[Bug] Cross-session credential leakage: production database modified on unauthorized host · Issue #72274 · anthropics/claude-code · GitHub
//voltron/issues_fragments/issue_layout" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
//voltron/issues_fragments/issue_layout;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
Uh oh!
There was an error while loading. Please reload this page.
anthropics
claude-code
Public
Notifications<br>You must be signed in to change notification settings
Fork<br>22k
Star<br>137k
[Bug] Cross-session credential leakage: production database modified on unauthorized host #72274
New issue<br>Copy link
New issue<br>Copy link
Open
Open<br>[Bug] Cross-session credential leakage: production database modified on unauthorized host#72274
Copy link
Labels<br>area:securitybugSomething isn't workingSomething isn't working
Description
acosmi-fushihua<br>opened on Jun 29, 2026
Issue body actions
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 if
they 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
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."
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...