Six of this week's eight fixes sat outside your package manager

Six of the eight vulnerabilities and incidents we published this week could not be closed by a fully updated operating system. Run apt upgrade or dnf upgrade on a server that hosts any of them, watch it report nothing left to install, and the vulnerable code is still there: compiled into a language runtime, sitting in a trust store the OS never opens, waiting behind an application's own updater, or planted beside a Python package as a startup hook.

That is a measurement problem before it is a patching problem. Most operators judge a host by one question, "is it up to date?", and answer it with the one tool that knows how: the distribution's package manager. This week that tool could see two of the eight.

Our desk reached a logged decision on 5,812 events in the seven days to October 27 and flagged around 30, by our tracking, as showing signs of exploitation. The two products that appeared most often in that triaged set were the Linux kernel, with 234 entries, and Chrome, with 229. Both arrive through channels operators already trust to run on schedule: the kernel package and the browser's auto-updater. The volume sat where the tooling is strong. The eight we judged worth publishing mostly sat somewhere else.

Group the week by the process that actually delivers each fix and the split is two through the OS package (PHP and Apache Tomcat, and only where they were installed from distro packages), two in copies bundled inside another runtime (Brotli and GitLab), two behind a vendor's own updater (Plex Media Server and Siemens Software Center), one in a runtime's private trust store (Oracle Java), and one through a language registry and container image (LiteLLM). The sharper detail is which ones were live. The three items with confirmed activity in the wild, Plex and Siemens (both added to CISA's Known Exploited Vulnerabilities catalog on October 20) and the poisoned LiteLLM release, all sit outside the package manager.

A library CVE is a list of copies

The Brotli decoder flaw, CVE-2026-111497, reads like a single-package bug. It is not. The decoder is compiled straight into Node.js and into .NET, Bun, PHP's Windows builds and the Python wheels as separate copies, so the distribution's libbrotlidec update protects only programs that link the system library dynamically. Every other copy waits for its own runtime release, and then for a restart.

GitLab CVE-2026-110264 is the same shape one layer up. The flaw sits in Onigmo, the regex library inside the Ruby runtime GitLab runs on, so the fix arrives as a GitLab release, not a system Ruby update. It also shows how copies multiply over time: a server upgraded on October 12 to close the earlier regex RCE was still exposed to this one until the October 21 build.

The practical consequence is that "patched" is a property of each copy, not of the host. A server can be clean by its package manager and dirty by its processes. Inventory has to follow the binaries that actually run, not the manifests that were installed.

Trust lives in more than one store

After researchers reported that eMudhra's intermediate keys could be derived, Chrome, Firefox, Safari and Edge pushed blocks between October 17 and 21, and operating-system vendors followed. Oracle's CVE-2026-114820 alert followed on October 24, and it had to: Oracle's JDK and GraalVM carry their own cacerts keystore that no OS update touches, as the Oracle Security Alert for the issue makes plain.

Here is the trap we think most coverage missed. Several distribution OpenJDK builds point Java at the system certificate bundle, so on those hosts an OS trust update does flow through. That is exactly why the assumption feels safe. It holds for the distro JDK and silently fails for the vendor JDK, the GraalVM install, or the runtime bundled inside an application's own directory, often on the same server. A trust decision is only as current as the store each process actually reads.

The updater you pinned was carrying the fix

Plex Media Server shipped build 1.43.3.10861 in early August. The four CVEs it fixed were disclosed in mid-October and, per CISA's KEV listing, were being chained for unauthenticated code execution soon after. For roughly two and a half months the only servers quietly protected were the ones left to update themselves. A Plex instance pinned in a container rebuilt on the owner's schedule, the configuration many careful operators choose for stability, sat exposed the whole time.

Siemens Software Center shows the opposite risk. Siemens says existing installations update on next startup, which is reassuring only if the client actually starts and reaches its update service. Even Apache Tomcat, the most conventional package on the list, shipped fixed builds on October 12 and published the details on October 20. Anyone who waited for the advisory before acting started eight days behind.

Our read: pinning is a reasonable trade, but it transfers a job to you. Once you freeze an application's own updater, you are responsible for reading its release notes, not just the CVE feeds, because the fix frequently ships before the advisory explains why it matters. We made a related argument in July, that the patch is not the finish line. This week adds a step before it: knowing which channel the patch even travels on.

Removing the package did not remove the code

The poisoned LiteLLM 1.107.0 release was on PyPI between 11:39 and 13:23 UTC on October 21, and in the project's Docker images until 14:20 UTC. According to Microsoft Threat Intelligence, it dropped .pth and sitecustomize.py files outside the LiteLLM directory. Python runs those on every interpreter start, so rolling back to 1.106.2 removes the package and leaves the stealer.

That is the limit of every package manager in one sentence: its idea of "installed" ends at its own file list. Anything an install script writes elsewhere is invisible to the tool you would use to check it.

Inventory the copies, then watch the files

None of this is fixed by a better patch cadence. It is fixed by asking the host, not the package database. For a self-hosted fleet, that means five concrete checks.

1. List every runtime that vendors native code. On each server, record node -p process.versions (it reports the bundled Brotli version), dotnet --list-runtimes, and the Brotli package in every Python virtualenv, not just the system interpreter. Compare against the fixed versions, not the distro's.

2. Restart what still maps old code. A process started before an update keeps the deleted library in memory. grep -l '(deleted)' /proc/[0-9]*/maps lists processes still running replaced code; restart them.

3. Find every Java trust store. find / -name cacerts -type f usually returns more than one. Check each with keytool -list for the eMudhra and emSign roots, and treat each as its own patch target.

4. Keep a register of what you pinned. Containers, media servers, Git forges, anything whose own updater you disabled. Each entry needs an owner who reads its release notes, because that is where the fix appears first.

5. Watch the places installs should not write. New .pth or sitecustomize.py files in site-packages outside a deploy window, new libraries in Plex's Codecs directory, or an unsigned DLL appearing next to a signed vendor binary in a user-writable path. Patching tells you the hole is closed. File integrity and process lineage tell you whether something came through it first.

The package manager was never an inventory. It is one of several delivery channels on a typical server, and this week it carried two of the eight fixes that mattered. Build the list of the other channels before next week's advisories decide it for you.