If you've been following along, you've already read about PHP2Shell (and how to fix it), the Node.js Brotli bug, and the NGINX, GitLab, Go and eMudhra fixes. The week isn't over. Java and Python now have their own urgent updates, PHP has published a new advisory with no patch yet, and the NGINX fix still hasn't reached the Linux packages most servers install from.
Here's what is still open as of October 24, explained without the jargon, and exactly what to do about each one.
The 30-Second Version
- Java: the regular October 20 update is not enough. You need the October 21 emergency builds (versions ending in .0.2, or 8u511) to stop trusting the broken eMudhra certificates.
- Python: upgrade pip to 26.2.2 and certifi to 2026.10.19 in every environment. Updating your OS alone doesn't fix pip.
- PHP: a new bug (CVE-2026-115560) has no patch yet. Set now.
- NGINX: on Ubuntu and Debian 12, does not fix it yet. Use the official nginx.org packages or apply the config workarounds below.
Java: Two Updates in Two Days, and the First One Isn't Enough
Java powers a huge amount of business software: banking and ERP systems, Spring Boot APIs, Android back-ends, Elasticsearch, Jenkins and Kafka. This week it got two separate updates.
1. The routine October update (October 20)
Oracle's quarterly Critical Patch Update fixed 55 Java SE vulnerabilities. None is rated critical: the highest scores are 7.5, and most are medium. The ones that matter most for servers involve processing untrusted images and fonts (Java 2D, CVE-2026-91415) and a bug in the HotSpot JIT compiler (CVE-2026-83378) that can affect any Java code.
2. The emergency fix (October 21): CVE-2026-91403, CVSS 9.1
A day later, Oracle issued an out-of-band Security Alert. This is the eMudhra certificate problem again. As we explained in our last update, eMudhra's signing keys were so weak that anyone could recover them and make fake HTTPS certificates. Browsers blocked them within hours. Java didn't, because Java keeps its own list of trusted certificates and, by default, doesn't check whether a certificate has been revoked.
In plain terms: a Java app that calls an API over HTTPS could be tricked into talking to an attacker's server while believing it's the real one. That could expose passwords, API keys and customer data.
The trap: Oracle lists the October 20 builds (such as 21.0.13 and 17.0.21) as affected. If you patched on the 20th, you still need to update again.
Which Java builds are fixed? (as of October 23)
- Oracle JDK: fixed in 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.33.0.2 and 8u511 b32.
- Azul Zulu: fixed builds shipped October 21.
- OpenJDK upstream: fix committed and tagged for 27, 25, 21 and 17; 11 and 8 not yet tagged.
- Eclipse Temurin, Amazon Corretto, Microsoft Build of OpenJDK: no fixed build announced yet. These are the ones most Docker images use, including the popular images.
- Red Hat / RHEL: system Java uses the OS certificate store, so updating covers it.
What to do if your JDK isn't fixed yet
- Replace the certificate blocklist: download the updated file from Oracle or Azul, check its SHA-256, back up the old one, and copy it into (Java 8 calls it ). Copy it as a file; don't paste it into a text editor.
- Restart every Java application using that runtime. The new list only loads at startup.
- Don't rely on deleting the emSign root with keytool. Some of the bad certificates chain through a different (Sectigo) root, so removing emSign alone leaves you exposed.
- Optionally turn on revocation checking with , but test it first: it adds network lookups to every new HTTPS connection.
- Rebuild Docker images, jlink runtimes and GraalVM native binaries. They carry their own copy of the certificate list.
Python: Your Operating System Update Doesn't Fix pip
Python's eMudhra exposure comes from a small detail most people never think about. Python tools usually trust certificates from a package called , not from your operating system. And pip always loads its own built-in copy of certifi in addition to the system list, with no supported way to turn that off. So even a fully updated server keeps trusting the bad certificates through pip until pip itself is upgraded.
On October 20 the Python ecosystem shipped fixes across the board, including new CPython releases (3.15.1, 3.14.9 and 3.13.17). The minimum safe versions are:
- pip 26.2.2
- certifi 2026.10.19
- uv 0.13.4, conda 26.9.4, pixi 0.82.1
What to do
- Upgrade pip and certifi in every virtual environment, not just the system Python. Each venv has its own copy.
- Because an old pip can't be fully trusted to download the new one, the Python team recommends installing the pip 26.2.2 wheel directly from files.pythonhosted.org and checking its SHA-256 before using it to upgrade everything else.
- For uv, run after updating your system certificates.
- Rebuild Docker images with the build cache disabled. As of October 21 the official images still shipped the old pip; until they update, point pip at the system bundle with .
- On a Mac with the python.org installer, update pip and certifi inside the framework install too. It bundles its own certificates.
Also worth catching up on: the October 1 Python releases (3.10.22, 3.11.17, 3.12.15, 3.13.16, 3.14.8) fixed several security bugs, including ways a malicious archive could write files outside the folder you extract it to (, CVE-2026-19672). Python 3.10 is now end-of-life, so plan to move off it. And if you use SAP's Cloud SDK for Python, CVE-2026-89111 (CVSS 10) can leak your OAuth client secret: upgrade to 0.55.1 or later.
PHP: A New Advisory With No Patch Yet
Two days after the PHP2Shell patches, on October 23, the PHP project published an advisory for a separate remote code execution bug: CVE-2026-115560. There's no emergency release. The fix will arrive in the next routine PHP release.
The good news: it only affects apps with an unusual setup, where the session format is set to one type in the config and switched to another in code before the session starts, with session upload progress turned on. PHP itself calls this unlikely, and no attacks have been reported.
The fix today: add to your php.ini and restart PHP-FPM or Apache. If you already did this as a PHP2Shell stopgap from our fix guide, you're already covered. Very few apps use upload progress bars built on this feature, so it's safe for almost everyone.
Meanwhile, attacks on PHP2Shell itself have grown fast. Cloudflare saw tens of thousands of attempts within 45 minutes of disclosure and millions by October 22. Attackers are trying to install a Mirai-based botnet called "Potassium". Censys estimated more than 34 million PHP services were still unpatched on October 23. No confirmed break-ins yet, but if you haven't upgraded to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, this is your sign.
NGINX: Fixed Upstream, Not Yet on Ubuntu or Debian 12
NGINX released 1.30.6 and 1.31.7 on October 14, fixing the five bugs we covered last time. F5 followed with patches for NGINX Plus and the Ingress Controller. But most servers don't install NGINX from nginx.org. They use their Linux distribution's package, and those haven't caught up:
- Ubuntu 26.04, 24.04, 22.04 and 20.04: listed as "needs evaluation", with no fixed package.
- Debian 12 (bookworm): still vulnerable to all five.
- Debian 13 (trixie): fixed on October 21 (DSA-6575-1).
So if you run Ubuntu or Debian 12 and ran this week, your NGINX is very likely still vulnerable. None of these bugs is known to be exploited, and each needs a specific feature switched on, but here's how to close the gap:
- Switch to the official nginx.org repository, which already has 1.30.6, or use a patched container image.
- Or apply F5's workarounds until your distro catches up: avoid inside blocks and the variable; use named regex captures in ; and turn off or SSI if you don't need them.
- Keep an eye on Ubuntu's and Debian's security notices so you can return to normal packages once the fix lands.
Other Things That Won't Fix Themselves
- Node.js 20 is end-of-life and will never get the Brotli fix. Move to 22, 24 or 26.
- curl and git on macOS don't check certificate revocation, so they need manual workarounds for eMudhra.
- WordPress sites using UpdraftPlus: the vendor was breached and UpdraftCentral connection keys were stolen. Update to 1.26.12 or 2.26.12 and check every site for unknown admin users and plugins.
- emSign certificates: Chrome removes the emSign ECC Root CA G3 on October 27. If your site's certificate chains to it, replace it now or visitors will see errors.
Your Weekend Checklist
- PHP: confirm you're on a fixed version, then set session.upload_progress.enabled=0.
- NGINX: run nginx -v. On Ubuntu or Debian 12, switch to nginx.org packages or apply the workarounds.
- Java: move to the October 21 builds or drop in the updated blocked.certs, then restart.
- Python: pip 26.2.2 and certifi 2026.10.19 in every environment and image.
- Everything: update ca-certificates and rebuild containers without cache. Restarting an old image is not patching.
We'll keep updating as the remaining fixes land. If you want a second pair of eyes on your servers, Team Peham can help. Book a 30-minute call.
Sources & References
- BleepingComputer: PHP shares mitigation for new unpatched RCE
- The Hacker News: PHP2Shell exploit attempts hit millions
- Emergency Java update: CVE-2026-91403
- Safeguard: eMudhra Java fix, JDK vendor builds and workarounds
- Java October 2026 CPU: 55 Java SE CVEs
- Python.org: Information for Python users regarding eMudhra
- Python Insider: October 1 security releases
- Ubuntu: CVE-2026-15176 status
- Debian security tracker: nginx
- BleepingComputer: F5 out-of-band NGINX patches
- The Hacker News: SAP Cloud SDK for Python CVSS 10 flaw
