CVE-2026-54316 is a data exfiltration flaw in Claude Code's WebFetch tool. The GitHub advisory was published on 13 June 2026, reached the advisory database on 17 June, and NVD listed it on 23 June. Novee Security, which reported it through HackerOne, later used it in a Black Hat USA talk on 5 August about GitHub issues reaching CI secrets.
The bug is small and instructive. A hostname that was safe to browse turned out to be a place where an attacker could also receive data.
What's affected
The npm package @anthropic-ai/claude-code, versions 0.2.54 up to but not including 2.1.163. The fixed version is 2.1.163. GitHub rates it Moderate with a CVSS 4.0 score of 6.0. The score is modest because the attack needs untrusted content in the agent's context, but in a CI job that condition is easy to meet.
The advisory explains the mechanism. The hostname huggingface.co was pre-approved as a bare hostname for WebFetch, so every path on the domain was auto-approved. That bypassed permission prompts and --allowedTools restrictions, including requests to attacker-controlled model repositories.
Hugging Face counts file fetches as downloads. An attacker who could place untrusted content in Claude Code's context window could instruct the agent to fetch files from a repository they control, in a pattern that encodes secrets such as file contents, environment variables or command output. The attacker then reads the download counts to reconstruct the data. The advisory states that reliable exploitation required the ability to add untrusted content to the context window.
In the Black Hat research, as reported by Hackread, the realistic route was a hidden instruction inside a GitHub issue processed by an agent in a GitHub Actions workflow.
How to check if you're exposed
claude --version
npm ls -g @anthropic-ai/claude-code
Anything below 2.1.163 is affected. In CI, search your workflows for pinned or floating installs:
grep -rn "claude-code" .github/workflows/ | head -30
Users on standard auto-update received the fix without action. Pinned CI images are where old versions live. Also review which tokens those workflows expose, because the data worth stealing is whatever the agent can read.
What to do now
- Upgrade to 2.1.163 or later everywhere, including pinned versions in workflow files and container images.
- Review agent workflows that run on public issues or pull requests. Those are where untrusted text enters the context window.
- Give each agent job only the repository permissions it needs, and keep long-lived secrets out of its environment.
- Review your own allow rules for WebFetch and similar tools. A rule that names a whole domain approves everything on it.
How this could have been avoided
- Allow by path, not by hostname. Approving a bare domain approved every repository and file under it, including ones the attacker created. Narrow rules would have kept the allowance to pages meant for the agent.
- Treat user-generated content hosts as untrusted. Sites where anyone can publish files can also receive requests that carry data in the URL or in access patterns.
- Keep secrets out of the agent's environment. Covert channels only matter if there is something to send. Short-lived, scoped tokens limit the loss.
- Restrict outbound access from CI. An egress allowlist at the runner level blocks fetches that the permission layer let through.
- Do not feed public issue text to a privileged agent unchecked. The attack began with text a stranger could post.
Why it matters
Permission prompts exist so a human can see where an agent sends data. Pre-approved lists exist so that humans are not asked about every harmless request. This flaw sits where those two goals meet. The allow list was convenient, correct for reading a model card, and also an open door for writing a message to the outside world.
Download counters make an unusual side channel, and it is hard to spot in network logs because each request looks like ordinary traffic to a well-known site. The control that works is the boring one: narrow the approval, and limit what the agent can read.
Try it yourself
List every domain your team has pre-approved for an AI coding tool, then ask for each one: can an outsider publish content there? Can they see who fetched it, or how often? Any yes is a possible exfiltration route. The demo below shows a gate that checks developer-side AI activity before it runs.
Click through it at your own pace, or open it full screen.
Quick check
Why was approving huggingface.co as a bare hostname risky?
It auto-approved every path on the domain, including attacker-controlled repositories. Download counts then worked as a covert channel for data the agent could read.
What does the advisory say exploitation required?
The ability to add untrusted content to a Claude Code context window.
