AI Supply-Chain Attacks Hit OpenAI and Anthropic in 50 Days—Your CI Gap Is Showing

Four supply-chain incidents struck OpenAI, Anthropic, and connected AI ecosystem tools in under 50 days—three adversary-driven attacks and one self-inflicted packaging failure—and not a single one targeted the model itself. According to VentureBeat’s May 2026 investigation, all four exposed the same blind spot: release pipelines, dependency hooks, CI runners, and packaging gates that no system card, AISI evaluation, or commercial red team currently covers. If your marketing stack runs any AI SDK, desktop tool, or automation suite built on these platforms, your build infrastructure was inside the blast radius of at least two of these incidents—and you probably did not know it.

What Happened

The 50-day window opened on March 31, 2026, and the first hit was precise.

At 23:59:12 UTC on March 30, a malicious npm package named plain-crypto-js@4.2.1 was published to the public registry, according to Socket Research’s real-time monitoring. The attacker had published a clean predecessor (plain-crypto-js@4.2.0) eighteen hours earlier from the same account to establish credibility. Within 39 minutes, both axios@1.14.1 and axios@0.30.4 were poisoned across release branches. Axios has roughly 100 million weekly npm downloads. It became a delivery vehicle for a multi-platform remote access trojan.

The dropper used npm’s postinstall lifecycle hook—code that runs automatically during npm install—with a two-layer obfuscation scheme: reversed Base64 encoding and an XOR cipher using the key OrDeR_7077. When decoded, the payload deployed platform-specific second-stage binaries: VBScript for Windows, AppleScript for macOS, Python for Linux. The macOS payload was a Mach-O RAT capable of system fingerprinting, hourly C2 beacons, binary injection, and filesystem enumeration. The C2 domain sfrclak[.]com had been registered to impersonate npm infrastructure—a deliberate SIEM evasion technique.

OpenAI was hit the same day. The company’s GitHub Actions workflow for macOS app-signing was using a floating version tag with no minimum release age configured. That workflow pulled axios@1.14.1 the moment it was published. It had direct access to the code-signing materials for ChatGPT Desktop, Codex, and Atlas applications. OpenAI disclosed the incident on April 11, 2026, confirmed no user data or production systems were compromised, revoked and rotated its macOS code-signing certificate, and issued a hard deadline of May 8, 2026 for all users to update desktop apps before Apple blocked notarization under the compromised certificate. OpenAI’s own post-incident statement named the root cause directly: “the action in question used a floating tag, as opposed to a specific commit hash, and did not have a configured minimumReleaseAge for new packages.” This is a CI configuration failure. The model had nothing to do with it.

The same calendar date—March 31, 2026—produced a second incident. Anthropic published two security advisories for its Python SDK covering versions >= 0.86.0, < 0.87.0. The first, CVE-2026-34450 (CVSS 4.8), documented that the local filesystem memory tool created agent state files with mode 0o666, leaving them world-readable—and potentially world-writable in Docker base images with permissive umask settings. Persisted agent conversation history, customer data passed to Claude, and sensitive context stored by marketing automation tools were all accessible to any process in the same container. The second vulnerability, CVE-2026-34452 (CVSS 5.8), documented a TOCTOU race condition in the async memory tool: the SDK validated that model-supplied paths resolved inside the sandbox, then returned the unresolved path for actual file operations—creating a symlink-swap window for sandbox escape. Both were patched in version 0.87.0. These were not the result of an external attack. They were packaging failures shipped in a production PyPI release.

Six weeks later, the third and fourth incidents arrived simultaneously through the same campaign. Starting May 11, Socket’s detection pipeline identified 84 compromised TanStack npm artifacts containing a worm tagged as Mini Shai-Hulud, linked to the threat actor group TeamPCP. The attack vector was technically sophisticated: exploitation of GitHub Actions’ pull_request_target pattern to poison the Actions cache across the fork-to-base trust boundary, followed by OIDC token exchange to republish packages under hijacked maintainer identities. The attacker used GitHub’s passwordless publishing mechanism—no token theft required. The malicious packages carried valid SLSA Build Level 3 provenance attestations. Standard integrity checks passed.

