K000163821: PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619

My.F5 • October 21, 2026

CVE-2026-109618 (also known as php2shell) PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may not properly account for this scenario and leave request memory in an uninitialized state before performing an allocation. The subsequent request cleanup procedure may read or branch on this memory. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE).

PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may not properly account for this scenario and leave request memory in an uninitialized state before performing an allocation. The subsequent request cleanup procedure may read or branch on this memory. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE).

CVE-2026-109619 (also known as php2shell) PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE).

PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE).

For products with None in the Versions known to be vulnerable column, there is no impact.

For products with ** in the various columns, F5 is still researching the issue and will update this article after confirming the required information. F5 Support has no additional information this issue.

Security Advisory Status

To determine if your product and version have been evaluated for this vulnerability, refer to the Evaluated products box. To determine if your release is known to be vulnerable, the components or features that are affected by the vulnerability, and for information releases, point releases, or hotfixes that address the vulnerability, refer to the following tables. You can also use iHealth to diagnose a vulnerability for BIG-IP, BIG-IQ, and F5OS systems. For more information using iHealth, refer to K27404821: Using F5 iHealth to diagnose vulnerabilities . For more information security advisory versioning, refer to K51812227: Understanding security advisory versioning .

BIG-IP, BIG-IQ, and F5 Insight

F5 Distributed Cloud and NGINX Services

Note : After a fix is introduced for a given minor branch, that fix applies to all subsequent maintenance and point releases for that branch, and no additional fixes for that branch will be listed in the table. For example, when F5 releases a fix in BIG-IP for Kubernetes 2.3.1, the fix also applies to 2.3.2 and all later 2.3.x releases. For more information, refer to K51812227: Understanding security advisory versioning .

1 F5 evaluates only software versions that have not yet reached the End of Technical Support (EoTS) phase of their lifecycle. For more information, refer to the Security hotfixes section of K4602: Overview of the F5 security vulnerability response policy .

2 Starting with the August 2024 Quarterly Security Notification, F5 will provide the CVSS v4.0 base score in addition to the CVSS v3.1 score, for first-party security issues only. The CVSS score link takes you to a resource outside of MyF5, and the content may be removed without our knowledge. For more information how F5 uses CVSS v4.0, refer to K000140363: Overview of CVSS v4.0 in F5 security advisories .

**Confirmation of vulnerability or non-vulnerability is not presently available. F5 is still researching the issue for the products indicated and will update this article with the most current information as soon as it has been confirmed. F5 Support has no additional information on this issue.

BIG-IP, BIG-IQ, and F5 Insight

Note : After a fix is introduced for a given minor branch, that fix applies to all subsequent maintenance and point releases for that branch, and no additional fixes for that branch will be listed in the table. For example, when F5 releases a fix in 17.1.2.1, the fix also applies to 17.1.2.2 and all later 17.1.x releases (17.1.3.x, 17.1.4.x). For more information, refer to K51812227: Understanding security advisory versioning .

F5 Distributed Cloud and NGINX Services

Security Advisory Recommended Actions

F5 is still researching the issue for the products indicated and will update this article with the most current information as soon as it has been confirmed. F5 Support has no additional information on this issue.

If you are using the BIG-IP Advanced WAF, BIG-IP ASM, F5 WAF for NGINX, or the NGINX App Protect WAF to protect your backend pool members, you can mitigate this vulnerability for your backend pool members by using the following attack signatures enabled in blocking mode:

CVE-2026-109618: PHP Remote Code Execution, ID 200103697 and ID 200204115

CVE-2026-109619: PHP Remote Code Execution, ID 200204113

For information updating attack signatures on the BIG-IP system, refer to K82512024: Managing BIG-IP ASM Live Updates . For information assigning attack signatures to security policies on the BIG-IP system, refer to the Assigning Attack Signatures to Security Policies chapter of the BIG-IP Application Security Manager: Attack and Bot Signatures guide.

For information updating attack signatures on the NGINX system, refer to the Update F5 WAF for NGINX signatures chapter of the F5 WAF for NGINX guide.

Additionally, you can use the BIG-IP Advanced WAF/ASM system to mitigate the impact of the php2shell vulnerabilities in your infrastructure using the following procedures.

Important: The BIG-IP controls below reduce exposure to specific attack paths but do not replace patching.

PHP RCE from out-of-memory (OOM) corruption - CVE-2026-109618

Before configuring BIG-IP

Identify all ASM policies protecting the affected PHP applications.

Save backups of all identified policies.

Review legitimate upload, form, and API requirements before introducing restrictions.

