Critical PHP Remote Code Execution Vulnerabilities CVE-2026-109618 and CVE-2026-109619: Update Required

Executive Summary

The PHP development team has released urgent security updates addressing two critical remote code execution (RCE) vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0, according to the supplied security advisory.

These vulnerabilities, informally associated with the PHP2Shell security issue, affect PHP request-processing and memory-management behavior under certain abnormal termination conditions. Successful exploitation could allow an unauthenticated remote attacker to execute code on a vulnerable server, potentially compromising application data, server integrity, and service availability.

The vulnerabilities are particularly concerning because exploitation does not require prior authentication or user interaction. Depending on the PHP deployment architecture, a malicious HTTP request could trigger the vulnerable behavior before application code executes.

RELIANOID strongly recommends that administrators immediately assess their PHP deployments and upgrade to a patched PHP release or an equivalent vendor-provided security update. Internet-facing applications and services should receive the highest priority.

Which PHP Deployments Are Affected?

According to the PHP security announcement dated October 21, 2026, the vulnerabilities may affect PHP installations that process web requests, including:

• PHP-FPM.
• Apache HTTP Server using mod_php.
• php-cgi.
• FrankenPHP.
• LiteSpeed-based PHP deployments.

The PHP security team identifies Apache with mod_php as a particularly concerning configuration because a demonstrated exploit can trigger the attack before application code runs.

However, administrators should not assume that other deployment models are safe. The actual exposure depends on the PHP version, the deployed security patches, the request-processing configuration, and the relevant execution path.

PHP installations embedded in containers, virtual machines, application platform runtimes, and custom-built server images must also be assessed.

Understanding the Vulnerabilities

CVE-2026-109618: Remote Code Execution Through Out-of-Memory Corruption

Reference: https://nvd.nist.gov/vuln/detail/CVE-2026-109618

This vulnerability concerns PHP’s handling of memory allocation failures during HTTP request processing.

Under certain conditions, an out-of-memory (OOM) event can interrupt request initialization while internal request data remains only partially initialized. Subsequent cleanup operations may incorrectly treat that incomplete data as valid, potentially causing memory corruption and enabling remote code execution.

An attacker may be able to submit a specially crafted request designed to trigger the vulnerable memory-handling path.

The consequences of successful exploitation could include:

• Execution of unauthorized code in the PHP worker’s security context.
• Unauthorized access to application data and accessible system resources.
• Modification of application files or runtime configuration.
• Disruption of application services.
• Further compromise of the affected host, depending on the privileges and isolation of the PHP process.

The PHP security team has published mitigation guidance involving memory limits and request-size controls. These measures can reduce exposure to particular attack paths, but they do not eliminate the underlying vulnerability.

CVE-2026-109619: Remote Code Execution Through Stale Global State

Reference: https://nvd.nist.gov/vuln/detail/CVE-2026-109619

This vulnerability involves request-owned internal state that can remain accessible after the memory backing that state has been freed.

In certain circumstances, a subsequent request handled by the same worker may encounter and use stale state before the normal initialization process resets it. Depending on the execution path, this behavior can lead to memory corruption and remote code execution.

The PHP advisory identifies session upload progress and fatal-error backtrace processing among the relevant attack paths addressed by its temporary mitigation guidance.

Potential consequences include unauthorized code execution, compromise of application data, changes to application behavior, and service disruption.

Because worker processes may handle multiple requests, administrators must ensure that any configuration changes intended to mitigate this vulnerability are applied before request parsing and that affected workers are restarted.

Disabling a single PHP feature is not a substitute for installing the security update.

Officially Fixed PHP Versions

The PHP security announcement identifies the following patched releases:

PHP 8.5: 8.5.12
PHP 8.4: 8.4.27
PHP 8.3: 8.3.36
PHP 8.2: 8.2.35

Administrators should upgrade to the corresponding patched release or a later release that includes the fixes.

Security updates may also be available through Linux distributions and long-term support (LTS) vendors. Package versions and release numbering can differ from the upstream PHP versions, so verify the vendor’s security advisory and confirm that the relevant patches have been applied.

PHP 8.1 and older: These branches no longer receive regular security updates from the upstream PHP project. Some distributions and LTS vendors provide backported fixes. If an appropriately patched package is unavailable, migrate to a supported PHP branch.

