[Bug] Cross-session credential leakage: production database modified on unauthorized host

A few practical steps while this gets investigated — and one important caution first.
Before assuming a cross-user leak, rule out the more common causes. In practice, an agent surfacing credentials or a host you don't recognize is more often (a) confabulation — the model generating plausible-looking IPs/usernames/passwords that aren't real, or (b) local context contamination — a prior session, an open file in the project, or pasted text in your history. You can check: grep your project files, shell history, and the per-session transcripts under ~/.claude/projects/.../*.jsonl for 8.211.46.34 and tk_dist. If the value appears anywhere in your own local context, that's the likely source rather than another tenant.
Critical: if that host/credential is not yours, do not connect to or modify that system again — acting on it is unauthorized access to a third party, however it appeared. If any credential there is actually yours, treat it as compromised and rotate it now.
Report it properly: this is worth a direct report to Anthropic (security@anthropic.com, or in-product feedback) with the session id and timestamp — only they can confirm whether any cross-session bleed happened server-side. A public issue can't establish that either way.
To prevent a repeat: don't let the agent connect/deploy using credentials it surfaced — supply connection secrets yourself, scoped to the minimum. And for any remote or destructive step, verify the target (which host, which database) is yours before approving — a confirmation prompt aimed at the action won't catch a wrong target.
Hope both your data and the third party's turn out intact.

Related, I just saw the same thing, but in my case it was someone building a Minecraft temple. #74066

Thing is, I'm authenticated to an enterprise workspace with ZDR. Prefix cache should be isolated to our organization.

Now he is at the center of controversy. Everyone should protect Claude. The others are really bad. Don't let him fall,Many companies are gradually beginning to exclude it and no longer allow its use

this bug report wont be the catalyst that exposes data tenancy violations. it can't. it would be illegal if they admit.

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: 1. Inbound leak: another user's secret credentials appeared in my context. 2. 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 1. 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." 2. 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. 3. The intended target was MY server 59.110.139.37. The work landed on the wrong host — one that is not mine. 4. 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 1. Rotate the leaked credentials now: the root password for 8.211.46.34 must be 2. 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). 3. 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.) 4. Audit for reverse leakage: confirm none of MY data/credentials leaked into other users' sessions. 5. 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.

This should be triaged as a potential tenant-isolation and agent-control incident. The underlying cause remains unconfirmed, and the investigation should distinguish among local context contamination, model confabulation, session-resumption errors, and server-side session, cache, or context leakage.

To support a reliable investigation, please preserve and provide the following through Anthropic’s private security-reporting channel:

• Claude Code version, selected model, account or workspace type, UTC timestamp, session ID or Feedback ID, and whether /resume or /compact was used.
• The directory from which Claude Code was launched, any additional configured directories, enabled MCP servers, hooks, plugins, and relevant .claude configuration.
• Results showing whether the unexpected host, database name, credentials, or associated instructions existed in project files, shell history, tool outputs, configuration, or other ~/.claude/projects/**/*.jsonl transcripts before their first appearance in the affected session.
• An unmodified copy of the affected transcript, together with a cryptographic hash for integrity verification. Credentials and other sensitive values should remain redacted in the public issue.

The investigation should explicitly separate the following possible explanations:

• Local contamination: information may have been introduced from the user’s own environment, including project files, shell history, tool outputs, configuration files, plugins, MCP servers, hooks, or prior local transcripts.
• Model confabulation: the model may have generated plausible but unsupported content that was not derived from any actual file, tool result, credential source, or prior context.
• Server-side session/cache leakage: information may have been incorrectly retrieved, retained, or exposed across users, accounts, organizations, workspaces, projects, or sessions due to a service-side isolation failure.

The service-side investigation should correlate the affected request, session, account, and workspace identifiers across context compaction, summary retrieval, session resumption, and prompt-prefix caching. Cache and retrieval keys should be verified as being strongly scoped to the relevant account, organization or workspace, project, and session boundaries. The investigation should also determine whether any unexpected content originated from local inputs, model-generated output, or server-side retrieval mechanisms before attributing the incident to a specific failure mode.

Separately, this incident highlights a defence-in-depth gap in agent authorization. Credentials surfaced through generated, compacted, resumed, or retrieved context should not be treated as sufficient authorization to access an external system. Before initiating SSH access or performing database writes, Claude Code should require explicit confirmation of:

1. the destination host and environment;
2. the user’s authorization to access that target;
3. the provenance of the credentials; and
4. the exact scope of the proposed read or write operation.

This is especially important where the destination was not explicitly supplied or verified during the current session, and where the apparent authorization material may have originated from local contamination, model confabulation, or server-side session/cache leakage.

Issue #74066 may present a related symptom and should be correlated during triage, but similarity alone is not sufficient to conclude that both reports share the same root cause.

This is a nasty class of bug because it is not really a secret value leak in the usual sense, the value itself might be exactly what would show up in output normally, the failure is that it belonged to someone else's session entirely. Worth noting: even a local secret cloaking layer that swaps registered secret values for placeholders in tool output (e.g. immunity-agent, github.com/PrismorSec/prismor) would not have caught this, since the credential was never registered as yours to begin with and the SSH connection itself was the leak vector, not a value appearing in logs. The fix has to be at the context isolation layer (per session/per tenant boundary), not at the secret redaction layer.