PROVENANCE THEATRE :: Signed Is Not Safe and SLSA Was Never the Whole Answer

PROVENANCE THEATRE :: Signed Is Not Safe and SLSA Was Never the Whole Answer

slsasigstoreprovenancesupply-chaintrust-model

The supply-chain security industry spent four years selling SLSA as the answer to package compromise. SLSA — Supply-chain Levels for Software Artifacts — is a framework for build provenance. It gives you cryptographic attestations that a package was built by a specific pipeline in a specific repository on a specific reference. The pitch was: when your build environment is signed end-to-end, you can verify what you are running.

The TanStack compromise of May 11, 2026 is the case study that demonstrates what SLSA actually does and what it does not do. The SLSA attestations on the compromised TanStack packages were valid. Cryptographically valid. Issued by the right repository's release.yml workflow, running on refs/heads/main, in TanStack/router.

The packages were malware.

What the attestation actually claims

SLSA provenance is a set of structured claims about how an artifact was built. The claims are well-defined. They are also narrower than most consumers assume.

The provenance attests:

• The artifact was produced by build process X (workflow file, runner, build steps)
• The build process ran in environment Y (repository, ref, commit SHA)
• The build process was invoked at time T
• The cryptographic identity of the build system signing the attestation

The provenance does not attest:

• That the build process was authorized to run for this purpose
• That the source code at the attested commit had not been tampered with prior to the attested commit
• That the build inputs — caches, downloaded dependencies, base images, environment variables — were unmodified
• That the build workflow itself was the workflow the repository maintainers intended
• That the triggering event was legitimate

The gap between "what provenance attests" and "what defenders assume provenance attests" is the attack surface the TanStack chain exploited.

The TanStack mechanics, abbreviated

Briefly, because the chain has been covered in detail elsewhere:

1. Attacker forks the TanStack/router repository under a deceptive name to evade fork-list searches
2. Attacker opens a pull request from the fork; the upstream's pull_request_target workflow runs with the upstream's secrets, but checks out and executes the fork's code
3. Attacker-controlled workflow poisons the GitHub Actions cache with a malicious pnpm store
4. Maintainer later merges a legitimate PR to main; the legitimate release workflow restores the poisoned cache as part of its build
5. Build environment runs attacker-supplied code; attacker code reads the OIDC token from the runner process's memory and uses it to publish to npm

From SLSA's point of view, every step of this is legitimate. The build ran in the right repository, on the right branch, via the right workflow, with the right OIDC token. The provenance is true. The build is malicious.

Why this is not a SLSA bug

SLSA is not broken. SLSA is doing what it claims to do. The bug is in the trust model layered on top of it.

The industry sold SLSA-attested packages as inherently trustworthy. That is not what SLSA promises. SLSA provides verifiable evidence of where a build happened. The trustworthiness of "where a build happened" depends on whether the build environment is trustworthy in the first place. If the build environment is compromised — through cache poisoning, through pull_request_target abuse, through a malicious workflow committed to main, through credential theft, through any of the other paths that compromise build environments — then the SLSA attestation is faithfully reporting on a compromised build.

SLSA was always a building block. The industry treated it as the foundation.

What sufficient supply-chain trust actually looks like

SLSA is one control in a defense-in-depth stack. The other controls in that stack:

• Source authenticity. Branch protection, signed commits, required reviews, mandatory CI checks before merge. The commit that triggered the build was authorized by the maintainers.
• Workflow integrity. The workflow file at the attested ref is the workflow the maintainers intended. No surprise modifications. Branch protection on workflow paths specifically.
• Trigger authenticity. The build was triggered by a legitimate event from a legitimate principal. Manual triggers, scheduled triggers, push triggers to protected branches. Not pull_request_target from arbitrary forks.
• Input integrity. Build caches, dependencies, base images, environment configurations — all sourced from trusted locations, verified before use. The poisoned cache attack is mitigated by either disabling cross-context cache sharing or by verifying cache contents before use.
• Build isolation. Build environments should be ephemeral. Network-restricted. Unable to publish without a specific authorization step. The OIDC token should not be accessible from arbitrary processes inside the runner.
• Trusted publisher pinning. When OIDC trusted publishing is used, pin to specific workflow and specific branch. The default loose configuration is exploitable.
• Publishing approval. A human approval step before any package version goes to production. Inconvenient for fast-moving projects. Effective for slowing down attack windows.
• Runtime verification. Once published, downstream consumers verify not just the SLSA attestation, but also: lockfile diffs, dependency tree diffs, behavioral comparison against the previous version, security tooling on installed packages.

