Everything, everywhere, all at once… the week software broke

It’s been an absolutely wild few days. If you work in software or security, you probably spent part of this week reading a security advisory and wondering whether it applied to you. Then another one. Then a third.

Between October 20 and 21, at least nine programming languages and six Linux distributions needed security updates. Most of us saw these as separate headlines: a certificate problem, a bug in PHP, a malicious Python package. Put them side by side, though, and it's hard to find an environment that came through untouched.

This post covers what to update now, why this probably won’t be the last week like this, and how to make the next one less of a fire drill.

The short answer

Do you need to update something? Almost certainly, yes.

The less obvious part is what. In every case, the fix is updating something you didn't write, and in some cases something you didn't know you had: a version of PHP in your Docker image, the certificate lists built into pip, uv, and certifi (which nearly every Python project relies on), or a private copy of those certificates tucked inside a library.

So instead of starting with the incidents, start with your stack.

Find your language

Find the rows that match what you run. If you're in more than one row (most of us are), you have more than one thing to update.

The certificate fixes keep coming, so check the disclosure site for the current list.

eMudhra: the certificates you can't trust

Eight eMudhra certificate authority keys were generated so badly that anyone can recover them, and six of them can be used to impersonate any website or service to software that still trusts them. Browsers already blocked them. Much of the rest of your software didn't.

Most of that table comes from a single incident, so it's worth taking a second to cover how certificates work.

When your code calls an API over HTTPS, the server shows a certificate to prove it is who it says it is. A certificate authority vouches for that certificate. Your code checks the certificate against a list of certificate authorities it trusts, and if the authority is on the list, the connection goes ahead.

Here's the catch: there isn't just one list. Your operating system has one. Python's certifi package has one. pip and uv carry their own (the Python discourse explains why, and how to update them safely). Node.js, Go, and Java each keep another, and some libraries ship a private copy inside the package. When one certificate authority goes bad, every one of those copies needs fixing separately.

So one bad authority means fixes in at least nine languages. Our research team found 25 fairly popular packages carrying a private copy like this, 11 of them already patched.

What to do: update to the fixed versions in the table above, rebuild your container images, and test that your code rejects the bad certificates. Read the full analysis for the fixed versions, a one-line test, and a script that finds hidden certificate lists.

PHP2Shell: the bug is in PHP itself

Two critical bugs in PHP itself (CVE-2026-109618 and CVE-2026-109619) can let an attacker run code on your server without logging in. Updating WordPress or its plugins won't fix it, because the bug isn't in them. And PHP often comes from a Docker base image or a hosting provider, not something you installed yourself.

What to do: upgrade PHP to 8.2.35, 8.3.36, 8.4.27, or 8.5.12, rebuild any images that include it, and ask your hosting provider whether they've patched. Read the full analysis for affected versions and remediation steps.

Node2Shell: a bug in… Node.js itself

Node.js disclosed its own runtime bug the same day. Node2Shell (CVE-2026-111497) is a bug in the code Node.js uses to unpack Brotli-compressed data, and it can let an attacker run code if your app decompresses data they control. As with PHP2Shell, the bug is in the runtime, so changes to your own code or packages won’t fix it.

What to do: upgrade Node.js to 22.23.4, 24.22.1, or 26.12.1 (there’s no fix for Node.js 20), then rebuild any images that include it. The Node.js security advisory has the details.

LiteLLM 1.107.0: malware that runs whether you use it or not

Version 1.107.0 of LiteLLM, a popular Python library for connecting to AI model providers, shipped with malware that steals cloud credentials, developer secrets, and AI tool logins. It runs every time Python starts, even if your code never imports LiteLLM. And on October 21, the latest, main-latest, and main-stable Docker images all pointed to it.

What to do: go back to 1.106.2. If Python ran anywhere 1.107.0 was installed, replace every key and password that machine could reach, and don't run Python or pip on it to investigate. Read the full write-up for indicators, safe detection commands, and a credential checklist.

So what?

We’d hate to suggest this is the new normal, but the honest truth is that, for at least a while, vulnerabilities in operating systems, open-source libraries, and critical tools like sandboxes will keep surfacing. It certainly can’t help to act like that’s true when you architect your operations and tooling. You would do well to build for the fire drill (or to prevent the incident from turning into a fire drill) rather than pretend that things haven’t fundamentally changed in the world of vulnerability discovery and exploitation. 

You need systems that let your teams perform critical tasks quickly and efficiently, without blowing through the entire quarter’s token budget. Let’s take a quick look:

Discovery and triage: Do you have an easy way to know what’s in every app and every container? Can you (or your robot helper) query it via an API to filter for the vulnerable components? Are you using them in a way that’s a true risk, or can you add it to the next update? 

Remediation: can your tooling tell you if upgrading to the shiny new fixed version will break your app? Is there an alternative, like wrapping the vulnerable component in some extra app code? Can you upgrade the base container to remove the problem easily? 

Reporting and attestation: Can you generate an SBOM and/or a VEX file for your customers and regulators to consume as part of your product assurance? 

Most organizations can do this today, but their processes have enough bottlenecks or manual processes to break at scale. Which is exactly when you need them not to break. 

So, in this (probably brief) window before the next apocalypse, we’d encourage you to look not just at what you did, but how you did it, and war-game what you would change if you knew this would happen twice a month. If you’d like to invite your local friendly Endor Labs team along to be part of it, we’ll bring the donuts. 

How Endor Labs helps (and where it can't)

This is an Endor Labs blog, so here's the part where we talk about what we do.

• Certificates. SCA scans report the advisories for affected packages like certifi and the Go standard library, and container scanning finds images with an outdated ca-certificates package. Our research team is also adding packages with hidden certificate lists to scan results as each one is confirmed. That work is ongoing, and the eMudhra write-up includes ready-made queries you can paste in today.
• PHP2Shell, Node2Shell. Container scanning finds images running affected PHP versions.
• LiteLLM. Threat Center flags which of your monitored projects may pull in the malicious release, and Package Firewall can block malicious packages before they install.

What we can't see: certificate lists on hosts, network appliances, IoT devices, and the third-party services you depend on. Private copies inside packages can also be hard to spot through dependency analysis alone until each one is confirmed. For those, you can use the curl test from our blog post.

You're also welcome to reach out to us directly, we're happy to help.