The campaign expanded beyond TanStack rapidly. The Hacker News reported that mistralai@2.4.6 and guardrails-ai@0.10.1 were compromised, with the guardrails-ai version executing credential-stealing code immediately on import. Final scope: over 170 packages, 518 million cumulative downloads, CVE-2026-45321 assigned at CVSS 9.6. The worm wrote persistence hooks specifically to .claude/ and .vscode/ directories to survive reboots, targeting developers who work inside AI-augmented environments. Data exfiltration routed through Session Protocol’s decentralized P2P network (filev2.getsession.org) to disguise C2 traffic as encrypted messaging. By May 15, The Register confirmed that the worm had reached two OpenAI employee machines, exfiltrating limited internal credential material.

Why This Matters

The reflexive read on these incidents is that they belong to the security team. That reading misses what is actually at stake for marketing organizations.

Consider where your marketing stack touches these AI platforms. A CDP integration consuming the OpenAI API likely runs inside a GitHub Actions pipeline. Your chatbot infrastructure almost certainly uses an npm or PyPI package several dependency layers away from Axios, mistralai, or guardrails-ai. Your AI content generation workflows—the ones that call Claude or GPT-4o via SDK—may be running inside the exact CI environment that the Shai-Hulud worm was engineered to credential-harvest. If any developer on your MarTech team installed guardrails-ai@0.10.1 between May 11 and takedown, every secret accessible from that environment—GitHub tokens, AWS IAM keys, Vault credentials, Kubernetes service account tokens—was at risk of exfiltration to api.masscan[.]cloud.

The deeper problem is misplaced institutional confidence. Marketing and procurement teams have increasingly used AI lab safety documentation as a proxy for comprehensive trust in an AI tool. If OpenAI released a system card, if Anthropic participated in AISI evaluations, if a model passed capability benchmarks, the implicit conclusion was: this product is vetted. But AISI’s evaluation framework covers four domains: cyber capabilities via CTF challenges, chemistry and biology knowledge via expert-written questions, agent autonomy in software engineering tasks, and safeguard robustness against jailbreaks. AISI’s own researchers acknowledged plainly: “We remain acutely aware of the potential gap between how advanced AI systems perform in our evaluations versus how they may perform in the wild.” None of those evaluation categories probe whether the model’s publishing pipeline was using a floating CI tag on March 31.

Gray Swan AI’s red team platform—which focuses on input/output filtering, prompt injection, agent tool access vulnerabilities, and agentic system protection—is thoroughly scoped to deployed model behavior. The build pipeline that got the model to production is not in scope for any of those services.

This creates a specific and measurable organizational risk for marketing technology leaders. You may have completed vendor security questionnaires, reviewed responsible AI documentation, and received clean answers on model-level safety. None of that coverage extends to the artifact pipeline. The incidents of the past 50 days are software delivery events, not model events—and your marketing technology is software delivered through the same CI/CD infrastructure that was breached.

There is also a direct operational disruption risk. OpenAI’s certificate rotation required all users of ChatGPT Desktop, Codex, and Atlas to update their applications by May 8 or lose access entirely. Marketing teams using Codex inside content pipelines or ChatGPT Desktop as a daily productivity tool faced a hard-stop deadline with no workaround. The operational exposure had nothing to do with model performance, safety alignment, or prompt injection. It was a supply chain failure in a build system.

For agencies managing AI-integrated client stacks, the risk surface is multiplied. Each client environment is a separate blast radius. If your agency’s shared CI infrastructure or shared npm environment was running compromised packages during the Shai-Hulud campaign window, the credential exposure may span multiple client accounts simultaneously. The attack’s specific targeting of .claude/ directories—used by Claude Code in developer workflows—suggests the threat actor had a clear picture of which developers would have the most valuable credentials.

The Data

The four incidents, their verified attack vectors, and their scope across the 50-day window:

