Open Source Security: Kernel CVE Floods Meet CI-Stealing Worms

Two kinds of risk landing at once

Open source security this October is being shaped by two separate pressures, and both are getting worse. The first is the steady stream of patches. Linux distributions are now shipping kernel updates that each close hundreds, and sometimes more than a thousand, CVEs. The second is newer and more aggressive. Attackers have stopped just uploading lookalike packages to public registries. They are taking over the release pipelines of real projects and using them to spread self-replicating malware.

These two problems call for different responses. Taken together, though, they show where the open source trust model is under the most strain: in the gap between code that is fixed upstream and code that actually reaches running systems.

Kernel advisories measured in the thousands

The size of recent kernel advisories is hard to overstate. In a single day of releases, nine distributions pushed security updates: AlmaLinux, Debian, Fedora, Oracle Linux, Red Hat, Rocky Linux, Slackware, SUSE and Ubuntu. Oracle's Unbreakable Enterprise Kernel advisory alone resolved more than 1,100 CVEs, and Ubuntu's NVIDIA kernel update covered about 950.1312 Ubuntu's own notice list matches that count. USN-8875-2 for the NVIDIA kernel on 22.04 LTS lists a few named CVEs "plus 948 others," and USN-8887-3 for 24.04 LTS lists more than 1,000 additional identifiers.1 Debian has made similar headlines: a kernel update for Debian 13 "Trixie" was reported to patch more than 1,300 CVEs.19

Livepatching has kept up with the volume. Ubuntu's LSN-0122-1 put 150 CVEs into one livepatch that most systems can apply without rebooting. Its range runs from a use-after-free in the DLM filesystem code to a logic flaw in the XFRM ESP-in-TCP subsystem that developers nicknamed "Fragnesia."11 SUSE kept issuing kernel live patches across several SLE 15 service packs during the same period, all rated Important.15

Coverage of these numbers mostly agrees on what happened and differs on what it means. Roundup writers treat the giant rollups as items to schedule time for, saying admins should "block off time" for the Oracle releases.13 Hong Kong's computer emergency response team rated a batch of 25 SUSE kernel CVEs as only Medium risk, while noting they could allow privilege escalation, security-restriction bypass and information disclosure.2

The more useful reading, in this analysis, is that a CVE count no longer tells you much about urgency. Since the kernel project began assigning CVEs to a broad range of fixes, totals in the thousands mostly reflect bookkeeping. The bugs that matter are a small subset. One example is CVE-2025-10263, an Arm TLB flaw that turns up in Ubuntu's GCP and Oracle kernels and can escalate privileges or bypass memory protections.15 Another is CVE-2023-20585, an AMD SEV-SNP issue that could let a hypervisor-level attacker corrupt encrypted guest memory, which matters most for confidential-computing deployments.1517 Teams that triage by headline totals will spend effort in the wrong places. Teams that triage by exposure, meaning which subsystems and hardware they actually run, will fare better.

The userland flaws are just as busy

Outside the kernel, the shared libraries under nearly every Linux desktop and server are getting regular fixes. On October 12 alone, Ubuntu shipped updates for FFmpeg, libx11 and the Perl DBI module that reach back as far as 14.04 LTS.1 SUSE fixed a use-after-free in libpng's handling of incomplete compressed text chunks, which SUSE scored as high as 8.2.3 It also patched seven out-of-bounds reads in libXi.10 XOrg Server 21.1.25 and Xwayland 24.1.14 shipped to fix flaws that could cause heap corruption or denial of service.19

Some of these advisories trace back to the software supply chain. SUSE's Helm update fixed bugs in the Go dependencies Helm pulls in, not in Helm's own code: a signed integer overflow in klauspost/compress, an information disclosure in OpenTelemetry-Go, and a blind SSRF in oras-go.4 SUSE's virtiofsd fix also came from a dependency, the Rust "time" crate, whose RFC 2822 date parser could exhaust the stack.8 Advisories like these show how far a single library bug can spread through tools that never mention it.

Release pipelines become the target

