PHP is an open-source, general-purpose scripting language designed for server-side web development and maintained by the PHP project and its contributors. It powers a large share of the web, including content management systems such as WordPress, Drupal and Joomla, e-commerce platforms such as Magento and WooCommerce, and countless custom applications. Hosting providers, enterprises, public institutions and individual developers deploy PHP on Linux, Windows and BSD servers to generate dynamic pages and APIs. PHP is commonly embedded in Apache HTTP Server as mod_php, run behind nginx and other web servers through PHP-FPM, or served by runtimes such as FrankenPHP and LiteSpeed LSAPI. The PHP interpreter parses incoming HTTP requests, including query strings, cookies and multipart form data, before it hands control to the application code. Because it sits underneath every PHP application on a server, a flaw in the interpreter itself affects all hosted sites regardless of the application they run.
CVE-2026-109618 and CVE-2026-109619 are two related critical vulnerabilities in the PHP interpreter, disclosed by the PHP security team on 21 October 2026 and both rated CVSS v4.0 9.2. CVE-2026-109618, titled "RCE via OOM corruption", occurs when an out-of-memory error interrupts PHP while internal request data is only partially initialized. Request cleanup then treats this invalid data as valid, which corrupts memory and can be turned into code execution. CVE-2026-109619, titled "RCE via stale global state", lets request-owned internal state survive after its memory has been freed, so a later request handled by the same worker uses the stale state. Both flaws can be reached by an unauthenticated remote attacker through crafted HTTP requests, and the vulnerable code runs before any application code executes. The issues are fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, while PHP 8.1 and older branches do not receive an upstream fix.
PHP uses longjmp() to abort a request on out-of-memory errors, and in some contexts request memory is reachable before it is fully initialized, so an allocation failure at that point leaves it in an invalid state that the shutdown procedure later reads. An attacker can reach this out-of-memory condition during automatic multipart/form-data body parsing, for example by sending parts with an unrestricted number of headers, empty file controls with nested field names, or a body without a usable declared content length. On Apache mod_php the request shutdown procedure runs even when request startup failed, so the corruption happens before application code, and full remote code execution was validated over HTTP with default PHP input and memory limits. For CVE-2026-109619, a fatal error or out-of-memory interruption leaves global state pointing into freed request memory, and an operation in the next request on the same worker uses it before normal initialization resets it. The confirmed consumers of this stale state are diagnostics raised while applying per-directory INI settings such as .htaccess php_value entries, and the session upload progress handler, which is enabled by default and does not require session_start(). This scanner sends a single GET request to the root path and compares the PHP version in the X-Powered-By or Server response header with the affected ranges, without sending any exploit payload.
Successful exploitation allows an unauthenticated attacker to execute arbitrary code on the server with the privileges of the PHP worker account. The attacker can read or modify application source code, configuration files and database credentials stored on the server. Web shells or backdoors can be planted to keep persistent access even after the initial entry point is closed. On shared hosting, every site served by the same PHP runtime can be exposed through a single vulnerable worker. The compromised server can be used as a foothold to move into internal networks, send spam or host malicious content. Failed exploitation attempts can also crash PHP workers and cause service disruption.
REFERENCES
- Upgrade PHP to the fixed release of its branch: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Upgrading within the same branch keeps application compatibility risk low.
- If PHP comes from a distribution package (Debian, Ubuntu, RHEL and similar), install the vendor security update and confirm in the package changelog that CVE-2026-109618 and CVE-2026-109619 are fixed, because the upstream version number may not change.
- Restart every PHP process after the upgrade, including Apache with mod_php, all PHP-FPM pools and FrankenPHP or LSAPI workers, so that no worker keeps running the vulnerable code.
- Migrate servers on PHP 8.1, 8.0, 7.x or 5.x to a supported branch, because these versions will not receive an upstream fix.
- If an immediate upgrade is not possible, set and enforce memory_limit=-1 administratively as advised by the PHP security team, and do not use RLIMIT_AS or RLIMIT_DATA, which trigger the vulnerable path. This is a temporary measure, not a complete fix.
- Block multipart/form-data requests at the reverse proxy or WAF for applications that do not accept uploads, and limit the number of parts, headers per part and input variables for applications that do.
- Disable session.upload_progress.enabled where upload progress tracking is not used, since the session upload progress handler is one of the documented trigger paths.
- Set expose_php=Off and remove PHP version details from the Server header to reduce the information available for targeted attacks.
- Review web servers for signs of compromise, such as PHP workers spawning shells or download tools, unexpected PHP files in web roots and new scheduled tasks.
Get AI-powered remediation steps tailored to your asset.
Try AI Solutions →