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

4 min read Original article ↗

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.