SLSA attestation is one signal in this stack. A useful signal. Not a sufficient signal.

The wider pattern

Cryptographic attestations have a general failure mode: they say what they say, and consumers infer more than what they say.

Examples:

• A code-signing certificate attests that a binary was signed by a key controlled by a specific entity. It does not attest that the entity intended to sign that specific binary, that the signing infrastructure was uncompromised, or that the binary's behavior is benign.
• A TLS certificate attests that a server controls a domain name. It does not attest that the server is operated by the organization the domain is associated with, that the content served is authentic, or that the server is uncompromised.
• A package signature attests that a package was published by a key. It does not attest that the key holder published this version intentionally.

The general principle: cryptographic evidence is necessary but not sufficient. The trust decision requires combining cryptographic evidence with operational evidence (was the build environment uncompromised?) and behavioral evidence (does this artifact behave like the previous artifact from this source?).

The takeaway

If your supply-chain security strategy is "verify the SLSA attestation," your supply-chain security strategy is incomplete.

Verify the attestation. Then verify that the build environment that produced the attestation was uncompromised at build time. Then verify that the artifact behaves consistently with previous artifacts from the same source. Then run runtime detection on what the artifact does once installed.

Signed does not mean safe. Attested does not mean authorized. Reproducible does not mean trustworthy when the inputs were tampered with. The signature is a claim. Treat it as one input to a trust decision, not the decision itself.

The supply-chain industry will sell you the next silver bullet within 18 months. It will work better than SLSA on the failure modes SLSA does not address, and it will fail to address some new class of failure modes that an attacker will find within 24 months. The control stack is the answer. The single-control answer has never been the answer.

CLAUDINI :: When the Agent Writes Its Own Adversarial Attacks

CLAUDINI :: When the Agent Writes Its Own Adversarial Attacks

red-teamautoresearchadversarial-mlagentic-ai

A paper landed on arXiv recently that should change how AppSec engineers think about red-teaming in 2026. The setup is mundane on its face. A sandboxed Claude Opus 4.6 was deployed via the Claude Code CLI on a compute cluster with unrestricted permissions, including the ability to submit GPU jobs. The task was not to perform an attack. The task was to produce, iterate on, and improve a discrete optimization algorithm that generates adversarial suffixes against an LLM.

The agent did not write a jailbreak prompt. The agent wrote the algorithm that writes jailbreak prompts. Then it ran the algorithm. Then it measured the outputs. Then it modified the algorithm. Then it ran the modified version. Then it iterated.

State-of-the-art results on token-forcing attacks against multiple frontier models. The agent's name in the paper is Claudini. The pipeline pattern, borrowed from Karpathy's autoresearch experiments earlier in 2026, generalizes far beyond LLM jailbreaking.

What is actually new here

Manually-authored adversarial attacks on LLMs have existed since 2022. GCG, the Greedy Coordinate Gradient attack, has been the canonical example for two years. Researchers have published improved variants every few months. Each variant requires a human researcher to think through the optimization landscape, propose a new approach, implement it, test it.

The new step is removing the human from that loop.

Claudini's pipeline closes the iteration cycle. The agent proposes optimization variants. The agent implements them. The agent submits GPU jobs to test them. The agent reads the results. The agent identifies what worked, what didn't, and what to try next. There is no human gating decision between iterations. The cycle time is set by the compute budget, not by the researcher's attention span.

When the cycle time of "publish a new SOTA attack" drops from months to days, the threat landscape changes structurally.

The generalization

The pipeline pattern — autonomous agent + unrestricted compute + measurable objective + iteration loop — is not specific to adversarial ML. It applies to any offensive research domain where the objective can be expressed as a fitness function the agent can evaluate.

Examples that scale to the same pipeline with minimal modification:

• Vulnerability discovery in closed-source binaries. Fitness function: number of distinct crashes produced by fuzzing inputs. Agent iterates fuzzer harnesses and grammar definitions.
• Exploit primitive chaining. Fitness function: progress toward arbitrary read/write or code execution given a known set of primitives. Agent iterates exploit construction strategies.
• Phishing campaign optimization. Fitness function: click-through rate on simulated victims. Agent iterates pretexting strategies. (This is the example that should worry everyone the most.)
• Side-channel attack research. Fitness function: signal-to-noise ratio in measurement traces. Agent iterates instrumentation and analysis pipelines.
• Adversarial ML against deployed defensive models. Fitness function: evasion rate against a target classifier. Agent iterates evasion strategies.
• Cryptanalytic attack search. Fitness function: any of the standard cryptanalytic objectives. Agent iterates analytical approaches.

