CVE
CVE-2026-53612, CVE-2026-53613, CVE-2026-53614, CVE-2026-98260, CVE-2026-98256, CVE-2026-89754, CVE-2026-80775, CVE-2026-98385, CVE-2026-97941
CWE
CWE-346, CWE-863, CWE-494, CWE-506, CWE-367, CWE-416
Affected Surface
- npm packages that still had unvalidated Trusted Publishing bindings against GitHub or GitLab repository slugs that became claimable before the first successful publish
- Arch Linux and derivative systems that installed packages uploaded by the `marchos1as` AUR account during the 13-14 October 2026 window, especially the fake helper package `yyay`
- Linux hosts with unpatched util-linux mount flows or unpatched kernels from the Infinity Core disclosure, especially developer workstations, self-hosted CI runners, and shared build infrastructure where low-privilege code can already execute
Welcome to Corgea’s weekly briefing. The briefing covers the most important security findings and research from the week.
This edition covers research published from Tuesday, 13 October through Tuesday, 20 October 2026, excluding the items already summarized in the interim 15 October briefing. Once that overlap is removed, four uncovered English-language Corgea research posts remain in scope for this Tuesday handoff.
Top Article
SlugFest: npm Trusted Publishing let reclaimed GitHub slugs publish someone else’s package
Bloom Security deserves the discovery and public disclosure credit for SlugFest. It leads this week’s briefing because it was a registry authorization failure, not a single poisoned tarball. Before the first successful publish locked a binding to durable repository identity, npm Trusted Publishing accepted an owner/repo slug and workflow basename. If a maintainer later renamed, transferred, or deleted that repository, an attacker could reclaim the old slug, mint a valid publish credential, and ship a provenance-signed release for the wrong project. Bloom’s scan found more than 1,500 exposed packages, including security, auth, and cryptography projects.
Read it beside Corgea’s research on @subql/common, the Tensorlake npm compromise, and @7nohe/openapi-react-query-codegen. Those incidents differ in the initial breach, but they all show the same limit: a green provenance check only proves who published a package, not whether the source tree or publish authorization path still deserved trust.
More news
yyay turned a checksum-clean AUR helper into root-level malware execution
Archcanary deserves the first preserved public warning credit here, while BleepingComputer and CtrlAltNod captured details after the packages disappeared. The fake yyay package copied the real yay source tarball and checksum, then hid the malicious step in a root-run .install script that fetched hellscripter/install-scripts through web.archive.org. A cautious user could still verify the source archive, see the checksum pass, and get rooted during install anyway.
It is worth reading this one with the Angular typosquat wave, Atomic Arch’s AUR takeover, and the August AUR malware wave. The common thread is install-time execution on Linux hosts that often already hold SSH keys, npm tokens, and maintainer credentials.
Infinity Core: six Linux kernel bugs raise the value of any local foothold
Infinity Core deserves the disclosure credit for the six-bug kernel cluster posted to oss-security on 17 October. It belongs high in this briefing because it changes how defenders should evaluate any recent Linux foothold. The bugs sit across exec, signal delivery, page walking, futexes, scheduler cache accounting, and SLUB, but the operational takeaway is simpler: a low-privilege process on an unpatched host can have a much easier path to root, a broader path out of containers, or a kernel panic that takes shared infrastructure down.
For related host-escalation context, compare it with util-linux mount TOCTOU flaws, Dirty Frag, Linux UDPv6 fraggap, and Linux SCTP ASCONF UAF. If you are triaging Linux developer workstations or self-hosted runners after a package incident, those articles belong in the same reading stack.
Other news:
- util-linux mount TOCTOU flaws let user mounts reach root: the public credit here stays with the upstream util-linux maintainers and the advisory trail around
CVE-2026-53612,CVE-2026-53613, andCVE-2026-53614. The bug class is easy to miss because the mount request starts as a legitimate user-authorized flow. The risk appears when/usr/bin/mountvalidates one path, then later acts on a different object after a rename or legacy mount fallback. Read it with Infinity Core and CVE-2026-93207 if you are scoping how much damage a low-privilege Linux foothold can do this month.
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.