CVE-2026-109618: Critical PHP Memory Corruption Enables RCE

Are You Affected?

CVE-2026-109618 affects PHP request handling when an out-of-memory condition interrupts initialization and leaves invalid request state available to later cleanup or allocation logic. Successful exploitation can lead to arbitrary code execution under the privileges of the PHP or web-server process.

The affected branches and fixed versions identified in the Openwall disclosure are:

The NVD response supplied the 9.8 score but did not provide a vector string in the retrieved record. The PHP security announcement identifies the issue as CVSS v4.0 9.2. These values are not directly interchangeable, so defenders should validate the current NVD and PHP advisory records before using a single vector in formal risk reporting.

Potentially affected deployment models include Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed PHP deployments. The strongest demonstrated attack path is unauthenticated HTTP exploitation against Apache mod_php before normal application code executes. Source analysis indicated possible PHP-FPM susceptibility, but a complete FPM exploit was not demonstrated in the retrieved advisory material.

Analyst’s Take: Treat internet-facing Apache mod_php systems as the first patching queue because that is the deployment tied to the demonstrated unauthenticated attack path. PHP-FPM may also be susceptible, but the retrieved material does not establish a complete FPM exploit, so defenders should separate confirmed exposure from possible exposure while still inventorying both.

The Fix, If You’re in a Hurry

Upgrade each supported PHP branch to its corresponding fixed release or later:

• PHP 8.2: 8.2.35 or later
• PHP 8.3: 8.3.36 or later
• PHP 8.4: 8.4.27 or later
• PHP 8.5: 8.5.12 or later

CISA added CVE-2026-109618 to the Known Exploited Vulnerabilities catalog on October 26, 2026, with a remediation due date of October 29, 2026. Organizations subject to applicable CISA guidance should treat that date as an immediate operational deadline. All organizations should prioritize exposed systems regardless of formal applicability.

The exact upgrade command depends on the operating system and package source. First determine whether PHP is managed by the OS, a third-party repository, a hosting panel, a container image, or a manually compiled installation. For a source-built deployment, the operational target is the fixed release, for example:

php -v
./configure <your-existing-options>
make -j"$(nproc)"
sudo make install
sudo systemctl restart php-fpm 2>/dev/null || true
sudo systemctl reload apache2 2>/dev/null || true

Do not copy the placeholder configure line into production without preserving the existing build options. For package-managed systems, use the vendor-supported update workflow and verify the resulting binary:

php -v
php-fpm8.3 -v 2>/dev/null || true
systemctl status php*-fpm --no-pager

For PHP 7.4, 8.0, and 8.1, use a trusted distribution or long-term-support vendor package that explicitly contains a backport, or migrate to PHP 8.2 or later. PHP 7.3 and older have no current upstream fix identified in the retrieved sources and should be treated as unsupported software requiring migration.

If immediate patching is impossible, remove vulnerable services from external exposure, restrict access through network controls, isolate the host, and reduce PHP process privileges. These are temporary risk-reduction measures, not substitutes for upgrading. Disabling an individual application feature is not sufficient because the defect is in PHP core request handling.

How This Vulnerability Works

PHP uses longjmp() to handle out-of-memory errors by leaving the current execution context and aborting request processing. In the vulnerable path, the interrupted operation is not correctly accounted for, allowing request memory to remain uninitialized, incomplete, or otherwise invalid while subsequent allocation and shutdown logic continues.

During request cleanup, PHP can then read from or branch on this invalid state. Multiple out-of-memory triggering strategies can reportedly reach the condition. If an attacker can reliably cause the relevant allocation failure and control the resulting execution path, the invalid memory state may be converted into arbitrary code execution.

The issue is more serious than a conventional denial-of-service flaw. An attacker who reaches successful code execution can run commands with the privileges of the PHP or web-server process. The resulting impact depends on file permissions, operating-system confinement, application secrets, database access, and network connectivity from the compromised host.

Technical Notes

The affected condition is associated with this sequence:

1. A request triggers an allocation failure.
2. PHP uses longjmp() to abort the current execution context.
3. Request state remains partially initialized or invalid.
4. Later allocation or request-shutdown logic accesses that state.
5. Memory corruption can produce attacker-controlled execution.

The retrieved material does not establish that every PHP deployment or every request path is exploitable in the same way. Architecture, runtime version, SAPI, memory limits, compiler behavior, and web-server integration may affect exploitability. Defenders should nevertheless treat internet-facing vulnerable versions as compromised-risk assets because unauthenticated RCE has been demonstrated for Apache mod_php.

Severity, Explained

The NVD reports a CVSS base score of 9.8, which places CVE-2026-109618 in the critical range. The score reflects the combination of network reachability, the absence of an authentication requirement for the demonstrated attack path, and the potential for complete compromise of confidentiality, integrity, and availability.

The retrieved NVD record did not include a vector string. The PHP security announcement describes the issue using CVSS v4.0 with a score of 9.2. Because the scoring systems and metric definitions differ, organizations should not merge the two values or infer an unverified vector. Use the current authoritative record when entering the vulnerability into a GRC, vulnerability-management, or asset-risk platform.

Regardless of the precise vector, the operational severity is elevated by four factors:

• Unauthenticated remote access: HTTP exploitation was demonstrated against Apache mod_php without requiring application credentials.
• High-impact outcome: Successful exploitation may provide arbitrary code execution.
• Broad deployment footprint: PHP is used with multiple server APIs and web-server configurations.
• Confirmed exploitation: CISA KEV inclusion establishes exploitation in the wild.

CVE-2026-109618 should be prioritized above non-exploited critical vulnerabilities on internet-facing systems. Internal systems also require urgent remediation because a compromised web application, VPN, reverse proxy, or adjacent host may provide an attacker with network access to PHP services.

Is It Being Exploited?

Yes. Exploitation is confirmed in the wild. CISA added CVE-2026-109618 to its Known Exploited Vulnerabilities catalog on October 26, 2026. The catalog entry carries an October 29, 2026 remediation deadline. KEV inclusion is the strongest publicly documented signal in the supplied research that defenders should assume active attacker interest.

The retrieved Openwall disclosure states that unauthenticated remote code execution was demonstrated over HTTP against Apache mod_php. Additional reporting describes exploitation attempts and public technical material associated with the PHP2Shell vulnerabilities. The available material does not establish that every public exploit works against every PHP version, architecture, SAPI, or configuration.

A public PoC exists or has been publicly reported. Public GitHub repositories and technical write-ups reportedly contain proof-of-concept material targeting PHP memory-safety flaws, including CVE-2026-109618. Some demonstrations may depend on specific deployment conditions or additional application weaknesses. That variability does not reduce the urgency: KEV status confirms real-world exploitation independently of whether a particular PoC succeeds in a local test.

Known ransomware use is unknown based on the supplied research. That should not be interpreted as evidence that ransomware operators are not interested in the flaw. Attackers may use compromised PHP hosts for web shells, credential theft, persistence, lateral movement, or later-stage ransomware activity without the vulnerability appearing in a ransomware-specific attribution record.