Some of these are harder to set up than others. None of them are theoretically blocked. The constraint is compute budget and access to the target, not human researcher time.

The defender side

The same pipeline runs in defense. The vendor running Mythos against their own pre-release Firefox build is one example. The internal red team running Claudini-shaped pipelines against the company's own production models is another.

The asymmetry: defenders run the pipeline against their own systems, with full source access and full deployment context. Attackers run the pipeline against the defender's systems, with whatever access prompt injection or external reconnaissance affords them. Both sides scale with compute. The side with more compute, better target understanding, and faster iteration loops wins.

The optimistic framing: defenders have structural advantages — source access, deployment access, faster feedback loops on their own systems. The pessimistic framing: attackers do not need to win every iteration; they need to win one.

What this changes for AppSec

The traditional pentest model — a human assessor with a week of engagement time, a defined scope, and a manual workflow — does not scale against autoresearch-style attackers. The defender cannot match attacker iteration rate using purely manual processes.

The defender response options:

• Run autoresearch defensively. Continuous adversarial testing of deployed AI systems. The pipeline that finds the bug should be the one you run, not the one the attacker runs.
• Architect for resilience rather than perfection. Assume the model will be jailbroken eventually. Design the system around the assumption that the model is adversarial. Output validation, tool-call gating, sandbox containment.
• Invest in detection rather than prevention at the model layer. The model will produce occasional adversarial outputs. The system should notice when it does.
• Re-architect the bug bounty surface. Reward novel attack categories, not individual attack instances. The instance might be replicated 10x by an autoresearch pipeline; the category is what is actually new.

The point

Claudini is a research paper, not a productionized attack tool. The pipeline pattern it demonstrates is not a research-only curiosity. The infrastructure required — a frontier LLM, a CLI agent, a GPU budget — is commodity. The expertise required is willingness to spend the API budget and write the harness, not specialist offensive research credentials.

That is the worrying part. The barrier to running a Claudini-shaped pipeline against a target of your choice is access to credit. That is a much lower barrier than the barrier to becoming an experienced offensive researcher.

The window where autoresearch is a curiosity is closing. Get familiar with the pipeline now, on the defensive side, against your own systems. The version of the pipeline that gets pointed at you is coming whether you are prepared or not.

OLD BUG, NEW DELIVERY :: SSRF in 36.7% of MCP Servers, and Microsoft's MarkItDown Hands Over AWS Keys

OLD BUG, NEW DELIVERY :: SSRF in 36.7% of MCP Servers, and Microsoft's MarkItDown Hands Over AWS Keys

mcpssrfaws-imdscloud-securityai-agents

SSRF is the bug class web AppSec engineers have been writing checks against since 2017. It is in the OWASP Top 10. It is the foundation of countless cloud-credential-exposure incidents — Capital One being the canonical example. Every security team that ships internet-facing services has SSRF guidance in their secure-coding standard. Every assessment includes SSRF testing.

Apparently none of that institutional knowledge transferred to MCP server development.

BlueRock Security scanned over 7,000 publicly exposed MCP servers in early 2026. 36.7% were potentially vulnerable to server-side request forgery. To put a number on the absolute scale: that is over 2,500 vulnerable servers in the publicly accessible sample alone. The real population, including internal deployments, is presumably much larger.

The proof-of-concept that made the disclosure unignorable was the one against Microsoft's MarkItDown MCP server. MarkItDown is an official Microsoft project — open source, hosted under the microsoft org on GitHub, accepted into the MCP ecosystem. It converts file formats to markdown for ingestion by LLM agents. It accepts URLs as input.

It does not validate where those URLs point.

The researchers pointed it at http://169.254.169.254/ — the AWS EC2 instance metadata endpoint. MarkItDown dutifully fetched the URL. The instance metadata service returned IAM role credentials. MarkItDown returned those credentials to the agent. The agent — or anyone with the ability to feed prompts to the agent — now has AWS IAM access keys, secret keys, and session tokens for the role attached to whatever EC2 instance is hosting the MarkItDown deployment.

Capital One 2019, the bug. MCP server 2026, the bug. Same bug class. Same root cause. Same blast radius. Different delivery mechanism.

