PHP2Shell Explained: Impact, Patches and Mitigation for CVE-2026-109618 and CVE-2026-109619
By Harpreet Singh Virdi, CISSP, CCSP · Cybersecurity Updates
Published and evidence checked: November 3, 2026.
If you run PHP, start with an inventory and a patch decision today. If a security appliance uses PHP internally, check its vendor advisory too. Updating your website code alone does not update the runtime inside a firewall.
PHP2Shell is the name used for CVE-2026-109618 and CVE-2026-109619. They can allow remote code execution without authentication. PHP released security updates on October 21. The PHP team identifies web-serving installations as at risk and highlights Apache mod_php as the highest-risk configuration. PHP security announcements.
What the evidence tells us
There is a difference between an exploit demonstration and an attack against a real organisation. For this issue, Palo Alto Networks explicitly reports active exploitation against internet-exposed management interfaces. Its advisory assigns a CVSS v4.0 base score of 9.2, Critical, for its internet-exposed product scenario. That score is vendor-specific context, not a universal assessment of every PHP deployment. Palo Alto Networks advisory, updated October 29.
Canada's Cyber Centre updated its alert on October 27 to report exploitation in the wild and CISA KEV inclusion on October 26. Read the later update: the initial paragraph still describes an earlier point when exploitation had not been identified. A timestamp changes the meaning of a threat report. Cyber Centre AL26-026, Update 2.
Assessment: this is an emergency patching priority for exposed, affected services. I am using the term “actively exploited vulnerability” here. The evidence cited establishes exploitation; it does not, by itself, establish exactly when the first attack occurred relative to patch availability, so I am not labelling every case a zero-day attack.
Understand the two failures
CVE-2026-109618: failure while handling a memory shortage
Out of memory means PHP cannot obtain memory it needs. The problem is how PHP handles that failure: an early exit can leave request data only partly initialised. Cleanup can then act on invalid state and enable code execution. With mod_php, the dangerous sequence can happen before application code runs. The PHP advisory distinguishes that demonstrated path from PHP-FPM, where susceptibility is supported by source analysis but the same complete exploit was not demonstrated. PHP's OOM corruption advisory.
Think of a worker preparing a form, stopping halfway, and handing the unfinished form to cleanup as if it were complete. That is an analogy for the state error, not an exploit recipe. The practical lesson: a login check in your application may execute too late to protect a vulnerable runtime.
CVE-2026-109619: one request leaves unsafe state for another
A long-running PHP worker can handle multiple requests. Some internal state can keep referring to memory after the request owning that memory has ended. A later request can use the stale reference: a use-after-free. Exploitation needs a reachable operation that leaves the state behind and a later operation in the same worker that consumes it. PHP documents confirmed mod_php and application-dependent FPM paths. Its advisory says configuration changes do not cover every path. PHP's stale global state advisory.
Do not assume that switching PHP handlers is a complete fix. Different request lifecycles change the conditions for exploitation. They do not remove the need for the security update.
Two memory failures. One serious outcome.
Conditions vary by runtime, configuration and application path.
Which versions need attention?
| PHP branch | First upstream release fixing these two CVEs |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Earlier releases in each listed branch need remediation. These minimum versions are listed in PHP's advisory. Use the latest appropriate supported vendor package, not an old build simply because it matches this table. Distribution vendors may backport fixes without adopting the upstream version number. Check their security notice and package revision. PHP 8.1 and older no longer receive normal upstream updates; verify any extended-support fix or plan an upgrade. PHP release and upgrade guidance.
For PAN-OS, use the vendor's branch-specific upgrade matrix. For example, its advisory lists 11.2.10-h16 and 11.1.7-h12 among fixed maintenance releases. Those examples are not interchangeable upgrade targets. Check your precise branch, platform and upgrade path. Do not manually replace an appliance's embedded PHP package. PAN-OS affected and fixed version matrix.
Possible impact: what could an attacker gain?
Analysis: code execution initially gives an attacker the permissions and access of the compromised process. From there, possible consequences include reading application secrets, modifying website files, accessing databases reachable with those secrets, installing persistence or disrupting service. These are possible consequences, not claims that every affected system suffered them.
A compromised management service can be especially serious because of the configuration and trust attached to that device. Do not equate PHP code execution automatically with root access. Additional privilege and lateral movement depend on the environment and any further weaknesses.
Work through the response in this order
- Find the actual runtime. Record internet-facing sites, internal applications, containers, hosting platforms and appliances. Assign an owner. Include every backend behind the load balancer, not just the virtual IP.
- Confirm exposure. Record the runtime or firmware build, vendor patch status, web handler and reachable interfaces. Test management-interface restrictions from an authorised external location. A diagram alone is not evidence of reachability.
- Reduce exposure while patching. Restrict management access to approved administration paths. For a service that cannot be safely updated or mitigated promptly, consider taking it offline. These priorities align with NCSC guidance.
- Apply the supported update. Follow the operating-system, hosting or appliance vendor's process. For applications, test essential login, upload, API and background-job behaviour. Plan rollback without quietly returning a vulnerable service to public exposure.
- Replace running instances. Ensure old PHP workers and old containers are gone. Update deployment images and templates so the next scale-out does not reintroduce the vulnerable build.
- Investigate possible compromise. Patching closes the vulnerability; it does not remove an existing backdoor. If suspicious evidence exists, involve incident response before destructive cleanup.
Close the exposure. Verify the fix.
Preserve evidence, review suspicious activity and follow incident response if compromise is suspected.
Temporary mitigation: know its limits
PHP recommends disabling session.upload_progress.enabled at startup configuration and restarting all workers to block confirmed session paths. For PHP 8.5, disabling fatal_error_backtraces blocks one confirmed path. Neither covers the full vulnerability family. Follow the complete stale-state mitigation guidance.
The OOM advisory discusses administratively enforcing memory_limit=-1 when an update is impossible. This removes a predictable trigger but leaves other allocation failures possible and requires careful availability controls. Do not copy that setting into production without assessing resource exhaustion. The advisory also warns against substituting RLIMIT_AS or RLIMIT_DATA. OOM mitigation limitations.
A related issue, CVE-2026-115560, was not fixed by the October 21 updates. The Cyber Centre describes an unusual combination of session configuration and application behaviour and recommends keeping upload progress disabled until a fix is available. Track that separately; fixing two CVEs does not prove the entire runtime has no remaining issues. Cyber Centre Update 1.
Where F5 ASM or FortiWeb fits
Defensive analysis: a WAF can only evaluate traffic that actually passes through an applicable inspection policy. An appliance management port may sit outside your application's WAF path. Confirm routing, TLS visibility, policy attachment, enforcement and origin restrictions before claiming coverage.
Use a vendor-supported signature or virtual patch where available and validate its documented scope. A blocked request demonstrates that one request was blocked. It does not demonstrate complete protection against every memory corruption path. Keep patching on the response plan. Our F5 ASM and FortiWeb training hub explains policy operation and evidence-based tuning.
Detection and investigation: build a timeline
The following are investigation leads, not unique indicators of PHP2Shell. Correlate reverse-proxy access logs, PHP and web-server errors, worker crashes, process activity, outbound connections, file changes and administrator events. Look for abnormal request patterns near memory failures, unexpected child processes, new executable files in writable web directories and unexplained configuration changes. Ordinary application faults can produce some of these signals too.
Record timestamps and time zones, affected hosts, original logs and retention gaps. Protect evidence with your incident-response process. A clean access log is weak reassurance when telemetry is incomplete. NCSC specifically recommends checking for compromise and backdoors when immediate updating or disabling is not possible. NCSC response guidance.
How to prove the remediation is complete
For each asset, retain the vendor advisory, installed package or firmware revision, deployment time, worker or service restart evidence, and an authorised post-update assessment. Verify the web-serving runtime: a command-line PHP version alone may describe a different binary. Avoid leaving a public phpinfo() page behind as a verification shortcut.
Confirm all load-balanced nodes and standby devices, test normal user journeys, review relevant alerts, and recheck external exposure. Close the change only when the evidence matches the inventory. Keep the incident investigation open if patch verification passes but compromise remains unresolved.
Your action today
Identify the runtime, verify the vendor fix, reduce unnecessary exposure, patch every affected instance and investigate suspicious activity. Treat WAF controls as a supporting layer. Keep a dated evidence record so the next person can verify what was actually fixed.
References and evidence
- PHP official release announcements — October 21 fixes and subsequent notices.
- PHP GHSA-w8hw-w9fx-j79w — OOM root cause, fixed versions and limitations.
- PHP GHSA-6wmf-4rv5-p3rp — stale-state conditions and mitigation scope.
- Palo Alto Networks security advisory — product scope, scoring, exploitation and release matrix.
- Canadian Cyber Centre AL26-026 — dated updates on exploitation and the related issue.
- UK NCSC guidance — discovery, patching and incident-response priorities.
This is independent educational analysis based on the cited public evidence. No exploit, mitigation or product configuration was tested for this article. Advisories can change; recheck the vendor before implementing a production change. See our editorial disclosure.
Originally published on WAF Protect. This is the full syndicated edition on SGP Tech Providers.