Claude Session-Bridge Tokens and Artifact Uploads: What the exploit.cat Disclosure Claims

A researcher published a 90-day disclosure on October 20, 2026 claiming two things about Anthropic's Claude products: that a Claude Code session-bridge token let free accounts use paid models through the Message Batches API, and that a file uploaded to a chat sandbox could be published as an artifact and opened in Claude Desktop. The write-up, "Hacking Anthropic For Free Unlimited Claude" on exploit.cat, is a single-researcher account. We could not reproduce any of it and Anthropic has not published its own statement that we could find. This post separates what is claimed, what Anthropic's documentation confirms, and what you can check on your own machines.

Claim one: the session-bridge token and the Batches API

What the researcher describes

Claude Code can share a session with Claude Desktop through a "bridge". According to the write-up, a POST to /v1/code/sessions/{id}/bridge on claude.ai returned an ES256-signed worker JWT with the prefix sk-ant-si- to any signed-in claude.ai user, regardless of plan. The researcher says free-tier accounts, whose capabilities list only chat, could call it, provided the account had sent at least one message. The researcher classes the missing capability check as CWE-863, incorrect authorization.

The token was then presented as a bearer token to the API. The researcher reports two further gaps:

1. Calls to /v1/messages with a premium model from a free account returned a 429 "not available on your plan", but on a paid account the token drew on the claude.ai usage allowance, so any harness could reuse a subscription's limits. The token had to be refreshed every 8 hours.
2. The Message Batches API at /v1/messages/batches, which accepts up to 100,000 requests per batch at low priority, had no plan gating at all for this token. The write-up says free accounts could reach every public model and that no account was billed.

The write-up lays out the request flow as a session creation, a bridge call that returns worker_jwt, and then batch requests polled until completion. We are not reproducing request bodies here; the full flow is in the original post.

Anthropic's reported response and the timeline

The researcher gives this timeline: reported through HackerOne on July 22, 2026; closed as Informational on July 23; review requested August 10, with an automated reply confirming the scoping; permission to discuss publicly given August 15; and the Batches endpoint began rejecting worker tokens around September 1 "despite being told this issue was out of scope". The researcher also says a related gap remained: after cancelling a paid plan, a paused account could still reach the messages endpoint on August 17. Disclosure came on October 20, 2026, when the 90-day window ended, and the researcher says some issues remain unfixed.

We have only the researcher's account of Anthropic's replies, which the post shows as screenshots. Treat the vendor's position as reported, not confirmed.

Why this matters beyond billing

At face value this is a plan-enforcement and billing problem, not a data exposure, and that is probably why it was scoped as it was. It still matters to people who run coding agents for three reasons. First, a long-lived or bearer-style credential that works outside the surface it was minted for is the pattern behind most token-abuse incidents; the question to ask of any agent credential is what it can do beyond its intended job. Second, the token prefix and format are now public, so scanners that look for sk-ant-si- strings in logs and repositories are worthwhile. Third, harnesses that accept a bearer token in a config file, such as the OpenCode config shown in the write-up, put a usable credential in a place that agents and extensions may read. Our write-up of the OpenCode console breach claims shows how quickly provider keys become the target.

How Claude Code chooses a credential

Whatever happened server-side, the local picture is documented. Anthropic's Claude Code authentication docs list the order Claude Code uses when several credentials are present:

1. Cloud provider credentials, when CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX or CLAUDE_CODE_USE_FOUNDRY is set.
2. The ANTHROPIC_AUTH_TOKEN environment variable, sent as an Authorization: Bearer header.
3. The ANTHROPIC_API_KEY environment variable, sent as X-Api-Key. In non-interactive mode (-p) the key is always used when present.
4. apiKeyHelper script output.
5. The CLAUDE_CODE_OAUTH_TOKEN environment variable, a long-lived token from claude setup-token.
6. Anthropic profile and federation credentials.
7. Subscription OAuth credentials from /login.

The docs also say credentials live in the macOS Keychain, or in ~/.claude/.credentials.json with file mode 0600 on Linux (and as a macOS fallback), and under %USERPROFILE%\.claude\.credentials.json on Windows. The researcher's list of seven methods follows the same order.

Two practical consequences follow. A stray ANTHROPIC_AUTH_TOKEN or ANTHROPIC_API_KEY in your shell profile outranks your /login session, so check env if billing looks wrong. And .credentials.json is exactly the kind of file an agent could be told to read, so treat it like any other secret store.

For organisations, the docs describe forceLoginMethod and forceLoginOrgUUID in managed settings to require logins to belong to a given organisation, and allowedProviders (Claude Code v2.1.285 or later) to limit which services a managed machine may reach. The docs state that claude setup-token and /install-github-app enforce only forceLoginMethod, so they can mint a token in a different organisation. These controls govern which account is used; they are not a defence against a server-side flaw.

Claim two: uploads promoted to artifacts, then a Chromium n-day

The mechanism as described

Claude's code-execution sandbox, which the write-up calls the "wiggle sandbox", mounts a Linux filesystem with roughly 10 GB of storage. Files uploaded through its upload endpoint land in /mnt/user-data/uploads. The researcher says the endpoint that converts files to artifacts correctly refuses paths under /uploads with wiggle_artifact_promotion_path_not_allowed, but artifacts are read from /mnt/user-data/outputs, so asking the model to run a cp from one folder to the other got around the block.

This matters because of what artifacts are. The researcher cites a Huntress post from July 24, 2026 saying a link to a legitimate claude.ai artifact URL led 29 organisations to an infostealer. Artifacts live on a trusted domain, so a link to one looks legitimate to people and to URL checks.