The PHP team has also published minimal source backports for PHP 7.4, PHP 8.0, and PHP 8.1 to assist deployments that build PHP from source or rely on vendors providing compatible maintenance.

Official references:

PHP security announcement: https://www.php.net/archive/2026.php#2026-10-21-5
PHP downloads: https://www.php.net/downloads.php?source=Y

Recommended Actions for Application and Infrastructure Administrators

1. Upgrade All PHP Deployments Immediately

Identify every server, application, and runtime that includes PHP. Upgrade to the corresponding patched release or install a vendor-provided package that explicitly includes the fixes.

Prioritize internet-facing applications, public APIs, file-upload endpoints, and systems processing untrusted HTTP requests.

Include production, staging, development, disaster-recovery, and other environments that could be exposed to untrusted traffic.

2. Rebuild and Redeploy Container Images

Updating PHP on the container host does not necessarily update PHP installed inside a container image.

Administrators should:

• Identify container images containing PHP runtimes.
• Update the PHP base image or PHP packages included in each image.
• Rebuild and redeploy affected images.
• Update deployment manifests and image references where necessary.
• Verify that running containers use the corrected build.

The same principle applies to virtual machine templates, application platform runtimes, and immutable infrastructure images.

3. Verify the Effective PHP Version and Patch Status

Do not rely exclusively on the version reported by a development workstation or host operating system.

Check the PHP version and package provenance inside the actual execution environment. Where a vendor backports security fixes without changing the upstream version string, verify the package changelog or vendor advisory.

After updating, restart or reload the relevant PHP and web-server workers as required by the deployment model, then verify that the patched runtime is serving application traffic.

4. Migrate Unsupported PHP Installations

If a deployment uses a PHP branch without a supported security update, plan a migration to a maintained branch.

Where an immediate migration is not possible, evaluate a trusted vendor’s backported fix or the PHP project’s published source backport. Test compatibility, dependencies, and application behavior before deploying the change.

5. Apply Temporary Mitigations Where Necessary

If an immediate update is not possible, follow the PHP security team’s mitigation guidance for each vulnerability.

For CVE-2026-109618, the advisory recommends considering:

• Removing the controllable PHP memory-limit failure path by setting memory_limit=-1 through a suitable administrative configuration, while recognizing that underlying allocation failures remain possible.
• Setting an appropriately low post_max_size, for example 8M for applications that do not need uploads or 32M where larger requests are necessary.
• Keeping upload_max_filesize below post_max_size.
• Enforcing appropriate request-size, header-count, multipart-part-count, input-field-count, and nesting-depth limits at the reverse proxy or web-server layer.
• Using container or cgroup resource boundaries to limit the consequences of resource exhaustion, without introducing alternative allocation failures through unsuitable process memory limits.

For CVE-2026-109619, the advisory recommends considering:

• Setting session.upload_progress.enabled=0 in a configuration that applies before request parsing.
• On PHP 8.5, setting fatal_error_backtraces=0 to block the confirmed fatal-backtrace path.
• Removing invalid or deprecated per-request settings that emit diagnostics before initialization.
• Addressing attacker-reachable fatal errors and execution timeouts in callbacks, upload and import processing, and cleanup operations.

Apply relevant configuration changes and restart all affected workers. These measures reduce exposure to specific attack paths only; they do not make a vulnerable PHP installation safe.

Additional Protection with RELIANOID Load Balancer and WAF

A Web Application Firewall (WAF) can provide an additional layer of defense by inspecting HTTP requests and applying controls against selected request patterns.

For example, RELIANOID WAF rules can be used to detect or block multipart requests containing PHP session upload-progress markers and to log requests with deeply nested form parameters.

These controls can help reduce exposure to particular exploitation techniques, but they have important limitations:

• A WAF cannot repair vulnerable memory-management code inside PHP.
• Request patterns can vary, and a rule may not identify every possible exploitation path.
• Request-body inspection depends on WAF configuration, request-body limits, parsing behavior, and available inspection buffers.
• Rules that inspect only selected content types or parameter structures cannot protect every PHP request-processing path.

Therefore, WAF mitigations should be treated as temporary, supplementary protection while administrators apply the official PHP security updates.

RELIANOID Product Impact Statement

RELIANOID Load Balancer Enterprise and Community Editions are not affected by these PHP vulnerabilities because they do not use PHP internally.

The vulnerabilities described in this advisory concern vulnerable PHP runtimes processing application requests. They do not apply to the RELIANOID Load Balancer software itself under the stated architecture.

