PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 Close Two Critical RCEs

⏱️ Reading time: 9 min

The PHP security team has just released four emergency versions (8.5.12, 8.4.27, 8.3.36, and 8.2.35) to close two critical vulnerabilities that allow unauthenticated remote code execution. The official advisory leaves no room for doubt: updating is the only safe solution, and any server running PHP-FPM, mod_php, php-cgi, FrankenPHP, or LiteSpeed remains exposed until it does.

📑 En este artículo

1. TL;DR
2. What PHP Is
3. What Happened
4. Context and History
5. Technical Details
6. Impact of the Critical PHP Vulnerabilities in Production
7. What’s Next
8. Frequently Asked Questions
   1. Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?
   2. What makes mod_php exploitable in the face of these critical PHP-FPM flaws?
   3. Is adjusting php.ini enough if I can’t update PHP right away?
   4. Do PHP 8.1 and earlier versions receive this patch?
   5. How do I know if my server is still exposed to the unauthenticated PHP RCEs?
9. References

The highest risk hits mod_php. According to the PHP team itself, an exploit already exists that triggers the attack before a single line of application code runs. No framework, however hardened, can save a site if the interpreter running underneath it is vulnerable.

TL;DR

• PHP releases versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two critical unauthenticated RCEs.
• CVE-2026-109618 corrupts memory through an OOM handling flaw; CVE-2026-109619 reuses stale global state.
• The highest risk falls on mod_php, with a proven exploit that fires before any application code runs.
• Minimal backport patches were also released for PHP 7.4, 8.0, and 8.1, even though those versions no longer receive official support.
• There is no complete mitigation: updating is the only safe solution, according to the official advisory.

What PHP Is

PHP is the general-purpose server-side web development programming language, created in 1994 and maintained by the PHP Group. It runs behind blogs, online stores, and a large share of the world’s most visited sites, which makes the critical PHP vulnerabilities disclosed this week all the more serious.

The project maintains several active branches in parallel: 8.5, 8.4, 8.3, and 8.2, each with its own support and security schedule. That policy explains why the patch shipped the same day across four different version numbers instead of just one.

What Happened

The PHP security team confirmed that both flaws let a remote, unauthenticated attacker execute arbitrary code on the server. The first, identified as CVE-2026-109618, corrupts memory when out-of-memory (OOM) handling interrupts a request that’s only half-initialized; the subsequent cleanup then treats that invalid data as if it were valid. The second, CVE-2026-109619, lets the internal state of a previous request survive after its memory has already been freed, and a worker handling the next request can use that stale state before normal initialization resets it.

The advisory itself flags mod_php as the highest-risk scenario, since a proven exploit there can trigger the attack before any application code runs. PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed are also exposed: in short, any standard way of serving PHP in production.

Context and History

Unauthenticated PHP RCEs are rare: most of the project’s security reports fix memory leaks, denial-of-service issues, or flaws that require some prior configuration by the attacker. Two bugs of this caliber appearing together, with one of them already having a proven exploitation path against mod_php, is what pushed the team to release four versions on the same day instead of waiting for the usual monthly patch cycle.

The PHP Group simultaneously maintains the 8.5, 8.4, 8.3, and 8.2 branches under active support, plus a security support window for already-retired versions. PHP 8.1 and earlier stopped receiving official updates from the project, although some Linux distributions and LTS vendors still apply their own patches with a delay. Given the severity of this case, the security team also decided to release minimal backports for PHP 7.4, 8.0, and 8.1, aimed at anyone who compiles from source and doesn’t depend on a vendor with extended support.

Technical Details

The mechanism behind CVE-2026-109618 lives in how PHP handles exhausted memory. When PHP runs out of memory midway through processing a request, the engine interrupts execution and triggers cleanup of that request’s data. The problem is that the interruption can land exactly when that data is still half-built: the cleanup routine doesn’t distinguish between a complete structure and a half-initialized one, and ends up freeing or reusing pointers that were never properly allocated in the first place. An attacker who manages to force that memory exhaustion at the precise moment turns an error condition into an exploitable memory corruption.

CVE-2026-109619 is different. It doesn’t depend on a memory failure, but on a request’s internal state surviving longer than it should. PHP-FPM reuses worker processes across requests to avoid the cost of starting a new interpreter each time. If a request ends abnormally (for example, a fatal error while processing a file upload) without the worker fully clearing certain global state, the next request handled by that same worker can inherit data that isn’t its own. The advisory points to confirmed paths through session.upload_progress and, on PHP 8.5, through fatal error backtraces (fatal_error_backtraces).