The more worrying development is on the package-registry side. On September 23, an attacker published malicious versions of two packages from MemTensor, the developer of the MemOS LLM memory framework: an OpenClaw plugin on npm and the MemoryOS library on PyPI.21 The MemOS project has about 11,500 GitHub stars.23 Both releases carried a Go implant called sckit. It searches developer home directories for credentials and sends them to servers under the skyleen[.]fr domain.21

What stands out is how the attacker got in. According to SafeDep's reconstruction, the attacker did not phish a maintainer. They pushed commits that made MemTensor's own GitHub Actions release jobs hand over npm and PyPI publishing tokens before anything was published.21 On the npm side, a script injected through the BASH_ENV variable ran ahead of the real publish step, passed the token to the implant, then deleted itself and failed the job on purpose.21 On PyPI, a capture run was followed about two hours later by a commit that let the project's own workflow build and upload the poisoned package with its real token.21 The attacker also mixed clean and malicious npm releases on the same day. That is why one security vendor told users to pin to older baselines instead of trusting "latest."28

Accounts mostly agree on the implant's capabilities. Aikido, SafeDep, Socket and StepSecurity all describe a cross-platform stealer that goes after cloud, registry, source-code and developer credentials.25 Aikido's list includes AWS keys, GitHub and GitLab tokens, npm and PyPI tokens, Hugging Face and Vault tokens, and Stripe keys.29 The implant also contains templates for copying itself into other npm packages, Python packages and GitHub Actions workflows.26 Aikido said it had not yet found public workflow files infected by the worm.29 The Hacker News reported it was unclear whether projects beyond MemTensor were affected, and later updated its report to say the malicious versions had been removed from both registries.25

A year-long pattern, not a one-off

The MemTensor incident fits a clear 2026 trend. TuxCare counts six confirmed supply chain campaigns across npm, PyPI, Go modules and Packagist between March and July. That includes Mini Shai-Hulud, a self-spreading npm worm, and TrapDoor, a campaign that ran across several registries.22 TrapDoor placed 34 malicious packages, with more than 384 versions, on npm, PyPI and Crates.io starting May 19. It used a different execution hook for each ecosystem, and its targets were developers working in crypto and AI.24 It also dropped .cursorrules and CLAUDE.md files hidden with zero-width characters to manipulate AI coding assistants.24 In May, the TanStack compromise turned 42 @tanstack packages into a worm that reached more than 170 packages on npm and PyPI. Strobes calls it the first supply chain worm to ship malicious packages with valid, signed provenance.30

The accounts disagree on two points, and both have practical consequences. The first is timing. TuxCare argues the main attack surface in 2026 has moved to install time, through postinstall hooks, import-time execution and build scripts.22 sckit doesn't fit that pattern. It runs whenever the package is invoked, not at install, which daily.dev notes lets it slip past scanners that focus on install-time behavior.2329

The second is provenance. One TrapDoor checklist names enforced npm provenance attestation as one of three controls that would have stopped that campaign entirely.24 TanStack shows the limit of that claim. Provenance proves where a package was built, so if the build pipeline itself is compromised, a malicious package can still carry a valid attestation.30 MemTensor makes the same point from a different angle, since the malicious PyPI wheel was built and uploaded by the project's legitimate workflow.21

What this means for defenders

The conclusion here is that build-system trust is now the weakest point in open source security, more than registry hygiene. Signing, provenance and scanners at publish time remain useful. They do not help much when attackers control the CI job that creates the signatures. The defenses that hold up better are the less glamorous ones. They include scoping and rotating publish tokens, pinning third-party actions to commit SHAs, isolating install steps from the network, and watching for releases that don't match any commit in the repository. That last check is how a researcher first spotted the MemTensor compromise.2130

Distributions are hardening their own base layers at the same time. Ubuntu 26.10, due October 15, ships a signed, slimmed-down GRUB with a smaller attack surface, TPM-backed encryption on machines without a hardware root of trust, and dbus-broker as the default message bus, with AppArmor mediation kept in place.14 Those changes matter, but they protect the operating system, not the developer credentials and CI tokens that recent campaigns have gone after. That threat lives in pipelines and package registries, and protecting it is still mostly up to the projects that run them.