RELIANOID also confirms that the PHP software used by its online services has been appropriately updated.

Customers who use RELIANOID to protect or distribute traffic to their own PHP applications must nevertheless assess and patch those backend applications and servers. Using RELIANOID as a load balancer or WAF does not automatically remediate vulnerable PHP runtimes behind it.

Security Rules for RELIANOID WAF

Apply these RELIANOID WAF rules to mitigate those PHP vulnerabilities in your RELIANOID Load Balancers Enterprise Editions. Once the rules are created in the IPDS > WAF > Ruleset section, then apply to the HTTP/S farms required to be protected.

Rule 1 — Block PHP Session Upload Progress

SecRule REQUEST_HEADERS:Content-Type "@contains multipart/form-data" \
    "id:100101,\
    phase:2,\
    deny,\
    status:403,\
    log,\
    t:none,\
    t:lowercase,\
    msg:'PHP security mitigation: session upload progress marker detected',\
    chain"
    SecRule REQUEST_BODY "@contains php_session_upload_progress" \
        "t:none,t:lowercase"

How it works:

• Checks that the request uses multipart/form-data.
• Searches the request body for php_session_upload_progress, ignoring case.
• Blocks matching requests and records a security event.

This rule can disrupt legitimate applications that use the matching marker. Validate application requirements before enabling it in production.

Rule 2 — Log Deeply Nested URL-Encoded Form Parameters

SecRule REQUEST_HEADERS:Content-Type "@beginsWith application/x-www-form-urlencoded" \
    "id:100102,\
    phase:2,\
    pass,\
    log,\
    t:none,\
    t:trim,\
    t:lowercase,\
    msg:'PHP security monitoring: deeply nested URL-encoded parameter detected',\
    chain"
    SecRule REQUEST_BODY "@rx (?:^|&)[^&=\[]+(?:\[[^&=\]]*\]){20}" \
        "t:none,t:urlDecode"

How it works:

• Applies to URL-encoded form submissions.
• URL-decodes the body for inspection.
• Detects a parameter name with at least 20 bracketed nesting levels.
• Logs matching requests without blocking them.

This is a targeted detection pattern, not a comprehensive defense against every form of excessive nesting.

Rule 3 — Log Deeply Nested Multipart Form Parameters

SecRule REQUEST_HEADERS:Content-Type "@beginsWith multipart/form-data" \
    "id:100103,\
    phase:2,\
    pass,\
    log,\
    t:none,\
    t:trim,\
    t:lowercase,\
    msg:'PHP security monitoring: deeply nested multipart parameter detected',\
    chain"
    SecRule REQUEST_BODY "@rx (?i)(?:^|\r?\n)content-disposition:[ \t]*form-data[^\r\n]*;[ \t]*name[ \t]*=[ \t]*(?:\"[^\"\r\n\[]+(?:\[[^\]\r\n]*\]){20}\"|[^ \t\r\n;\"\[]+(?:\[[^ \t\r\n;\"]*\]){20})" \
        "t:none"

How it works:

• Applies to multipart form submissions.
• Inspects Content-Disposition form-data headers for parameter names containing at least 20 nested bracket pairs.
• Logs matches without blocking requests.

Test it against representative multipart requests before production deployment, particularly if applications accept complex field names.

Deployment and Validation Checklist

Before enabling these rules, verify the following:

• Request-body inspection: RELIANOID WAF request-body access is enabled, with suitable body limits and buffering for the applicable request types.
• Rule IDs: The example IDs do not conflict with existing local rules or CRS rules.
• Rule engine: The rules are enabled in the intended RELIANOID WAF policy and processing phase.
• Audit logging: Matched requests are recorded in the configured audit or security log.
• False positives: Legitimate uploads and deeply nested form parameters have been tested.
• Detection versus prevention: The two nesting rules remain logging-only unless a deliberate, separately tested policy change is made.
• Backend remediation: All affected PHP application servers, containers, and runtimes are updated to patched versions.

Important: RELIANOID WAF behavior depends on the installed version, request-body processor, and RELIANOID configuration. Confirm syntax and behavior on the target deployment before rollout. These rules do not protect against every possible exploitation path and are not a replacement for patching PHP.

The primary remediation remains upgrading to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or installing an equivalent security-fixed vendor package.

For further information or assistance, do not hesitate to contact our experts.