On October 21, the PHP development team published a security advisory for two critical vulnerabilities that can permit unauthenticated remote code execution in affected web-facing PHP installations. The same day, patched releases were made available for supported branches. This is a high-priority patching issue for teams that operate PHP services, but the advisory is also specific about affected runtime conditions and temporary mitigations.

What PHP disclosed

The advisory identifies two separate flaws: CVE-2026-109618, involving unsafe handling during an out-of-memory condition, and CVE-2026-109619, involving stale internal request state. PHP describes both as capable of leading to remote code execution. The risk applies to PHP installations serving web requests across several deployment models, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. PHP notes that risk is highest for mod_php, where a demonstrated request can reach the vulnerable path before application code executes.

These are runtime-level issues, not a single vulnerable PHP application or framework. Updating application dependencies alone will not replace a vulnerable PHP interpreter.

Fixed versions

PHP lists 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as fixed releases. Operators should confirm the actual version used by every web-serving process, including containers, worker pools, and secondary environments. A command-line PHP binary can be patched while a separate PHP-FPM pool or container continues to run an older build.

1. Inventory the PHP versions and server integrations that process internet-facing or untrusted requests.
2. Apply the fixed PHP release from php.net or the supported package channel for your operating system. Distribution-maintained packages may carry a backported fix while retaining an older-looking upstream version number; confirm status with the vendor.
3. Restart or roll out all relevant PHP workers and containers, then verify the active runtime version rather than only the installed CLI version.
4. Record the patch state and prioritize exposed production services before lower-risk development systems.

Temporary mitigation is not a substitute for patching

PHP says updating is the only complete fix. Its advisory describes configuration measures that can reduce exposure to specific paths when an immediate update is not possible, including restricting request sizes and disabling session upload progress for the relevant vulnerability. These measures have limitations and must be applied at the server or PHP worker configuration layer; they should not be treated as proof that a system is safe.

PHP 8.1 and older no longer receive standard upstream updates. Some operating-system vendors may provide backported security fixes, so administrators should check the vendor advisory for the exact package they run. If no supported fix is available, plan an upgrade to a maintained PHP branch.

What security teams should monitor

Patching closes the known vulnerable code path; it does not establish whether a system was previously accessed. Teams should review web server, PHP, and endpoint telemetry for unusual activity around the affected hosts, preserve relevant logs, and follow their incident response process if suspicious behavior is found. Avoid relying on a single indicator or assuming that a lack of obvious alerts proves there was no compromise.

This is also a useful reminder to maintain an accurate inventory of server-side runtimes. Web applications often outlive the deployment configuration they were first built on, and a framework-level dependency scan will not necessarily identify the PHP binary serving the application.

Sources

• PHP security advisory: Critical remote code execution vulnerabilities, update now
• GitHub Security Advisory for CVE-2026-109618
• GitHub Security Advisory for CVE-2026-109619

Information in this article reflects public advisories available on October 24, 2026. Check PHP and your operating-system vendor for later updates.