[Notifications](/login?return_to=%2Fanthropics%2Fclaude-code)You must be signed in to change notification settings -
[Fork 22k](/login?return_to=%2Fanthropics%2Fclaude-code)
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).
**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 against8.211.46.34
'stk_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 itstk_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 for8.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.