CVE
CVE-2026-89418, CVE-2026-45321, CVE-2025-39682, CVE-2026-53266, CVE-2025-39964
CWE
CWE-674, CWE-506, CWE-416
Affected Surface
- Node.js services that still run google-protobuf 4.0.2 or earlier on attacker-controlled protobuf input
- Organizations still scoping May TanStack exposure, especially where developer laptops or CI runners may have installed the malicious 11 May package versions
- Linux hosts running kernel builds affected by newly KEV-listed CVE-2025-39682, CVE-2026-53266, or CVE-2025-39964
Welcome to Corgea’s weekly briefing. The briefing covers the most important security findings and research from the week.
This edition covers research and exploitation updates surfaced between Tuesday, 16 September and Saturday, 19 September 2026, excluding incidents Corgea had already covered before this window opened.
Top Article
CVE-2026-89418: google-protobuf lets unknown group fields recurse until Node.js crashes
The cleanest new package-security finding in the window is CVE-2026-89418 in google-protobuf. It is not a maintainer compromise, and it is not limited to one framework. The bug sits in the generated JavaScript protobuf runtime itself.
The vulnerable control flow is easy to reason about. A generated deserializer feeds attacker-controlled bytes into BinaryReader. If the reader encounters an unknown field with wire type START_GROUP, skipField() calls skipGroup(), which loops and calls skipField() again without any nesting limit. A payload full of nested group markers therefore turns unknown-field skipping into unbounded recursion and ends with a stack-overflow RangeError.
That makes the issue a good fit for AppSec teams rather than only language-runtime maintainers. The affected surface is any Node.js service, worker, or gateway that parses hostile protobuf bytes with google-protobuf 4.0.2 or earlier. The fixed version is 4.0.3. The full write-up is in the new google-protobuf article.
More news
CrowdSec’s final report sharpens the May TanStack blast radius
The most important supply-chain follow-up in the 16-19 September window is not a new npm publish. It is CrowdSec’s 18 September final incident report tying a September source-code leak back to the May TanStack compromise.
CrowdSec says an attacker used a compromised former employee account on 22 May to clone about 170 private repositories, plus 130 or more repositories that were already public. The company says no code, build pipelines, infrastructure, or databases were altered, but the disclosure still included 83 user email addresses and information tied to 51 potential investors. The important lesson for defenders is timing. The malicious TanStack package versions were removed in May, yet the downstream impact did not become public until September.
That is why the TanStack wave still matters four months later. A package compromise does not end when the registry yanks the release. It ends when every exposed workstation, CI runner, token, and repository scope has been hunted, rotated, and re-scoped. For the original incident mechanics, revisit Corgea’s earlier article on Mini Shai-Hulud and the TanStack compromise.
Other news
- CISA added three Linux kernel flaws to KEV on 18 September: CVE-2025-39682, CVE-2026-53266, and CVE-2025-39964. They warrant urgent patching on exposed or multi-tenant Linux hosts, but the current public reporting is stronger on exploitation status than on application-facing exploit mechanics, so we did not force a separate Corgea article in this run.
- Our requested scan of CISA, NVD, Aikido, Wiz, Socket, Endor Labs, and broader web search did not surface a second brand-new npm, PyPI, Maven, or Linux package compromise first disclosed in the 16-19 September window that cleared the bar for a separate Corgea write-up without becoming duplicative.
- If you are reviewing adjacent package-manager risk from earlier this month, the most relevant carry-over remains Corgea’s recent work on pnpm install-time path traversals, JFrog Artifactory active exploitation, and the 13 September briefing.
From research to remediation
Check whether this pattern exists in your codebase
Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.