Recommended BIG-IP Advanced WAF/ASM configuration

For applications that do not require multipart submissions:

Open the relevant security policy’s Allowed URLs configuration.

In Header-Based Content Profiles , add or modify an entry matching the Content-Type header for *multipart*.

Set the action to Disallow .

Enable Alarm and Block for Illegal request content type .

Apply the restriction to all relevant URL entries (explicit and wildcards).

This prevents blocked requests from reaching PHP’s multipart parser. It will also prevent legitimate multipart uploads and forms.

In the policy’s File Types configuration:

Enable POST Data Length checking and set the smallest maximum body size the application requires.

Enable Request Length checking and set an appropriate total-request limit, allowing for headers and the URL.

Review explicit file types, the wildcard entry and the no-extension entry.

Enable Alarm and Block for Illegal POST data length and Illegal request length .

PHP recommends a conservative backend post_max_size: 8M where uploads are unnecessary or 32M where uploads are required. These are exposure-reduction guidelines, not guaranteed safe WAF thresholds. The WAF max request buffer size is by default 10M so the recommendation is to limit to 8M.

Under HTTP Protocol Compliance , enable:

Check maximum number of parameters — reduce the maximum to the application’s required count.

Check maximum number of headers — set an application-appropriate maximum.

Bad multipart/form-data request parsing .

Bad multipart parameters parsing .

Unparsable request content .

Several Content-Length headers .

Chunked request with Content-Length header .

Enable Alarm and Block for HTTP protocol compliance failed . Also configure an appropriate HTTP header-length limit and block Illegal header length . Where practical, allow only expected form parameters. If array-style parameter names are unnecessary, restrict, and in parameter names and block Illegal meta character in parameter name .

Important : Small, valid multipart requests can still cause excessive PHP memory allocation. Ordinary HTTP header limits do not establish a limit on headers inside multipart parts, and parameter-count checks must not be assumed to count every empty file control. These controls do not fully address all documented OOM techniques.

Where application compatibility permits, reject POST requests without a valid Content-Length header. This reduces exposure to the documented attack path in which PHP processes multipart data without a usable declared length.

Under HTTP Protocol Compliance , enable POST request with Content-Length: 0 .

Enable Alarm and Block for HTTP protocol compliance failed , then apply the policy.

Separately enforce the presence of Content-Length on POST requests using a method-scoped BIG-IP local traffic policy or iRule. The POST request with Content-Length: 0 check should not be treated as a general missing-header check.

Continue enforcing actual request-body size limits and rejecting ambiguous framing, including requests containing both Transfer-Encoding and Content-Length.

Compatibility impact : Requiring Content-Length rejects otherwise valid chunked POST requests and HTTP/2 POST requests that omit it. Blocking zero-length POST requests can also disrupt legitimate application workflows.

Limitation : A valid Content-Length does not prevent memory amplification or other OOM triggers. These restrictions reduce exposure but do not replace updating PHP.

Apply the policy and validate

Set the policy to Blocking , resolve relevant staging or bypass exceptions, and Apply Policy .

Confirm prohibited and over-limit requests are blocked before reaching PHP.

Test legitimate uploads, forms and APIs, and monitor WAF events and application availability.

Prevent direct-origin access that bypasses BIG-IP.

Complete the PHP update promptly, then review temporary restrictions.

K41942608: Overview of MyF5 security advisory articles

K12201527: Overview of F5 security notifications

K51812227: Understanding security advisory versioning

K4602: Overview of the F5 security vulnerability response policy

K4918: Overview of the F5 critical issue hotfix policy

K39757430: F5 product and services lifecycle policy index

K9957: Creating a custom RSS feed to view new and updated documents

The full story

This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.

Critical PHP2Shell Vulnerabilities Expose Millions to Remote Code Execution On October 21, 2026, the PHP project released emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. These flaws allow unauthenticated attackers to execute arbitrary code on PHP servers, affecting versions from 5.4 to 8.5. The vulnerabilities stem from memory management issues during out-of-memory conditions and improper handling of request states. Attack attempts were observed shortly before the patches were released, indicating active exploitation in the wild. Organizations are urged to update PHP immediately, as configuration changes cannot fully mitigate the risks. The vulnerabilities carry a CVSS score of 9.2, highlighting their severity and potential impact on approximately 70% of the internet's web applications. 88 sources 73

Extracted Entities

K000163821: PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619

The full story

Extracted Entities

Attack Types (1)

CVEs (2)

CWE Weaknesses (1)

MITRE ATT&CK (1)

Platforms (3)

Tools (2)