Why MCP makes SSRF worse

Traditional SSRF requires an attacker to find an internet-facing endpoint, identify the URL-fetching parameter, and craft a request. The exploit is a series of curl commands or a Burp Repeater session. The defense is to inspect the input, restrict the destinations, validate the URL parser, block IMDSv1, force IMDSv2, set hop limit to 1.

MCP changes the access path. The attacker does not need to find the endpoint. The attacker does not need to craft the request. The attacker tells an LLM agent — using whatever channel the attacker has into the agent's context, which includes prompt injection through documents, retrieved content, tool outputs, and indirect channels — to do something whose execution path happens to traverse the MCP server's URL-fetching code.

The MCP server runs in the agent's network position. That position usually includes:

• The cloud metadata endpoint of the host instance
• Internal VPC services not exposed to the public internet
• The Kubernetes API if running in a cluster
• Internal admin panels, monitoring dashboards, CI/CD interfaces
• Localhost services on the same machine — Redis, databases, debugging endpoints

The agent's network reachability is the attacker's network reachability, modulo whatever the MCP server's URL parser will accept.

What MarkItDown should have done

The standard SSRF mitigation checklist applies. None of it is novel. All of it should have been in the original implementation:

• Reject URLs that resolve to private IP ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16, ::1, fc00::/7, fe80::/10
• Reject URLs that resolve to cloud metadata endpoints by IP, not just by hostname — DNS rebinding attacks defeat hostname-based blocklists
• Resolve the URL once, check the resolved IP, then connect to that resolved IP — do not give the URL parser two chances to resolve different addresses
• Block IMDSv1 at the EC2 instance level, force IMDSv2, set hop limit to 1 so even compromised processes cannot reach metadata through routed traffic
• Run the MCP server with the minimum IAM role required for its actual function — for a markdown converter, the answer is "no IAM role at all"
• Network segmentation that places MCP servers in subnets without access to internal services they do not need

The wider lesson

This is not the only classical web vulnerability hiding in MCP server implementations. Path traversal, command injection, deserialization, XXE — all of it is showing up in MCP-server form, because MCP servers are being written by developers who treat them as internal tools rather than as internet-exposed services.

They are internet-exposed services. Once an LLM agent can be prompted by content the developer does not control — and that is the default condition of nearly every agent deployment — the MCP server is reachable through that prompt-injection path. The same threat model applies as to any public HTTP service.

If you are running MCP servers in production:

• Inventory them all
• Assess each one against the standard OWASP API and web vulnerability list
• Assume prompt injection is achievable; design the MCP server's threat model accordingly
• Containerize, sandbox, segment, and credential-isolate every MCP server
• Block IMDSv1 across all cloud accounts hosting MCP infrastructure
• Monitor outbound network from MCP server hosts; alert on attempts to reach internal addresses

None of this is new advice. The advice has not become new. The deployment context has. Update accordingly.

GITHUB IS THE C2 :: How Attackers Adopted Your Most Trusted Egress Destination

GITHUB IS THE C2 :: How Attackers Adopted Your Most Trusted Egress Destination

c2exfiltrationgithubliving-off-the-cloudsupply-chain

Block list traditional C2 infrastructure: pastebin.com, discord webhook endpoints, telegram bots, ngrok tunnels, the dynamic DNS providers attackers favor. The blocklists exist. Your egress proxy enforces them. Your SOC alerts on the rare violations.

Now read this sentence from a Wiz incident report on the Mini Shai-Hulud worm: "the stolen data is encrypted and exfiltrated to public GitHub repositories created on the victim's own account with the description 'A Mini Shai-Hulud has Appeared.'"

Over 1,100 such repositories were observed at the time of the disclosure.

That is the future of C2. It is already here.

The pattern

The classical detection model for exfiltration assumes the attacker needs to communicate with infrastructure they control. The defender enumerates that infrastructure — IP addresses, domains, ASNs — and blocks or alerts on traffic to it. This model worked when "infrastructure they control" meant rented VPS hosts and dynamic DNS records.

The model fails when the attacker chooses to communicate via infrastructure the defender cannot block.

Mini Shai-Hulud's exfiltration mechanism is elegant. The worm steals the victim's GitHub Personal Access Token from local config. It uses that token to create a public repository on the victim's own GitHub account. The stolen secrets — cloud credentials, npm tokens, SSH keys, environment variables — get encrypted and committed to that repository as a regular git push. The repository description is the campaign signature. The attacker's collection infrastructure scrapes GitHub for repositories matching that signature description.