; Partial mitigation while updating (does NOT replace the patch)
memory_limit = -1
post_max_size = 8M
session.upload_progress.enabled = 0
fatal_error_backtraces = 0 ; only applies on PHP 8.5

These four settings, applied via php_admin_value in the FPM pool or in the Apache configuration (never with ini_set() or .user.ini, since those run after request processing has already started), close the exploitation paths already confirmed by the PHP team. They don’t close variants that haven’t been discovered yet, so the advisory itself insists that only updating is a complete solution.

To confirm which version your server is running, run php -v from the terminal or check the PHP_VERSION value with phpinfo(); the number should be 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or higher. On PHP-FPM, the version field also shows up at the /status endpoint if you have pool status enabled, or you can ask your hosting provider directly if they manage the server for you.

flowchart TD
A["HTTP request comes in"] --> B["PHP-FPM worker processes it"]
B --> C{"Memory exhausted or fatal error?"}
C -- "Yes, CVE-2026-109618" --> D["Cleanup treats half-initialized data as valid"]
C -- "No" --> E["Request ends normally"]
E --> F["Worker becomes available"]
F --> G["Next request reuses the same worker"]
G --> H{"Global state left uncleaned?"}
H -- "Yes, CVE-2026-109619" --> I["New request inherits stale state"]
H -- "No" --> E

Impact of the Critical PHP Vulnerabilities in Production

The real impact depends on how much attack surface each installation exposes. A server with mod_php active and file upload routes open to the public faces the most urgent scenario, since a proven exploit already exists there. Deployments running PHP-FPM behind Nginx reduce the risk somewhat because the worker runs isolated from the web server, but they remain exposed to CVE-2026-109619 as long as they share processes across requests, which is exactly FPM’s default design.

For platform teams, the operational message is simple: there’s no way to hot-patch without restarting. Changing session.upload_progress.enabled or fatal_error_backtraces only takes effect if applied in php.ini, in the FPM pool, or in the server configuration before request processing starts, and requires restarting every worker for the new value to take hold. A reload that doesn’t restart processes leaves the window open.

⚠️ Heads up: none of the partial mitigations is a complete solution; the PHP team itself says so without any caveats, updating is the only safe option.

What’s Next

Linux distributions and LTS vendors already received the patches before the public announcement, so most system packages (Debian, Ubuntu, RHEL, Alpine) should have fixed versions available in their repositories around the same time as this publication. Anyone who compiles PHP from source, or runs containers on an old base image, needs to manually rebuild against 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or apply one of the minimal backports released for 7.4, 8.0, and 8.1 while planning a migration to a fully supported branch.

The existence of a proven internal exploit against mod_php shortens the usual gap between the announcement and the appearance of public proof-of-concept code. That’s why the official advisory recommends updating before reading the full technical details of the advisories, not after.

Try it yourself: run php -v on your server today and compare it against 8.5.12, 8.4.27, 8.3.36, or 8.2.35 to find out if you’re already patched.

Frequently Asked Questions

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

The patched versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The security team also released minimal backports for 7.4, 8.0, and 8.1, intended only for those who compile from source.

What makes mod_php exploitable in the face of these critical PHP-FPM flaws?

In mod_php, the attack fires before any application code runs, because the corruption occurs in the interpreter’s own memory handling during request cleanup. That makes it the highest-risk scenario among the affected platforms.

Is adjusting php.ini enough if I can’t update PHP right away?

Not completely. Settings like memory_limit=-1, a low post_max_size, or session.upload_progress.enabled=0 close the already-confirmed exploitation paths, but the PHP advisory itself makes clear that only updating is a complete solution.

Do PHP 8.1 and earlier versions receive this patch?

The PHP project no longer offers official support for 8.1 or earlier versions, but given the severity of this case, it released minimal backports for 7.4, 8.0, and 8.1. Some Linux distributions and LTS vendors also offer their own patches.

How do I know if my server is still exposed to the unauthenticated PHP RCEs?

Run php -v or check phpinfo() to see the installed version number; if it’s not 8.5.12, 8.4.27, 8.3.36, 8.2.35, or higher, your server remains exposed until you update or apply the partial mitigations described in the official advisory.

References

• PHP.net: official announcement of versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 and the two critical vulnerabilities fixed.
• NVD, CVE-2026-109618: official record of the memory corruption vulnerability caused by OOM handling.
• NVD, CVE-2026-109619: official record of the stale global state vulnerability.
• GitHub Security Advisories, GHSA-w8hw-w9fx-j79w: technical detail of the exploitation path via OOM handling.
• GitHub Security Advisories, GHSA-6wmf-4rv5-p3rp: technical detail of the exploitation path via stale global state.

📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Featured image: Foto de Pankaj Patel en Unsplash