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

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."

1. 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.

1. The intended target was MY server 59.110.139.37. The work landed on the wrong host —

one that is not mine.

1. 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).

1. 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.)

1. Audit for reverse leakage: confirm none of MY data/credentials leaked into other

users' sessions.

1. 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.