Sources: Socket.dev Axios incident, Socket.dev TanStack incident, Anthropic GitHub advisories, The Hacker News, The Register May 15, 2026, VentureBeat

The pattern is stark when laid out in sequence: three of the four incidents directly exploited CI/CD infrastructure—not application code, not model behavior, not API endpoints. The one self-inflicted failure was a packaging configuration error that shipped in a production PyPI release. The attack surface is the software delivery layer.

The OIDC exploitation in Shai-Hulud deserves particular attention. The worm did not steal an npm token. It requested an OIDC JWT from GitHub’s token endpoint, exchanged it for an npm publish token via npm’s trust federation, and used that scoped, legitimate credential to publish malicious packages under the real maintainer’s identity—complete with valid SLSA Build Level 3 provenance attestations. Standard integrity checks passed because the provenance was genuine. This is the attack pattern that current red team frameworks are structurally unable to catch: it operates inside the trust model rather than against it.

Real-World Use Cases

Use Case 1: Marketing Automation Agency Running AI Pipelines on GitHub Actions

Scenario: A mid-size performance marketing agency has built an in-house AI content pipeline: a GitHub Actions workflow installs the anthropic SDK and several open-source AI utility libraries, runs a generation script, and pushes output to a CMS. The pipeline runs 20 times daily across client accounts.

Implementation: The workflow installs packages with caret ranges (^0.86.0). Any new version matching the range is automatically pulled on the next run. When guardrails-ai@0.10.1 was published by the Shai-Hulud worm on May 11, any workflow run between that publish and takedown automatically executed the malicious preinstall hook—harvesting GitHub Actions secrets, AWS metadata endpoint credentials, and Vault tokens from the runner environment. The hook ran with the same IAM permissions as the workflow itself.

Expected Outcome: Within a single pipeline run, the attacker captures AWS keys, GitHub PATs, and potentially production CMS API tokens. The agency’s entire publishing infrastructure becomes accessible from attacker-controlled endpoints. Multiple client environments are simultaneously exposed if the agency uses shared CI runners. Recovery requires rotating every secret across every affected environment—a multi-day incident response exercise, not a patch.

Use Case 2: In-House MarTech Team Using ChatGPT Desktop and Codex

Scenario: An enterprise marketing team of 40 people runs ChatGPT Desktop on Mac for daily writing tasks and uses a Codex-powered GitHub Actions integration to auto-generate A/B test variants for landing pages. The Codex integration was configured eight months ago and is treated as stable infrastructure.

Implementation: After the April 11 OpenAI certificate rotation disclosure, the team needs to update ChatGPT Desktop on 40 machines before May 8. The Codex CI workflow used a pinned reference to the OpenAI client library—but if it was pinned to axios@1.14.1 (the compromised version), it ran trojanized code from March 31 through discovery. That workflow had write access to the repository and access to all GitHub Actions secrets, including production deployment credentials.

Expected Outcome: Teams that audited GitHub Actions workflows immediately after the April 11 disclosure, rotated all secrets, and updated to patched dependencies contained the exposure. Teams that focused only on the desktop app update deadline—the visible user-facing remediation—without auditing their CI pipelines may have been running compromised tooling for six weeks after the initial poisoning.

Use Case 3: SaaS MarTech Vendor Shipping an AI Memory Feature on the Anthropic SDK

Scenario: A MarTech SaaS company built a “persistent memory” feature for its AI assistant product using the Anthropic Python SDK’s local filesystem memory tool, shipping in their v3.2 release in March 2026. The feature runs in Docker containers inside the company’s shared cloud infrastructure.

Implementation: The team installed anthropic>=0.86.0 before CVE-2026-34450 and CVE-2026-34452 were patched. In their Docker base image—which uses a permissive umask setting, standard in most base images—memory files were created world-writable. Any other process running in the same container could read or modify persisted agent conversation history, including sensitive marketing data, CRM context, and customer segment information passed to the model. The TOCTOU race condition in the async implementation additionally opened a symlink-swap window for sandbox escape in any container with write access to the memory directory.

