The Loop: TanStack npm Packages Compromised in Ongoing Mini Shai-Hulud Supply Chain Attack

TanStack, one of the most widely used React tooling ecosystems, was hit by a supply chain compromise affecting 84 published npm packages. The attack combined multiple CI/CD exploitation techniques: GitHub Actions pull_request_target abuse, cache poisoning across trust boundaries, and runtime extraction of OIDC tokens from workflow environments. Rather than relying on a single compromised maintainer token, the attacker used workflow execution paths to mint publish-capable credentials and inject malicious builds directly into npm releases.

The payload itself behaved like a staged CI credential stealer and worm. A large obfuscated JavaScript module (router_init.js) executed during install lifecycle hooks, harvesting secrets from GitHub Actions, npm, AWS, Kubernetes, and Vault environments, then exfiltrating via a decentralized Session network endpoint to reduce traceability. It also attempted propagation by modifying package metadata (optionalDependencies pointing to a GitHub-hosted commit) and abusing prepare hooks in git-based installs, effectively turning dependency installation into execution. Although detection and deprecation occurred quickly, the design meant any install window during the active publish period could result in full CI or workstation compromise. The implant also wrote itself into Claude Code's hook directory (.claude/settings.json) and VS Code's task runner — meaning a simple npm uninstall was not sufficient remediation.

The broader significance is that this was not a single-package incident but part of the “Mini Shai-Hulud” campaign, which shows a repeatable pattern: CI trust boundary abuse, ephemeral token theft, and self-propagating npm infection chains. The campaign has since expanded to affect OpenSearch, Mistral AI, and Guardrails AI packages across both npm and PyPI.

Econify’s take: This incident underscores that CI/CD systems are now a primary attack surface in modern open-source supply chains. The exploit chain demonstrates how non-obvious trust bridges like cache reuse, workflow triggers, and short-lived OIDC credentials, can be chained into a full compromise without ever touching a maintainer's credentials. The Claude Code persistence mechanism is worth calling out specifically: by writing into .claude/settings.json, the implant re-executed every time a developer used Claude Code in the affected directory, even after the package was removed. If your team uses TanStack, or any widely-consumed open-source dependency, this is a good moment to audit OIDC token scopes in your GitHub Actions workflows, review recent unexpected commits, and make sure secret rotation is part of your incident response playbook, not an afterthought.

OpenAI responds to TanStack supply chain attack with precautionary credential and signing key rotation

OpenAI’s response describes a downstream exposure stemming from the broader Mini Shai-Hulud supply chain campaign affecting upstream dependencies, rather than a direct compromise of OpenAI production systems, user data, or deployed model infrastructure. The investigation found no evidence of customer data access, system-level compromise, or modification of released software artifacts.

The impact was limited to a small number of internal developer environments where the malicious dependency executed, resulting in restricted credential exposure within repositories accessible to those systems. Two employee devices were affected, notably during a phased rollout of updated supply chain protections; those devices hadn't yet received the new configurations that would have blocked the malicious dependency. In response, OpenAI performed containment actions including session revocation, credential rotation, and engagement with third-party forensic support to validate scope and persistence. As a precautionary measure, OpenAI also rotated iOS, macOS, Windows, and Android application code-signing certificates and required macOS users to update desktop applications to maintain a trusted signing chain.

Importantly, the certificate rotation is explicitly preventive: there is no evidence of maliciously signed binaries, tampered releases, or customer-facing compromise. The action reflects a defense-in-depth response to upstream dependency risk, where compromise in the build ecosystem can force reassessment of trust anchors even when production systems remain unaffected.

Econify’s take: This incident highlights how supply chain risk now extends beyond dependency execution into software distribution trust layers. Even without direct production compromise, exposure in developer environments can cascade into signing infrastructure resets, a reminder that code-signing certificates deserve the same isolation and rotation discipline as production credentials. And an instructive detail is that OpenAI had the right controls in place. The two affected devices simply hadn't received them yet. For teams managing developer environments at any scale, that's a familiar risk - the gap between when a security policy is decided and when it's fully enforced.

What Cloudflare learned from using Mythos Preview

Anthropic’s Project Glasswing evaluates “Mythos Preview,” a security-focused LLM that Cloudflare ran against more than fifty of its own production repositories to understand how far AI-driven vulnerability research has evolved. The key finding is that frontier models are no longer limited to spotting isolated bugs—they are beginning to operate as end-to-end security reasoning systems that can identify weaknesses, combine them into exploit chains, and validate exploitability through code execution loops.

This changes the nature of automated security analysis. Instead of producing large volumes of speculative findings, Mythos Preview increasingly produces grounded results by iterating: it writes proof-of-concept code, tests it in controlled environments, adjusts hypotheses based on failures, and refines toward working exploitation paths. In practice, this collapses the traditional gap between “finding a bug” and “proving it matters,” which has historically been the main bottleneck in vulnerability triage.

The more important constraint Cloudflare highlights is not model intelligence but orchestration. Single-agent scanning produces shallow coverage and high noise (in part because a single agent session against a large repository can cover a fraction of the surface before context limits kick in), while structured multi-agent systems, separating reconnaissance, targeted hunting, independent validation, deduplication, and reachability analysis, dramatically improve both precision and throughput. The implication is that effective security AI is becoming less about prompting models and more about designing disciplined execution frameworks around them.