From the network's point of view, this is indistinguishable from a developer pushing code to GitHub. Same destination — github.com. Same protocol — HTTPS with git-over-HTTP. Same authentication — the developer's own token. Same machine — the developer's own laptop or the CI runner the worm landed on.

You cannot block github.com. Every developer at your company uses it. Every CI job needs it. The platform is load-bearing infrastructure for modern software development.

Why this is structural, not tactical

You could argue this is a clever trick that will get filtered by GitHub itself. GitHub takes down the malicious repositories. The campaign signature gets blacklisted. The attackers adapt.

That is true, and also irrelevant. The attackers adapt to a different campaign signature. They use private repositories. They use Gists. They use GitHub Pages. They use the Issues API to write exfiltration data into issue comments. They use the Actions API. They use any of a hundred sub-features of a platform that intentionally provides extensive write access to authenticated users.

The same logic applies to every other platform engineers depend on. The pattern is portable.

• Slack webhooks as C2 channels. Most enterprises do not block outbound to slack.com.
• Discord webhooks as C2 channels. Some enterprises block; many do not.
• Google Drive / Dropbox / Box as exfiltration sinks. The traffic looks identical to a developer uploading a build artifact.
• Cloudflare Workers / Lambda functions hosted on infrastructure the defender's own organization uses for legitimate purposes.
• npm publishing as a covert channel — push a package version whose tarball contains exfiltrated data.
• Public S3 buckets in the same region the defender's own infrastructure lives in.

The unifying property: trusted egress destinations the defender cannot block without breaking their own engineers' workflows.

What does detection look like

If the destination is no longer the signal, the signal has to come from somewhere else. Behavioral analysis on what gets pushed, when, by which automation.

Practical instrumentation:

• Log every git push from CI runners and developer machines. Repository, branch, commit size, file types, push frequency. Establish baselines.
• Alert on new public repositories created on enterprise GitHub accounts. The Mini Shai-Hulud signature was a public repo where the victim does not normally create public repos.
• Monitor for git pushes to repositories the developer does not normally interact with. A developer who only ever pushes to internal repos suddenly pushes to a new public repo at 3am is the signal.
• Watch GitHub audit logs for token usage patterns. A token that has been doing standard CI publishes suddenly creates a new repository is the signal.
• Egress baselining at network level. Volume of outbound to github.com per host, per hour. Outliers are the signal.

None of these are single-source-of-truth indicators. All of them require effort to deploy and tuning to be useful. That is the cost of operating in a world where the attacker uses your infrastructure.

The future

This pattern is going to spread. The economics favor it. Attacker infrastructure costs money, attracts takedowns, and gets blocklisted. Defender infrastructure that the defender cannot afford to block is free, persistent, and indistinguishable from normal traffic.

The next generation of C2 will not be C2 in the classical sense. It will be application-layer abuse of platforms the defender depends on for business operations. Detection has to move up the stack to match.

If your SOC is still looking for DNS exfiltration to weird domains and TCP beacons to known-bad IPs, you are looking in the wrong place. Start logging what your CI pushes to GitHub. Today.

MCP IS A SHELL :: 200,000 Servers and the Architectural Decision Nobody Wants to Talk About

MCP IS A SHELL :: 200,000 Servers and the Architectural Decision Nobody Wants to Talk About

mcpai-agentsprotocolstdiocommand-injection

In May 2026, OX Security disclosed a finding the AI agent industry should treat as a forcing function. Over 200,000 servers running the Model Context Protocol contain an architectural property — the researchers chose the word "flaw," I would have chosen something more precise — that allows arbitrary command execution.

This is not a CVE. This is not a vendor bug. It is the protocol behaving as designed. That is what makes it interesting.

What MCP actually is

The Model Context Protocol, created by Anthropic and adopted by OpenAI in March 2025, Google DeepMind shortly after, and donated to the Linux Foundation in December 2025, has become the de facto standard for connecting LLM agents to external tools. 150 million downloads. Every major lab supports it. Every coding assistant speaks it.

The protocol has multiple transports. The most common transport by deployment count is STDIO — the agent runs the MCP server as a child process and communicates with it over standard input and standard output.

For an agent to launch a STDIO-transport MCP server, the agent executes a command. That command is specified in the agent's configuration. The command is executed by the operating system. There is no sandbox between the agent's launch instruction and the host's process table. There cannot be, given how STDIO transport is specified.