Expected Outcome: The data exposure was passive—no active attacker required to trigger it. Any container breakout, co-located malicious process, or compromised sidecar service in the same pod could access memory files. The fix (upgrading to anthropic>=0.87.0) is a one-line change, but the vendor must also determine which customer conversations were persisted to affected versions and whether any regulatory notification obligations apply. Contracts built on AI vendor security certifications do not typically cover packaging-level CVEs in the AI SDK layer.

Use Case 4: B2B Agency Using Vendor Questionnaires to Evaluate AI Platforms

Scenario: A B2B demand generation agency is evaluating an AI copywriting platform for a Fortune 500 client with strict InfoSec requirements. The client’s security team issues a vendor questionnaire covering model safety, bias testing, adversarial evaluation methodologies, data handling practices, and responsible AI frameworks. The platform’s vendor references an OpenAI system card, AISI evaluation results, and a Gray Swan commercial red team engagement.

Implementation: The questionnaire covers everything in the standard AI safety evaluation matrix and receives complete, accurate answers on all model-level questions. It does not ask whether the vendor pins CI dependencies to specific commit hashes, whether their GitHub Actions workflows enforce pull_request_target review gates on fork inputs, whether they have a minimum package release age policy, or whether they audit third-party package publishes before accepting new versions into their dependency graph. The vendor passes the questionnaire and gets procurement approval.

Expected Outcome: Three months later, the vendor’s CI pipeline auto-pulls a compromised version of a widely-used AI utility library. GitHub Actions secrets are harvested, including credentials with access to the marketing automation environment where the Fortune 500 client’s campaign data is processed. The questionnaire delivered confidence on the wrong threat model. Model safety documentation and supply chain security are not the same coverage.

Use Case 5: Marketing Ops Team Running Localization on MistralAI

Scenario: A global e-commerce brand’s marketing ops team automates product description localization using the Python mistralai client library. The pipeline runs nightly, processing 2,000 SKU descriptions across eight languages. The team installed mistralai six months ago and has not updated since—the lockfile shows a pinned version that preceded the compromise.

Implementation: The lockfile does not pin to mistralai@2.4.6—it was pinned to an earlier version. However, when a team member ran pip install --upgrade mistralai to access a new translation endpoint during the Shai-Hulud campaign window, the auto-upgrade pulled the compromised version. Each nightly localization run thereafter executed credential-harvesting code on import. AWS IAM credentials used to access the product catalog S3 bucket, and any GitHub tokens in the runtime environment, were exfiltrated with each pipeline execution.

Expected Outcome: Teams subscribed to Socket’s real-time monitoring would have received an alert within hours of the compromise—Socket flagged mistralai@2.4.6 almost immediately after publication. Teams treating their AI dependencies as set-and-forget infrastructure ran compromised code for the campaign’s full duration. The specific risk for marketing ops teams: the credentials used to read product catalog data typically also have write access to the same buckets. An adversary with those credentials could modify product data at scale.

The Bigger Picture

What these 50 days reveal is a structural divergence between how AI security is governed and where attacks are actually landing.

The current AI safety evaluation stack—system cards, AISI capability benchmarks, commercial red team engagements—was built to answer one question: what will this model do when prompted adversarially? That is a legitimate question, and the evaluation infrastructure built around it is genuinely useful for understanding model-level risk. AISI’s Inspect framework, Gray Swan’s arena competitions, OpenAI’s system card methodology—all of these produce real signal about model behavior under adversarial conditions. None of them are designed to surface a compromised postinstall hook in a transitive npm dependency.

This gap is not unique to AI. The SolarWinds breach in 2020 exploited exactly the same blind spot—targeting the build system rather than the deployed application. The xz-utils backdoor in 2024 targeted a CI maintainer’s trust and a dependency chain with hundreds of millions of downstream users. The difference in the AI context is that organizations are now using model safety documentation as a comprehensive proxy for supply chain trust. System cards and safety evaluations were never designed to certify a CI/CD pipeline. Marketing teams that equate the two have a misalignment between their risk model and their actual exposure.