Cloudflare also pushes back on the industry's instinct toward speed. More than one team is now operating under a two-hour SLA from CVE release to patch in production, but Cloudflare's view is that patching faster doesn't change the shape of the pipeline that produces the patch. Skipping regression testing to hit that SLA tends to produce bugs worse than the ones being patched. The harder question, they argue, is what the architecture around the vulnerability looks like (defenses that sit in front of the application, limit blast radius, and enable simultaneous rollout) so that the gap between disclosure and patch matters less.

Econify’s take: The shift here is from AI as a scanner to AI as an exploit-capable reasoning layer. The real risk and value both move upstream into system design: whoever controls the workflow architecture (scope, constraints, validation, and execution boundaries) controls whether these models act as noisy assistants or as scalable vulnerability discovery engines. It's also worth naming the dual-use reality plainly - the same capabilities that accelerate defensive research will accelerate the attack side, and that asymmetry favors whoever builds the better harness first. Cloudflare's more contrarian point is also notable, where the answer to a shrinking attacker timeline isn't faster patching; it's building systems where the gap between disclosure and patch matters less. Security teams will increasingly differentiate not by whether they use AI, but by whether they can safely structure it before it becomes an automated attacker proxy.

TypeScript 7.0 Beta Moves to a Native Go-Based Compiler, Delivering Major Performance Gains

Microsoft has released TypeScript 7.0 beta, marking a major architectural shift: the compiler has been ported to Go, enabling native execution and shared-memory parallelism across parsing, type checking, and emit.

The result is a significant performance jump—up to ~10× faster than TypeScript 6.0 in large real-world codebases. Much of this comes from parallelized type-checking and project builds, with new controls for tuning worker concurrency in CI and local environments. For large monorepos, this meaningfully reduces build and feedback times.

Despite the rewrite, TypeScript 7.0 is designed to be behaviorally compatible with 6.0. Teams can run it side-by-side using tsgo, allowing validation against existing builds before fully migrating. The beta has already been validated against multi-million line codebases at companies including Bloomberg, Canva, Figma, Google, Slack, and Vercel, and the teams consider it stable enough for daily use today.

The release also formalizes several modern defaults: strict mode is now on by default, legacy module targets are removed, and ESM-first resolution is the standard path forward. This is less about syntax change and more about aligning projects with modern JavaScript infrastructure assumptions. Teams migrating from 5.x should note that the stable programmatic API won't be available until TypeScript 7.1 at the earliest, which may affect tooling that imports from typescript directly.

Econify’s take: This is less an incremental release and more a shift in compiler strategy. The gains are most immediate for CI-heavy teams and large monorepos, where TypeScript has historically been a bottleneck. The key work now is controlled rollout - running 7.0 alongside 6.0, validating parity, and introducing parallelism deliberately. The --checkers and --builders flags have a multiplicative effect on memory usage, so the right configuration depends on your machine and codebase rather than maxing out both. One other reason to pace the migration: the stable programmatic API won't land until 7.1 at the earliest, which means tooling that imports from typescript directly (typescript-eslint being the most common case) will need to stay on 6.0 for now.

Vercel internal access incident via third-party OAuth compromise

Vercel disclosed an internal security incident triggered by a compromise of Context.ai, a third-party AI tool connected to an employee account via OAuth. The attacker used that access path to take over the employee's Google Workspace account, then pivoted into their Vercel account. From there, they were able to pivot into a Vercel environment and subsequently maneuvered through internal systems to enumerate and decrypt non-sensitive environment variables. Vercel assessed the attacker as highly sophisticated based on their operational velocity and in-depth understanding of Vercel's product API surface.

Vercel states there is no evidence of npm supply chain tampering, production system modification, or exposure of customer-facing services. The impact appears limited to credential visibility and internal system enumeration rather than code or deployment manipulation. Notably, the non-sensitive environment variables affected are those not marked as "sensitive" in Vercel - values that decrypt to plaintext. Environment variables marked as sensitive were not exposed.

In response, Vercel engaged external incident response support, notified affected customers, and expanded monitoring and logging around environment variable access. The company also pushed stronger defaults and tooling improvements around secret management and deployment visibility.

Econify’s take: This is identity compromise turning into infrastructure access. The weak point isn’t Vercel itself—it’s the OAuth-connected tool chain sitting outside it. Once those integrations are trusted, they become indirect entry points into production-adjacent systems, making third-party app governance as critical as traditional secret security. It's also worth noting the practical control that would have limited the blast radius here: Vercel's sensitive environment variable feature protects values from being read even with valid credentials. Teams not using it should be.

Zooming out, this issue has a thread running through it. The TanStack compromise didn't start with a stolen password; it started with a CI trust boundary. OpenAI's exposure came through two employee devices that hadn't yet received updated protections. Vercel's breach entered through an OAuth-connected AI tool. None of these were frontal attacks. They were all lateral moves through systems that were trusted but not hardened. The pattern is consistent enough to be instructive: the perimeter has moved, and it now runs through your developer toolchain, your OAuth integrations, and your CI/CD pipeline. Security posture increasingly depends on how well you govern the things adjacent to your systems, not just the systems themselves.