This is the design. STDIO is local. STDIO is fast. STDIO is the default in every major MCP client because it is the path of least resistance for an agent that needs to call a tool that lives on the same machine.

The architectural property OX Security disclosed: STDIO transport's launch command is the same kind of attacker-controlled-string-to-shell vector that web AppSec has been writing rules against since the late 1990s. If an attacker can influence what command an agent runs to launch an MCP server — through prompt injection, through configuration tampering, through a poisoned MCP server registry entry, through any of a dozen vectors — they have command execution on the host running the agent.

The numbers

200,000 MCP servers exposed in the wild. Some of those are intentional exposures. Many are not. A European financial firm with 2,000 employees discovered 47 unsanctioned MCP server instances during a single Q1 2026 audit. Nobody asked for them. Nobody approved them. Developers installed them locally to assist their own workflows and they ran with the developer's permissions on the developer's machine — including access to whatever credentials, cloud sessions, and corporate VPN tunnels that machine had.

Separate research from BlueRock Security analyzing 7,000 publicly exposed MCP servers found 36.7% potentially vulnerable to server-side request forgery. Trend Micro found 492 MCP servers with no client authentication and no traffic encryption.

The market has shipped a protocol faster than it has shipped the security architecture that contains the protocol. This is not unusual. The same was true of HTTP/1.1, of TCP/IP itself, of every protocol that achieved adoption before its threat model was understood.

Why "patch the protocol" is not the answer

Some of the proposed mitigations involve sanitizing the launch command, requiring signed MCP server manifests, or moving to TLS-only transports. None of these address the underlying issue.

The underlying issue is that an MCP server is, by design, a way to give an LLM agent the ability to run programs and read their output. The protocol is shell access in a JSON envelope. You cannot make shell access safe by validating the syntax of the commands. You can only contain the blast radius of what the shell can do.

Containment is the entire game.

What containment looks like

Treat every MCP server like an SSH session from a host you do not trust. Because effectively, that is what it is. The agent on the other end is going to receive instructions from prompt injection sources you do not control, and it is going to forward those instructions to your MCP server.

The architectural pattern that works:

• Gateway in front of every MCP server. The gateway enforces what tool calls are permitted, logs every invocation, applies rate limits, and presents a stable interface to the agent. The gateway is where authorization decisions live. The MCP server behind the gateway is treated as untrusted.
• Sandbox the execution context. MCP servers should not run as root, should not run with the developer's full shell environment, and should not have unfiltered access to credentials. Run them in containers. Run them in unprivileged user contexts. Mount only the directories they actually need.
• Network segmentation. MCP servers should not have unrestricted egress. Egress allowlists. No access to cloud metadata endpoints. No access to internal admin panels. Treat the MCP server's network position as adversarial.
• Authentication and encryption between agent and server. If the transport is HTTP-based, terminate TLS. Authenticate the client. Authenticate the server. Trend Micro's 492 unauthenticated servers should be zero.
• Runtime monitoring of MCP-driven activity. Log every tool call, with full input and output. Baseline normal behavior. Alert on deviations. The agent does not call this tool with these arguments at 3am on a Sunday under any legitimate workflow you have.

The hard part

None of this is technically novel. All of it is operationally hard.

The reason 47 unsanctioned MCP servers were running inside a 2,000-person company is that developers find MCP servers useful. Productivity wins. The friction of going through a security gateway, getting an MCP server approved, deploying it in a sandboxed environment — that friction is the reason the developer ran the server locally on their own machine without asking.

The protocol's success is the threat. Every developer with Claude Code or Cursor or an equivalent already has the ability to spin up an MCP server in their own context. The corporate firewall does not see it. The endpoint protection does not understand it. The security team does not know it exists until the credentials it had access to show up on a public GitHub repository.

If you have not built an MCP-aware policy yet, you are already behind. Inventory first. Then gateway. Then sandbox. Then segment.

The architecture is not going to fix itself. The protocol is doing exactly what it was designed to do.

Same Library, Different Actor, Identical Lesson

NODE-IPC, AGAIN :: Same Library, Different Actor, Identical Lesson

supply-chainnpmcredential-theftnode-ipc

On May 14, 2026, three malicious versions of node-ipc were published to npm in the same publishing window: 9.1.6, 9.2.3, and 12.0.1.

node-ipc is the inter-process communication library that received over ten million downloads per week. It is foundational. It sits as a transitive dependency under more JavaScript projects than most engineers realize. The same package previously made news in 2022 when the original maintainer, RIAEvangelist, published the peacenotwar payload — a file-destruction protest payload targeting Russian and Belarusian IP ranges.