The incentive structure reinforces the gap. AI labs publish system cards and undergo safety evaluations partly for regulatory positioning, partly for enterprise sales credibility. Those evaluations are visible, documentable, and produce clean answers in procurement questionnaires. Pinning CI dependencies to commit hashes and implementing minimum package release age policies are invisible to the customer and generate no procurement leverage. The market currently rewards model-level safety documentation over infrastructure-level supply chain hygiene—which is exactly why four incidents hit the top names in AI in under two months without any of them being flagged by standard evaluation frameworks.

The velocity of the AI software ecosystem amplifies the risk further. When model providers ship SDK updates weekly, when AI utility packages like guardrails-ai are in active development with frequent releases, and when GitHub Actions pipelines pull latest versions on every run, the attack surface is constantly expanding. The Shai-Hulud worm exploited characteristics intrinsic to a high-velocity software ecosystem: trust in maintainer identities, automated OIDC publishing mechanisms, and downstream pipelines configured to auto-accept new versions from trusted sources. The more aggressively a marketing team has adopted AI tooling, the more entries they have in the dependency graph that adversaries are actively targeting.

The competitive intelligence dimension is worth flagging for marketing leaders specifically. When credential-harvesting code writes to .claude/ directories—as the Shai-Hulud worm did explicitly—the target is the developer’s full working environment. That includes repository access, which may contain campaign strategy documents, audience segment configurations, A/B test results, and competitive positioning materials checked into infrastructure-as-code repositories. The attack surface is not just the API keys; it is everything the pipeline touches.

What Smart Marketers Should Do Now

1. Audit your AI SDK versions against all four incidents’ affected ranges today.

This is a one-hour task with definitive answers. Check whether any environment in your stack ever ran mistralai@2.4.6, guardrails-ai@0.10.1, axios@1.14.1, or axios@0.30.4. Verify your anthropic Python SDK version is >= 0.87.0 on every deployment that uses the memory tool. Check for router_init.js in any node_modules directory from the May 11-15 window. If you find affected versions in your lockfiles or deployment logs, treat the environment as compromised: rotate every secret that was accessible from those runners—GitHub tokens, AWS keys, CMS credentials, Vault tokens, Kubernetes service account tokens. Do this before completing any other item on this list.

2. Pin all CI dependencies to commit hashes or exact digests, not floating version tags.

OpenAI named the root cause in their own post-incident statement: floating tag, no minimum release age. This is a mechanical fix. For GitHub Actions: replace tag references (@v3) with commit SHA references (@abc1234). For npm: use npm ci with a committed lockfile rather than npm install. For PyPI: use hash-verified pinning in requirements.txt or poetry.lock. For any third-party GitHub Action in your AI workflows specifically—Actions that install AI SDKs, run model calls, or access AI APIs—pin to exact commits first. This single practice eliminates the entire class of attack that compromised OpenAI’s signing pipeline and would have caught three of the four incidents in this cluster.

3. Update your AI vendor questionnaires to explicitly probe supply chain and CI infrastructure.

The standard AI safety questionnaire does not cover the attack surface that produced four incidents in 50 days. Add these specific questions: Does your organization pin all CI/CD dependencies to exact commits or digests? Do you enforce a minimum package release age before accepting new third-party versions into production pipelines? Are all GitHub Actions workflows that access production credentials gated against pull_request_target fork abuse? Do you maintain SLSA Build Level 2 or higher provenance on your published packages—and have you audited that provenance wasn’t issued through compromised maintainer credentials? Any vendor who cannot answer these questions has uncovered supply chain risk, regardless of how thorough their system card or AISI evaluation participation is.

4. Treat .claude/ and .vscode/ directories as monitored persistence vectors.

