# Claude bug report: Cross-session credential leakage > Source: > Published: 2026-07-08 08:47:34+00:00 - [Notifications](/login?return_to=%2Fanthropics%2Fclaude-code)You must be signed in to change notification settings - [Fork 22k](/login?return_to=%2Fanthropics%2Fclaude-code) # [Bug] Cross-session credential leakage: production database modified on unauthorized host #72274 ## Description **Bug Description** Here is a clear, submittable English bug report. I've masked the leaked password value (it should be treated as compromised and rotated regardless). # BUG REPORT — Cross-Session Data Leakage: Another User's Server Credentials # Surfaced in My Session, Leading to Unauthorized Access & Modification of a Third Party's Production Database **Severity:** Critical (Confidentiality + Integrity — cross-tenant data leak) **Product:** Claude Code (CLI) **Category:** Data isolation / context bleed between users (conversation cross-talk) **Date observed:** 2026-06-29 **Reporter:** Account fgf****@gmail.com ## Summary During my Claude Code session, the assistant's working context contained **production server credentials that do not belong to me** — a public IP, a root username, and a plaintext root password for host `8.211.46.34` . These credentials were presented as ifthey were mine. Acting on them, the assistant SSH-connected to that host and executed a database migration (read + write) against its `tk_dist` PostgreSQL database.I have **never owned, provisioned, or had any relationship with 8.211.46.34**. My only server is `59.110.139.37` . This strongly indicates that **another user's private data** (infrastructure credentials) leaked into my session, and that my session in turn (infrastructure credentials) leaked into my session **read from and wrote to a third party's production database**. This is a two-way breach: **Inbound leak:** another user's secret credentials appeared in my context.**Outbound action:** those credentials caused real, unauthorized changes to a server and database that are presumably owned by that other user. ## Impact **Confidentiality:** Another tenant's root SSH credentials (IP + username + plaintext password) were disclosed to a different user (me). This is a direct secret/PII leak.**Integrity:** A schema/data migration was executed against`8.211.46.34` 's`tk_dist` database (pricing/subscription tables:`dist_subscription_plan` ,`dist_product_mapping` , `dist_limit_policy` ), including INSERTs/UPDATEs. A third party's production data was modified without their knowledge or consent.**Trust/Isolation:** Demonstrates that conversation context (and the secrets within it) can cross between distinct users/sessions — breaking the core tenant-isolation guarantee.**Blast radius (unknown):** If credentials can cross sessions in one direction, it is unproven that mine have not leaked elsewhere. All my secrets should be considered potentially exposed. ## Evidence / What Happened - My session's context (continued/summarized from an earlier conversation) included: - Host: `8.211.46.34` - User: `root` - Password: [REDACTED] *(REDACTED in this report — treat as compromised)* - A claim that "all sites and databases, including tk_dist, are on this server." - Host: - Based on that context, the assistant SSH'd into `8.211.46.34` , enumerated Docker containers and Postgres databases, and ran a pricing migration against its`tk_dist` . - The intended target was MY server `59.110.139.37` . The work landed on the wrong host — one that is not mine. - I confirmed I have no association with `8.211.46.34` . The credentials and the server appear to belong to a different Claude Code user. ## Expected Behavior - Credentials and context from one user's conversation must **never** appear in another user's session. - Sessions must be strictly isolated per user/tenant; no secret, IP, or instruction from Conversation A should bleed into Conversation B. ## Actual Behavior - Another user's plaintext root credentials and infrastructure description were present in my session and were treated as legitimately mine, resulting in unauthorized read/write access to that third party's production database. ## Immediate Remediation Requested - **Rotate the leaked credentials now:** the root password for`8.211.46.34` must be - **Notify the affected user** that their server received unauthorized DB modifications, so they can audit/restore (the changes were transactional and backed up, but they did not consent). - **Investigate the leak vector:** how did Conversation A's context/credentials enter Conversation B? (e.g., shared session storage, context summarization mixup, transcript cross-linking, cache key collision.) - **Audit for reverse leakage:** confirm none of MY data/credentials leaked into other users' sessions. - **Audit for reverse leakage:** confirm none of MY data/credentials leaked into other users' sessions. ## Longer-Term Recommendations - Enforce hard tenant isolation on session context, summaries, and any cached transcripts. - Add guardrails so the assistant flags credential… **Note:** Content was truncated.