October 21 Security Roundup: PHP2Shell's Backstory, Java, HTTP/3, Node, Railway and OVH

21 October 2026 was a long day for security teams. PHP patched two critical vulnerabilities, Oracle issued an out-of-band alert for Java, Node.js closed ten vulnerabilities and Railway disclosed access to customer secrets. The day before, OVHcloud’s command-line tool had been shipped with malware.

This post is a roundup of that day. Each section says what happened and what you should do. The technical deep dive on the PHP bugs is in a separate post: Two Critical RCEs in PHP: CVE-2026-109618 and CVE-2026-109619. Video: Pixel Shorts · Yesterday, in short.

At a glance

PHP2Shell: from 2024 to today

2024: the first sign

According to the PHP Foundation, the first signs appeared in 2024. A PHP core developer contracted by the Foundation noticed the out-of-memory (OOM) problem while fixing another issue from Quarkslab’s 2024 audit. No concrete attack vector was found at the time, and issues with clear impact took priority.

In the following months the security team drafted several fixes. As The Next Web reports, one broke backward compatibility, one introduced a new DoS risk and one required changes across thousands of extensions. The small, consensus-driven team could not pick one. The Foundation called this a “structural failure” and says decisions will now be made by majority.

August 2026: rediscovered with AI

This summer two teams independently found a working attack path:

• Calif: According to the Wall Street Journal, a Calif researcher found the flaw with GPT-5.6 Sol as part of OpenAI’s “Patch the Planet” program.
• Wiz Research: According to Wiz, the first finding came on 19 August, unauthenticated RCE was confirmed against Drupal and WordPress on 20–21 August, and the reports went to PHP on 24 August. Wiz says it used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol.

PHP acknowledged the reports on 21 September and started a coordinated fix.

17–21 October: the leak and the patch

Names of alleged leakers are circulating on social media. I could not find them in any primary source, so they are not here.

How to apply the PHP fix correctly

1. Check the PHP your site actually runs

If a server has several PHP versions, php -v in the terminal shows only the default CLI. The PHP-FPM pool or Apache module serving your site can be a different version.

php -v                 # CLI PHP
php-fpm8.4 -v          # the FPM your site uses (adjust the version)
ls /etc/php/           # all installed versions (Debian/Ubuntu)

If unsure, put a temporary phpinfo() page on the site, check “Server API” and the version line, then delete it.

2. Update the package

Debian and Ubuntu (distribution packages): Distributions usually backport security fixes into the old version number. If the number did not change, look for the CVE in the changelog.

sudo apt update
sudo apt install --only-upgrade 'php8.4*'
apt changelog php8.4-fpm | grep -E '109618|109619'

Ondřej Surý’s repository (deb.sury.org): This repository follows PHP’s upstream version numbers. It also has new packages for 7.4, 8.0 and 8.1 dated 21 October. I checked their changelogs myself: the patch was written by PHP developers and carries the note “Minimal mitigation for EOL version”. It buys time for 8.1 and older; the real fix is moving to 8.2 or later.

AlmaLinux: Patched packages are in the AlmaLinux 8, 9 and 10 repositories.

sudo dnf update 'php*'

Docker: Rebuild your image on the new version tag (e.g. FROM php:8.4.27-fpm) and restart the containers. A docker pull alone is not enough; containers started from the old image keep running old code.

Shared hosting and control panels: Your provider applies the update. Ask in writing which version you are on.

3. Restart

PHP-FPM workers and Apache processes run the code they loaded into memory. The fix is not live until they restart.

sudo systemctl restart php8.4-fpm
sudo systemctl restart apache2      # if you use mod_php

4. Interim settings

The interim settings php.net lists (session.upload_progress.enabled = 0, memory_limit = -1, a low post_max_size, and fatal_error_backtraces = 0 on PHP 8.5) do not make a server safe; they close some paths. Details are in the earlier post. If you don’t use upload progress, keeping it off after patching does no harm; I left it off on my server.

On my own server

I installed the builds that landed in the CloudPanel repository on the evening of 21 October: 8.5.12 (17:29) and 8.4.27 (18:56). The check on 22 October:

$ php-fpm8.5 -v
PHP 8.5.12 (fpm-fcgi) (built: Oct 21 2026 07:08:08) (NTS)
$ php-fpm8.4 -v
PHP 8.4.27 (fpm-fcgi) (built: Oct 21 2026 07:08:08) (NTS)

Java: CVE-2026-91403

According to OpenJDK’s 21 October advisory, eight intermediate CA certificates were compromised. The component is security-libs/javax.net.ssl (JSSE), scored 9.1 under CVSS 3.1. JDK 8, 11, 17, 21, 25 and 27 are affected; OpenJFX is not. Oracle issued it as a separate Security Alert, outside the regular October CPU.

• Standalone JDK/JRE: Update to the latest release.
• If you can’t update: Drop in the new $JDK_HOME/lib/security/blocked.certs (blacklisted.certs on JDK 8; back up any entries you added), or enable revocation checking:

-Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true

• OS-provided OpenJDK: On Debian, Ubuntu, Fedora, Red Hat and Arch, updating the system certificates is usually enough. Update FreeBSD and Homebrew packages directly.

If you don’t know how many JDKs you have, count them first: CI agents, IDEs and runtimes bundled inside applications each need their own update.

HTTP/3: QPACK memory amplification