The Shai-Hulud worm specifically targeted .claude/ and .vscode/ directories to survive reboots and environment resets. This was a deliberate choice—developers using Claude Code and VS Code with AI extensions are high-value targets with elevated credentials and direct paths to production infrastructure. Establish a verified baseline of expected files in both directories across all developer machines that install third-party AI packages. Add these paths to endpoint monitoring rules. Any unexpected script or binary in these directories on a developer machine that ran npm install during the May 11-15 window should be treated as a persistence artifact from an active compromise.

5. Subscribe to real-time package security monitoring for every AI library in your stack.

Socket’s automated detection flagged the compromised Axios package within 6 minutes of publication. The Shai-Hulud TanStack compromise was identified and documented within hours. The information was available—but only to teams monitoring the right feeds. Set up alerts for your entire AI dependency graph: anthropic, openai, mistralai, guardrails-ai, langchain, llama-stack, and their first-order dependencies. Socket, Phylum, and GitHub’s Dependabot advisory integration all provide near-real-time notification. A 6-minute detection time is operationally meaningless if you only see the incident in a VentureBeat post six weeks later. The gap between detection and notification is where blast radius is determined.

What to Watch Next

The OIDC trust federation exploit pattern will proliferate in Q3 2026. The Shai-Hulud worm’s technique—using legitimate OIDC tokens to publish malicious packages with valid provenance attestations—is the most technically sophisticated element of this incident cluster, and it has been open-sourced. The Register reported on May 13 that TeamPCP published the worm’s source code to GitHub, where it spread widely through forking. Expect copycat campaigns in Q3 targeting other registries with OIDC publishing support: PyPI, RubyGems, Maven Central. Marketing technology vendors with AI-adjacent packages in these registries are on the target list.

MCP server packages are the next high-value attack surface. The Shai-Hulud campaign compromised @squawk/mcp@0.9.5, a Model Context Protocol server package. As MCP adoption accelerates across the AI tooling ecosystem—connecting AI agents to databases, APIs, and marketing automation platforms—the MCP registry represents a uniquely dangerous target. MCP servers run with elevated permissions inside AI agent workflows, with direct access to tools, data sources, and APIs that most npm packages never touch. Watch for supply chain attacks specifically targeting MCP packages by Q3-Q4 2026.

SLSA Build Level 3 is no longer a sufficient trust signal alone. The Shai-Hulud worm produced malicious packages with valid SLSA Build Level 3 provenance because the attacker hijacked a legitimate publishing pipeline rather than creating a fake one. The SLSA working group is expected to publish updated guidance addressing this class of attack—where provenance is genuine but the build system was compromised—in Q3 2026. Until that guidance is published, treat SLSA provenance attestations as necessary but insufficient for AI toolchain packages specifically.

Regulatory response to AI software supply chains is accelerating. The combination of high-profile incidents and earlier DoD supply chain risk designations involving AI companies signals that AI software supply chain security is moving from a technical concern to a procurement and regulatory requirement. NIST guidance updates covering AI software supply chains and Executive Order follow-on rulemaking are expected in H2 2026. Marketing technology teams at companies with federal contracts or in regulated industries—finance, healthcare, insurance—should begin tracking these developments now and mapping current dependency management practices against emerging compliance requirements.

Bottom Line

Four supply-chain incidents in 50 days—hitting OpenAI directly twice, Anthropic through a self-inflicted SDK packaging failure, and the broader AI ecosystem through a sophisticated worm campaign—exposed a structural gap that the AI safety industry has not yet closed. System cards, AISI evaluations, and commercial red team engagements answer one question: what will this model do when adversarially prompted? None of them cover whether the CI pipeline that published the model’s SDK was using a floating version tag, or whether the async memory tool shipped with world-writable default permissions. For marketing teams, the immediate actions are concrete: audit affected version ranges now, pin CI dependencies to commit hashes, add supply chain questions to every AI vendor questionnaire, and subscribe to real-time package monitoring for your AI dependency graph. The incidents themselves are recoverable. The gap between “passed AI safety evaluation” and “verified supply chain integrity” is the actual vulnerability—and it will be exploited again before any current evaluation framework is updated to cover it.