PHP's Unpatched Critical RCEs (CVE-2026-109618, CVE-2026-109619): What's Confirmed and What Isn't

Most security advisories tell you what's wrong and how to fix it. This one is unusual because the two things arrived separately, and out of order. PHP's security team announced an emergency release for two critical bugs, both rated as severe as a vulnerability score gets, but withheld every technical detail until the fix was ready. Then the details leaked anyway, a day early, along with a working exploit tool. By the time you read this, PHP may have already shipped the fix. The gap between what PHP has confirmed and what independent researchers have reported is the most important thing to understand right now, because they are not the same list.

What PHP itself has actually said (tier one, confirmed)

PHP's security team posted an announcement on October 20, 2026, titled "Upcoming Critical PHP Security Release." The full operative text is short enough to quote directly:

That's it. No CVE numbers. No affected version list. No description of the bug class. PHP deliberately withheld those details, which is normal practice for a severe, unpatched vulnerability: publishing exploit-relevant specifics before a fix exists just hands attackers a head start. The release was scheduled for Wednesday, October 21, 2026, at 14:00 UTC.

What leaked, and who's reporting it (tier two, unconfirmed by PHP)

The plan to withhold details didn't survive contact with the internet. According to multiple independent write-ups, information about the embargoed bugs leaked on October 20, a day before the scheduled release, along with a screenshot of an exploit tool. Once that happened, several security research firms published their own analyses, and this is where the CVE numbers and technical details actually come from.

Read that table as a confidence gradient, not a wall of equally solid facts. The CVE numbers and the broad severity are about as solid as unofficial reporting gets, since they're consistent across multiple independent firms. The exact affected version range and the in-the-wild exploitation claim are each resting on thinner evidence. Don't make irreversible decisions, like taking production systems offline for days, based on the shakiest items in that list without also checking PHP's actual release once it's out.

Why "just change a config setting" doesn't work here

Most PHP vulnerabilities can be partially contained with a config change while you wait to patch. This one is different, and that difference is the main reason it's gotten this much attention.

• If the reported mechanism (a use-after-free in memory handling) is accurate, this is a bug in PHP's own C code, not in how your application uses PHP. No amount of application-level validation reaches it.
• PHP core developer Gina Peter Banyard has publicly stated that patching is the only real mitigation, according to researcher write-ups of the leak.
• The commonly circulated stopgap, setting session.upload_progress.enabled to 0 in php.ini, closes one plausible path but multiple sources are explicit that it is not confirmed to fully eliminate the risk.
• Because the vulnerable code reportedly runs during PHP's own request parsing, before your application code executes, request-level defenses like a WAF rule matching a specific exploit pattern can be evaded by variations the rule doesn't anticipate.

What to actually do, right now

1. Check what PHP version every internet-facing system you run is actually on. Not what you think it's on: actual runtime version, including inside containers and serverless functions, which often lag behind what's patched on the host.
2. If you can take internet-facing PHP services offline or put them behind an authenticated access path until the patch is available, that's the highest-confidence mitigation. Not every team can do this; if you can, it's worth the disruption for a CVSS 9.2 unauthenticated RCE.
3. If you can't go offline: set session.upload_progress.enabled = 0 in php.ini, .user.ini, or .htaccess as a partial stopgap, understanding it isn't guaranteed complete.
4. If you're behind a CDN or WAF, check whether your provider has shipped rules targeting this vulnerability class and enable them, while treating any single vendor's rule as incomplete coverage rather than a fix.
5. Patch the moment the official PHP release is available. Don't wait for a maintenance window on a CVSS 9.2 unauthenticated RCE with public leak activity.
6. If you're on PHP 8.1 or earlier, you are on an end-of-life branch and will not get an official fix. Upgrading to a supported branch (8.2 or later) is the only real path off this exposure, for this bug and every future one.

# Check the actual running PHP version (not just what's installed)
php -v

# Check across all running containers using PHP
docker ps --format '{{.Names}}' | xargs -I{} docker exec {} php -v 2>/dev/null

# Check whether session.upload_progress is currently enabled
php -i | grep -i upload_progress

# Disable it as an interim stopgap (edit php.ini directly, then restart php-fpm / apache)
# session.upload_progress.enabled = 0

# Confirm the setting took effect
php -i | grep 'session.upload_progress.enabled'

# After patching, confirm the version actually changed everywhere
php -v | head -1

If you were already exposed: what to hunt for

Because embargoed details leaked and a proof-of-concept exists, the responsible assumption for any internet-facing PHP system with a long uptime is that you may have been probed or worse, not just as of this week, but since the leak first circulated. If your systems handle anything sensitive, don't wait for a confirmed breach notification to start looking.

• Look for unexpected PHP files in upload directories, temp directories, or anywhere your application writes user-supplied content, especially files with recent modification times that don't correspond to a known deploy.
• Check for new or modified admin users across any system with a PHP-based admin panel (CMS platforms, e-commerce backends, internal tools).
• Review outbound connections from PHP worker processes for anything unexpected: unfamiliar destinations, unusual ports, or connections initiated outside normal application behavior.
• Check web server and PHP-FPM error logs for repeated crashes or worker restarts around the same request pattern. Researchers have noted that failed exploitation attempts against this bug class tend to crash the PHP worker rather than fail silently, which is itself a signal worth investigating.
• If you have WAF or CDN logs, look for unusual multipart/form-data POST requests, particularly ones with malformed or oversized boundaries, which is the general shape of request this vulnerability class interacts with.

The bigger picture

PHP still runs a large share of the web. Whatever the exact affected version range turns out to be once PHP's own advisory publishes, a CVSS 9.2 unauthenticated RCE in the interpreter itself, not in a plugin or a specific application, is as serious as this category of bug gets. The embargo leak is its own lesson: coordinated disclosure exists precisely to give defenders a head start over attackers, and when that head start gets cut short, the sensible response isn't panic, it's falling back to the things that work regardless of exact technical details: know your exposure, reduce it where you can, patch the moment a real fix exists, and verify rather than assume. We'll update this piece once PHP's official release and advisory are out with confirmed CVE mappings, affected versions, and fixed versions.