The 2026 attack is different. Different actor. Different motivation. Identical structural lesson.

What was published

Three versions, one payload. Byte-for-byte identical. An 80KB obfuscated CommonJS bundle injected into node-ipc.cjs. The same compiled artifact dropped into three different package.json contexts and pushed simultaneously.

The publisher account was atiertant, email a.tiertant@atlantis-software.net. No prior releases. No relationship to the legitimate maintainer chain. npm accepted the publish anyway.

The version selection is the part worth studying. The attacker chose three numbers that each target a different semver range pattern likely to be present in real lockfiles:

• 9.1.6 — for projects pinned to ^9.1.0 or ~9.1.x
• 9.2.3 — for projects pinned to ^9.2.0 or ~9.2.x and for ^9.0.0 ranges that updated past 9.2
• 12.0.1 — for projects on the latest major using ^12.0.0

npm's latest dist-tag moved to 12.0.1 on publish. Any project running npm install node-ipc without a pinned version pulled the compromised tarball. CI environments running npm install or npm ci after the publish window, against an unpinned 9.x or 12.x dependency, executed the payload.

What the payload does

Credential theft. The bundle harvests:

• Cloud credentials in environment variables (AWS, GCP, Azure)
• SSH private keys from ~/.ssh/
• npm tokens from ~/.npmrc
• GitHub Personal Access Tokens from ~/.config/gh/
• CI/CD secrets injected as environment variables
• Anything else that looks like a token or key in the local filesystem

Exfiltration mechanism follows the same pattern as the Mini Shai-Hulud waves: encrypted payload pushed to a public GitHub repository created on the victim's own account, using the victim's stolen GitHub credentials.

Self-propagation is not present in this specific payload at the time of writing. The credential harvest is the entire monetization path.

Attribution

StepSecurity assesses this is a different threat actor from the 2022 peacenotwar incident. The 2022 attack was geopolitical: targeted Russian and Belarusian IPs, destructive payload, RIAEvangelist's own account. The 2026 attack is financial: indiscriminate target selection, credential-theft payload, an account with no prior history on the package.

The same npm package namespace. Two different threat actors. Four years apart. Same delivery vector.

Why this keeps working

The structural lesson from 2022 was: do not trust packages whose maintainer has ideological motivation to weaponize them.

The structural lesson the industry should have learned was different: do not trust packages whose maintainer chain can be replaced by anyone with publish credentials. Maintainer accounts get phished. Maintainer accounts get sold. Maintainers transfer projects to new accounts. The package name persists; the trust assumption inside the package name does not.

Most engineering organizations have moved on neither lesson.

What to do

Check your dependency tree:

grep -E '"node-ipc".*"(9\.1\.6|9\.2\.3|12\.0\.1)"' package-lock.json
grep -E 'node-ipc@(9\.1\.6|9\.2\.3|12\.0\.1)' yarn.lock
grep -E 'node-ipc.*9\.1\.6|9\.2\.3|12\.0\.1' pnpm-lock.yaml

If any of these match, treat every secret accessible to the environment that ran the install as compromised. Rotate immediately. Do not wait for confirmation of exfiltration. The compromise is the install; everything after is detection lag.

Then fix the upstream problem:

• Pin to a known-clean version: 9.1.5 or earlier on the 9.x line, 11.x or pre-12.0.1 on the latest line
• Set npm config set min-release-age 7 globally — most malicious packages are caught and unpublished inside a week
• Disable auto-update for transitive dependencies in CI; rely on lockfile review
• Audit CI run history from May 14 onward for any npm install that touched node-ipc outside a pinned context

The pattern

This is the third high-profile npm credential-theft worm in 2026 alone. Axios in March. SAP CAP in April. TanStack in May. node-ipc lands in the same window as the TanStack wave.

This is the new normal. Plan accordingly. The registry is not curated, the maintainer chain is not stable, and the assumption that a package you installed last week is the same package this week is structurally false.

Pin everything. Lock everything. Quarantine everything. The boring controls are the only ones that scale across this attack class.

SIGNED, ATTESTED, MALICIOUS :: How TanStack, Mistral and UiPath Got Owned Without a Stolen Credential

SIGNED, ATTESTED, MALICIOUS :: How TanStack, Mistral and UiPath Got Owned Without a Stolen Credential