The write-up goes further. Artifacts can be "remixed" and opened in Claude Desktop, which is an Electron app and therefore bundles Chromium. The researcher states that at disclosure Chrome stable was 151.0.7922.34 and Claude Desktop bundled 148.0.7778.271, three major versions behind, and that 1,066 CVE-assigned fixes (389 rated high or above) landed between those versions. Using a public V8 backport commit, the researcher built an addrOf primitive and says opening the crafted remixed artifact would trigger it when the chat loads.

What the researcher does and does not claim

The write-up is careful here, and we should be too. It says a full browser exploit chain is hard, that this primitive alone only gives a caged read in the isolated renderer process serving claudeusercontent.com, and that it would need several more n-day exploits to be dangerous. It also states Claude Desktop is "genuinely very good" at staying current compared with other Electron apps.

Anthropic's reported position is that this is not a security bypass: /outputs can legitimately contain user-generated content, the blocks are model-side safeguards rather than security controls, the desktop app is updated on a regular cadence, and the demonstrated primitive does not cross the renderer sandbox. The researcher accepts the justification as an "acceptable risk" while still calling the vector real.

Our read

Both sides can be right. The path exists, and a Chromium primitive in a sandboxed renderer is not a compromise. The practical risk is the combination of three things: attacker-controlled content on a trusted domain, a desktop client one to three major browser versions behind, and a user who opens it. That is a patch-gap argument, and it applies to every Electron app that renders third-party content. Our post on the Claude Code desktop preview-pane exfiltration covers a different Claude Desktop surface where rendered content became a data path.

What this means if you run AI coding agents

1. Update Claude Desktop and Claude Code through your normal channel, and prefer managed rollouts where you can. For Claude Code, claude --version shows the version.
2. Do not open or remix artifacts from untrusted people. An artifact link on claude.ai is not proof of content you can trust, as the Huntress report on the infostealer campaign shows.
3. Audit what credentials your shells and agents can see. Run env and look for ANTHROPIC_AUTH_TOKEN, ANTHROPIC_API_KEY and CLAUDE_CODE_OAUTH_TOKEN; remember they outrank /login.
4. Search for token strings. Grep logs, shell history and repositories for sk-ant- prefixes. A leaked worker JWT would also be short-lived, but you want to know.
5. Pin who may sign in. For teams, set forceLoginMethod and forceLoginOrgUUID in managed settings and allowedProviders where your version supports it, and keep these keys in both the managed file and server-managed settings, as the docs instruct.
6. Keep bearer tokens out of shared harness configs. If you use a third-party harness, give it a scoped key rather than a session token copied from another tool.

What Beam can and cannot do here

Beam cannot see Anthropic's servers, Claude Desktop's Chromium or the Batches API. It cannot tell you whether a session-bridge token was minted for your account. What it can do is narrower: its agent hooks can flag credential exposure when Claude Code or Codex reads a credentials file or prints a token during a tool call, and it redacts known credential formats before anything is stored locally. That is heuristic, hook-based and not a kernel sandbox; it only sees what the agent does on your machine. See stopping Claude Code dangerous commands for the setup, and the local-first design for what stays on-device.

What is and isn't established

• Documented: the Claude Code credential precedence and storage locations, in Anthropic's docs.
• Reported by one researcher, not independently verified by us: the bridge endpoint behaviour, the plan-gating gaps, the sandbox path bypass, the Chromium version gap numbers, the timeline and Anthropic's replies.
• Reported by Huntress, per the researcher's link: the July 2026 artifact-hosted infostealer campaign. We have not separately confirmed it.
• Not claimed by anyone: a full compromise of Claude Desktop, access to other users' data, or exploitation in the wild of the Chromium primitive.

We will update this post if Anthropic or the researcher publishes further detail.

Frequently asked questions

What did the researcher claim?

That a Claude Code session-bridge endpoint issued a worker JWT to any signed-in claude.ai user, including free accounts, and that the token could call the Message Batches API without plan limits or billing. They also claim uploaded files could be copied into the outputs folder and published as artifacts.

Did Anthropic fix it?

The researcher says the Batches API issue stopped working around September 2026 after an unannounced product change, and that other plan-gating gaps remained. Anthropic reportedly does not treat the artifact path as a security bypass. We could not verify either statement independently.

Is Claude Code on my machine affected?

The post describes server-side authorization and a Claude Desktop artifact path, not a flaw in the Claude Code binary. Nothing in the disclosure says your local installation is vulnerable.

What should I check if I use Claude Desktop?

Keep it updated, and be cautious about remixing and opening artifacts from people you do not trust. The researcher reports Claude Desktop bundled a Chromium build three major versions behind Chrome stable at the time of disclosure.

How does Claude Code choose between credentials?

The Claude Code authentication docs list the precedence: cloud provider credentials, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_API_KEY, apiKeyHelper output, CLAUDE_CODE_OAUTH_TOKEN, Anthropic profile and federation credentials, then subscription OAuth from /login.

Can Beam detect any of this?

No. These are server-side and Claude Desktop issues. Beam can flag secrets such as tokens appearing in what a coding agent reads or runs locally, but it does not inspect Anthropic API traffic or Electron app internals.

Related reading

• Claude Code desktop preview-pane exfiltration
• OpenCode console breach claims, verified and unverified
• Claude Code plugin hash-pin bypass CVE-2026-86063
• Fake Claude Code installers aimed at developers
• Sources: exploit.cat disclosure and Claude Code authentication docs

Details are as published on October 20, 2026 and reflect the researcher's account. Check the sources for later changes.