FoxIO published a class of memory amplification flaws in QPACK, HTTP/3’s header compression (summary by The Hacker News). Affected stacks cap the compressed input but not the decoded header list, or apply the cap too late. Seven of the ten HTTP/3 stacks tested were affected. No authentication is needed; a small request can make the server allocate far more memory.

Interim mitigations for unpatched stacks: don’t expose Bun’s HTTP/3 server, run mitmproxy with --set http3=false, and set a limit with max_field_section_size in h3. No in-the-wild exploitation was reported at disclosure.

Node.js: 21 October security releases

On 21 October Node.js fixed 10 CVEs across the 22.x, 24.x and 26.x lines: 4 high, 3 medium, 3 low. The fixed releases are 22.23.4, 24.22.1 and 26.12.1.

High severity:

• CVE-2026-111497: out-of-bounds write in the Brotli decoder that allows remote code execution (RCE).
• CVE-2026-105483: TLS certificate hostname check bypass when an IP address is written with fullwidth digits.
• CVE-2026-106069: TLS hostname check bypass when the host loosely resolves to an IP address.
• CVE-2026-105482: dns.resolve truncates names containing a NUL character.

Among the medium ones, CVE-2026-106074 stores the entropy cache of crypto.randomUUID() and randomInt() in snapshots and SEAs, so processes started from the same snapshot can repeat values. Node.js 20 and 25 are end-of-life and got no fix; apps on those lines need a major upgrade.

node -v

Railway: access to environment variables

On 21 October Railway detected anomalous activity in the systems that store customer environment variables. According to GitGuardian’s summary, an unauthorized party may have accessed encrypted values and, for some, decrypted ones. Railway links it to a series of attacks on platform companies aimed at compromising AI inference providers.

Per the status page, builds were paused platform-wide, OAuth sessions were invalidated, bucket credentials were rotated and on 22 October at 04:17 UTC all Railway API tokens were revoked. On the morning of 22 October, Pro and Enterprise builds were running slowly and Hobby builds were not yet enabled.

If you use Railway:

1. Rotate keys in the upstream services first (AWS, GCP, GitHub, AI providers), then update the values in Railway.
2. Rotate sealed variables too; the disclosure doesn’t say whether they were in scope.
3. Rotate private registry credentials.
4. Review the logs of services that use these credentials. Railway published guides for AWS, GCP and GitHub.
5. Create a new Railway API token; the old ones no longer work.

Claims that crypto assets stored on Railway were also drained are circulating on social media; I could not confirm them from a primary source.

OVHcloud CLI: a supply-chain attack

According to BleepingComputer, attackers took over a developer’s GitHub account and replaced files in existing OVHcloud CLI releases. Versions 0.11.0 through 0.15.0 served malicious files on 19 October between roughly 14:47 and 16:21 (sources state the time zone differently; the window is about 94 minutes).

• The malware is an infostealer that collects secrets from disk. It includes a hidden preinstall.js loader and a second stage fetched through a Solana memo dead drop. OpenSourceMalware links it to an operation called GlassWorm.
• Affected platforms: macOS (Intel, ARM), Linux (x86_64, ARM64) and Windows x86-64. Builds from source and Docker images were not affected.
• The releases could be changed without passing CI/CD because GitHub’s release immutability setting was off. OVHcloud has turned it on.
• 0.10.0 and 0.16.0 are clean.

This is not a customer data breach; there are no reports of access to OVHcloud infrastructure or customer databases. But if you installed or updated the CLI in that window on 19 October, the advice from OVHcloud CEO Octave Klaba is clear: change every secret on that machine.

Today’s checklist

• PHP: is your site’s PHP-FPM on 8.5.12, 8.4.27, 8.3.36 or 8.2.35? If not, update, then restart PHP-FPM and Apache.
• PHP 8.1 and older: install the minimal patch and plan the move to 8.2 or later.
• Java: update every JDK/JRE or replace blocked.certs.
• HTTP/3: check your quic-go, quiche and lsquic versions; disable HTTP/3 on Bun.
• Node.js: 22.23.4, 24.22.1 or 26.12.1.
• Railway: rotate every environment variable, registry credential and API token.
• OVHcloud CLI: if you installed 0.11–0.15 on 19 October, rotate your secrets and move to 0.16.0.

Sources

• php.net · 21 October security releases
• PHP Foundation · Today’s PHP Security Release, and How We’re Strengthening PHP Security
• The Next Web · PHP knew about one of the flaws in 2024 but could not agree a fix
• Wiz Research · PHP2Shell
• AWS Security Blog · PHP2Shell exploitation prior to public disclosure in MadPot
• watchTowr · PHP2Shell FAQ
• The Hacker News · PHP Issues Emergency Patches
• AlmaLinux · Patched PHP packages
• packages.sury.org · php7.4 7.4.33-31, php8.0 8.0.30-25, php8.1 8.1.34-9 (21 October builds, debian/changelog)
• OpenJDK Vulnerability Advisory 2026/10/21
• The Hacker News · New QPACK Flaws Can Crash HTTP/3 Servers
• Node.js · October 2026 Security Releases
• Railway status · QH8L8B3E
• GitGuardian · New Railway Incident
• BleepingComputer · OVHcloud CLI releases backdoored on GitHub
• TechCrunch · The internet is having a very bad cybersecurity day