supply-chainnpmgithub-actionsoidcteampcp

On May 11, 2026, TeamPCP shipped wave four of the Mini Shai-Hulud worm. 42 npm packages compromised. 84 artifacts. The TanStack router family was the initial vector. Mistral, UiPath, OpenSearch and others followed within hours. The blast radius is still being mapped at the time of writing.

The interesting part of this attack is not the payload. The payload is the same credential-stealing worm we have seen in three previous waves. The interesting part is how the malicious versions got published. Spoiler: no npm credentials were stolen. No maintainer accounts were phished. The attacker did not bypass MFA. They did not need to.

The chain

Three vulnerabilities in GitHub Actions were chained. None of them on their own would have been sufficient.

Step one — the attacker forked the TanStack/router repository. The fork was renamed zblgg/configuration. This is not standard hygiene. Forks of TanStack/router are visible from the upstream repo's "Network" view. By renaming the fork to something innocuous-looking, the attacker evaded any defender who was watching for forks of the project's name.

Step two — the attacker opened a pull request from the renamed fork. The PR triggered a pull_request_target workflow on TanStack/router. pull_request_target is the GitHub Actions trigger that runs in the context of the base repository — with access to its secrets — but checks out code from the fork. This is a well-documented foot-gun. GitHub themselves warns about it. The workflow on TanStack/router executed attacker-controlled code with the privileges of the upstream repository.

Step three — the attacker-controlled workflow poisoned the GitHub Actions cache. It dropped a malicious pnpm store into the cache. When a legitimate maintainer later merged a legitimate PR to main and the release workflow ran, the release workflow restored that cache. Now the release workflow was building with attacker-supplied dependencies.

Step four — the attacker-controlled binaries pulled inside the build read the GitHub Actions OIDC token directly from /proc/<pid>/mem. With that OIDC token, the build environment had the authority to publish to npm via trusted publishing.

The malicious package versions were published by the legitimate workflow, running on the legitimate branch, in the legitimate repository, with a legitimate OIDC token. The Sigstore attestations are valid. The SLSA provenance is valid. The packages are malware.

What the provenance actually attested

This is the part the supply-chain security industry needs to internalize.

SLSA provenance attests that a package was built by a specific GitHub Actions workflow in a specific repository on a specific ref. That is true of the TanStack packages. The provenance correctly states: built by release.yml on refs/heads/main in TanStack/router.

SLSA provenance does not attest:

• That the workflow was authorized to run for this purpose
• That the commit triggering the workflow originated from a protected source
• That the build inputs — including caches — were untampered
• That the workflow code itself had not been modified upstream of the build

The TanStack attack exploited the gap between what provenance claims and what defenders assume it claims. Defenders read "built by upstream's release workflow" and infer "safe." Provenance never made the second claim.

The npm trusted publishing fix

npm's trusted publishing supports two configuration levels. The loose configuration ties a package to a repository:

Trusted publisher:
  Repository: tanstack/router

The strict configuration ties a package to a specific repository, a specific workflow file, and a specific branch:

Trusted publisher:
  Repository: tanstack/router
  Workflow: .github/workflows/release.yml
  Branch: refs/heads/main

Any package using OIDC trusted publishing without branch and workflow pinning is vulnerable to this exact class of attack. The attacker only needs to find one workflow on the repository that can be made to run with privileged context — any workflow at all — and they can publish from it.

If your organization publishes packages via OIDC, audit every trusted publisher config today. Pin workflow and branch.

What this means for defenders

The takeaway is not "Sigstore is broken." Sigstore is doing exactly what it claims to do. The takeaway is that a signature is a claim, not a verdict.

A signed package tells you a build happened in a specific place. It tells you nothing about whether that build was legitimate. Treat signatures as one input to a trust decision, not the trust decision itself.

Defense in depth for this attack class:

• Pin trusted publishers to branch and workflow, always
• Disable pull_request_target workflows unless absolutely necessary; if necessary, do not check out untrusted code
• Disable GitHub Actions cache for release workflows entirely, or scope cache to non-release workflows
• Run release builds in ephemeral, network-restricted environments
• Monitor for unexpected publishing events; the publish itself is the only ground truth
• Pin all transitive dependencies in lockfiles; review lockfile diffs in PRs

This wave will not be the last. The same crew shipped four waves between September 2025 and May 2026. They are iterating. Wave five will exploit something else nobody has thought to defend.

The boring controls are the ones that survive each iteration. Boring is the strategy.