osbytes

Search

Find posts, projects, and members.

← back to blog

Dirty Frag, stable kernels, Google’s AI exploit tracker, and the TanStack npm supply-chain compromise

2026-05-11by@osbytes7 min read
#linux #kernel #security #threat-intelligence #ai #npm #supply-chain #github-actions

TL;DR

  • LWN reported stable releases 7.0.6 and 6.18.29 earlier today carrying Kim's patch for CVE-2026-43500, the second vulnerability named alongside Dirty Frag and the Copy Fail 2 thread; the same page surfaced a follow-up concern that the fix might still be incomplete in some configurations.
  • Google's Threat Intelligence Group published a long-form update today describing criminal and state-nexus use of LLMs across discovery, weaponization, and orchestration, including a case where GTIG says it has high confidence a zero-day exploit against an open-source admin tool was model-assisted, with mass exploitation planned and disrupted after vendor coordination (GTIG: AI vulnerability exploitation and initial access).
  • TanStack published a detailed postmortem the same evening (UTC) on a compromise of dozens of @tanstack/* packages: malicious versions reached the npm registry after a pull_request_target workflow, poisoned Actions cache reused on main, and OIDC minted for trusted publishing was extracted from runner memory and used to POST to the registry outside the normal publish step (TanStack npm supply-chain compromise postmortem, GHSA-g7cv-rxg3-hmpx).

If you only patch one thing this week, it is probably the kernel line. If you ship JavaScript to production, read the TanStack advisory and postmortem before the next dependency bump. If you brief executives, the Google document is the primary text worth reading slowly, not the second-hand headlines alone.

Dirty Frag: from broken embargo to stable tags

Dirty Frag is a chained local privilege escalation affecting widely deployed Linux configurations; public discussion traces to Hyunwoo Kim's May 8 post on oss-security explaining that coordinated disclosure had been broken and publishing mitigation advice alongside exploit code (oss-security: "Dirty Frag: Universal Linux LPE"). The note ties the issue to in-place decryption paths in xfrm ESP and RxRPC and compares how broadly the flaw applies to the earlier Copy Fail discussion.

The stable tree moved on the same beat. LWN summarized Greg Kroah-Hartman's 7.0.6 and 6.18.29 releases as carrying Kim's patch for CVE-2026-43500, the second vulnerability named with Dirty Frag, alongside the Copy Fail 2 thread, and it closed with the blunt guidance readers expect from that venue: upgrade (LWN: "Two stable kernels with Dirty Frag fixes"). The same page carries a subscriber comment pointing at follow-up traffic on netdev suggesting the fix may still be wrong in edge cases; treat that as a signal to watch your vendor's errata, not as a verdict you can act on without your own kernel team's read of the thread (netdev follow-up cited in LWN comments, LWN comment thread).

For operators the actionable shape is familiar: kernel bugs with public exploit code compress the calendar between "interesting research" and "someone is scanning your fleet." Kim's mail included a modprobe mitigation disabling esp4, esp6, and rxrpc where unloading is operationally tolerable; stable kernels are the cleaner answer when you can take the reboot.

Google's AI exploit brief: facts in the paper, headlines aside

The GTIG post reads less like a press release than like a long brief with section headers you can skip to. The executive summary claims a maturing shift from experiments to industrial-scale use of generative models in adversary workflows, then walks through vulnerability research, malware obfuscation, agentic tooling, information operations, LLM access abuse, and supply-chain pivots through ML stacks (Google Cloud Threat Intelligence blog).

What the document itself states: GTIG describes partnering with a vendor on disclosure, walks through a Python exploit that implements a two-factor authentication bypass on a popular open-source web admin tool, and says the actor planned mass exploitation that proactive work may have headed off.

What is interpretation: When Google writes high confidence that the exploit was model-assisted, it lists concrete style signals in the PDF (verbose docstrings, formatting that resembles training-corpus Python, a stray CVSS figure in the script that does not line up cleanly with the vuln metadata). Readers should treat model-assisted as an inference justified by those signals, not as a reproducible benchmark. Keep that separate from plainly quotable specifics you can photocopy straight out of Google's text.

Readers evaluating similar claims elsewhere get a workable recipe: cite lines you can excerpt, distinguish bugs in HTTP-layer auth logic from memory corruption, note where scanners miss semantic mistakes humans (or tooling) spot, and keep caveats beside anything that boils down to vibes.

The same document names operational chatter worth tracking on its face: persona-shaped jailbreaks, curated vulnerability dumps wired into plugins, CVE-shaped prompts piled into campaigns, experimentation with automation stacks next to lab targets. None of it replaces patching; it explains why patching races more parallel probing than fifteen years ago.

TanStack on npm: registry writes without a stolen npm password

TanStack’s postmortem reads like trace evidence: timeline in UTC, named workflow files, and an explicit chain (Pwn Request-style pull_request_target, cache poisoning across fork and base contexts, then memory extraction of an OIDC token already permitted for npm trusted publishing). Malicious optionalDependencies pulled a payload during install; maintainers deprecated affected versions and engaged npm to pull tarballs. Detection came quickly from an external researcher; TanStack is blunt that it had no internal alerting on its own publishes.

The shape is an old supply-chain lesson in different packaging: what npm serves rests on which CI jobs can mint trusted publish credentials, not only on maintainer laptops and whoever still types npm passwords by hand. Kernel bugs and compromised packages can both land mid-week reading as boring version bumps unless you skim the advisory.

For teams asking what to do before the next incident report lands, the low-regret .npmrc controls are mostly about reducing automatic execution and surprise dependency edges. In CI jobs that only lint, test, or bundle and do not require package install hooks, set ignore-scripts=true so compromised lifecycle scripts do not auto-run during install (npm config: ignore-scripts). In production image builds where optional extras are not required, set omit=optional to reduce exposure to exactly the optionalDependencies path used in this compromise class (npm config: omit). Where your package manager supports it, enforce a minimum release age (for example, delaying installs of just-published versions) so brand-new malicious publishes have less chance of landing in your pipeline before signals emerge (pnpm minimumReleaseAge). Keep those settings scoped per environment (for example, a repo-level CI .npmrc and a stricter production build profile) so you are not breaking legitimate developer workflows just to feel secure on paper.

Same day, three separate fires

Kernel, threat intel, and npm are unrelated vendors. They still reward the same habits: read primaries, patch on evidence, assume public PoC or published chains shrink the comfortable window.

  • Kernel: track stable tags and your vendor’s errata when disclosure wobbles.
  • GTIG: treat "model-assisted" as a labeled claim tied to quoted artifacts in the PDF, not as a universal law of "AI cyber."
  • npm: audit pull_request_target, cache reuse, and OIDC publish paths; use the .npmrc levers spelt out in the TanStack section above when your pipeline can tolerate them.

Pick the section that matches your job; do not try to average the three into one thesis.

Sources