Exposure Focus
All verdicts

Evidence as of 2026-11-09 (UTC) · Review by 2026-11-23

PHP2Shell

CVE-2026-109618 · CVE-2026-109619 · CVE-2026-115560

Tier 1 · Emergency

Two flaws in the PHP runtime itself let an attacker run code from an ordinary web request with no login. Both are being exploited, so internet-facing PHP needs an out-of-cycle response and internal-only PHP does not.

This tier is for “Internet-facing PHP (Apache mod_php or PHP-FPM)”. Other placements are higher or lower; see below.

Remote code executionBreaks: Confidentiality, integrity and availabilitySome facts unconfirmed

Verdict by placement

Your tier depends on where it runs. Find the line that matches your setup.

  • Tier 1

    Internet-facing PHP (Apache mod_php or PHP-FPM)

    Out-of-cycle response: patch PHP and restart every worker. If you cannot patch at once, apply PHP's configuration workarounds first.

    Why Tier 1
    • Reachable from the internet.
    • Listed in CISA KEV on 2026-10-26.
    • No login needed.
    • Code execution as the web server account.

    Rubric: Reachable. Business impact: critical. Evidence: exploited.

  • Tier 4

    Internal-only PHP

    Patch in your normal cycle. Move up if it becomes reachable from the internet.

    Why Tier 4
    • Not reachable from the internet.

    Rubric: Not reachable from the internet. Routine patching.

Does this apply to you?

Do you run PHP that serves requests from the internet?

How to checkOn each web server, run php -v and compare with the fixed releases 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Check how PHP is served (php -i | grep 'Server API'): Apache mod_php and PHP-FPM are both named in PHP's advisories. Distribution packages can carry the fix without changing the version number, so check your distribution's security tracker too.

If you cannot tell, answer Yes.

Patch and mitigate

There are 3 ways in. Each option below says which it closes and which it leaves open.

  • AOut-of-memory corruption during request handling (CVE-2026-109618)
  • BStale state left behind between requests (CVE-2026-109619)
  • CSession upload progress with an unusual session setup (CVE-2026-115560, not yet fixed)

  1. Update PHP and restart every worker

    Vendor-stated

    AClosedBClosedCLeft open

    Upgrade to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a distribution package that includes the fix. PHP calls updating the only complete mitigation for the first two flaws. Restart Apache or PHP-FPM so no old worker keeps running; rebuild container images that bundle PHP. These releases do not fix CVE-2026-115560, which PHP says it will fix in its next regular release.

    Effort
    A package update and a service restart per server.
    Might break
    No breakage is reported. Test first anyway. PHP 8.1 and older get no fix from PHP and need a supported release or a vendor backport.
    Check it worked, undo, guides
    Check it worked
    Run php -v through the same SAPI the site uses (for example a temporary page calling phpversion(), removed afterwards) and confirm a fixed release or a patched distribution build. Confirm worker processes started after the update.
    Undo
    Reinstall the previous package. This reopens both flaws.

  2. Stopgap for CVE-2026-109618: remove the memory-limit trigger

    Vendor-stated

    APartial mitigationBLeft openCLeft open

    Set memory_limit=-1 administratively, keep post_max_size conservative, bound input variables, multipart parts and uploads, and block multipart form requests at the frontend if the application does not use them. Do not use RLIMIT_AS or RLIMIT_DATA. PHP calls this the primary configuration mitigation but not a complete one.

    Effort
    A configuration change and a restart of every worker.
    Might break
    Removing the per-request memory cap lets one request use much more memory, so you need frontend limits to replace it.
    Check it worked, undo, guides
    Check it worked
    Confirm the running value with phpinfo() or php -i for the SAPI in use, and that workers restarted.
    Undo
    Restore the previous memory_limit and limits, then restart workers.

  3. Stopgap for CVE-2026-109619 and CVE-2026-115560: turn off session upload progress

    Vendor-stated

    ALeft openBPartial mitigationCClosed for that app

    Set session.upload_progress.enabled=0. This removes the session path PHP demonstrated for CVE-2026-109619, and PHP recommends it even after patching if you do not use the feature. On PHP 8.5, fatal_error_backtraces=0 removes another confirmed path. PHP says there is no complete configuration mitigation for CVE-2026-109619. For CVE-2026-115560, which has no fix yet, this setting is the mitigation PHP suggests until its next regular release.

    Effort
    A configuration change and a restart of every worker.
    Might break
    Upload progress bars that rely on PHP sessions stop working.
    Check it worked, undo, guides
    Check it worked
    Confirm session.upload_progress.enabled is Off in phpinfo() for the SAPI in use.
    Undo
    Set session.upload_progress.enabled back to 1 and restart workers.

  4. Turn on your WAF vendor's PHP rules

    Vendor-stated

    APartial mitigationBPartial mitigationCPartial mitigation

    Several WAF vendors have shipped rules for the first two CVEs: AWS WAF (the PHP managed rule group), Cloudflare (managed rules, set to block by default on its emergency release) and a Fastly Next-Gen WAF virtual patch. Broadcom publishes rule text for VMware Avi. All of them describe this as an interim measure that blocks known exploit patterns. AWS says no WAF rule is a complete mitigation, and Cloudflare says to patch PHP regardless. Of these, only Cloudflare says its rules also cover CVE-2026-115560.

    Effort
    Enable a managed rule group or virtual patch, or add the rules, on every site that serves PHP. Update any pinned rule-group version to pick up the new rules.
    Might break
    Rules match known attack patterns, so they can block some legitimate requests. Cloudflare's rule for the session upload path only works while session.upload_progress.name is left at its default. Traffic that bypasses the WAF is not covered.
    Check it worked, undo, guides
    Check it worked
    In your WAF console, confirm the rules or virtual patch are on, set to block and not only to log, and applied to every hostname that serves PHP. A WAF does not change the PHP version, so keep checking php -v as above.
    Undo
    Disable the rule group or virtual patch.

The detail behind this call

Evidence

6 items, as of 2026-11-09
CISA KEV · Vendor-stated
Both CVEs are in the Known Exploited Vulnerabilities catalog, added 2026-10-26, which means CISA has evidence of exploitation. CISA does not say how many systems were breached.
As of 2026-11-09 · Source for CISA KEV
Vendor advisory · Vendor-stated
PHP's advisories confirm unauthenticated remote code execution as the web worker account. Code execution was validated against mod_php for CVE-2026-109618, and against mod_php and FPM for CVE-2026-109619. Affected: below 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
As of 2026-11-09 · Source for Vendor advisory
Exploit evidence · Reported, not yet confirmed
BleepingComputer reports a researcher saw working shells on honeypots running PHP 8.4.26 under Apache mod_php, and that other vendors reported exploitation attempts, with reliability varying between those reports. Treat individual attack reports with caution; the KEV listing is the firm signal.
As of 2026-11-09 · Source for Exploit evidence
Related flaw, vendor notice · Vendor-stated
On 2026-10-23 PHP published an informational advisory for a third, related flaw, CVE-2026-115560, in session upload progress. It says it will publish a full advisory with the next release, and suggests setting session.upload_progress.enabled=0 until the next regular bugfix release. Cloudflare says the flaw affects fully patched releases, including 8.5.12. The php.net notice names no fixed version.
As of 2026-11-09 · Source for Related flaw, vendor notice
Related flaw, how it works · Reported, not yet confirmed
PHP's notice, relayed on the oss-sec list, describes a possible code execution route that needs an unusual setup: the application switches session.serialize_handler to php with ini_set() before session_start() while session upload progress is on. BleepingComputer says it is exploitable only with an unusual combination of configuration and application code and reports no exploitation in the wild. Wiz lists no public exploit. These details come from relayed summaries, not from a full PHP advisory, which does not exist yet.
As of 2026-11-09 · Source for Related flaw, how it works
Related flaw, CISA KEV · Vendor-stated
CVE-2026-115560 is not in the Known Exploited Vulnerabilities catalog (catalog released 2026-11-09). Only the two flaws above are listed.
As of 2026-11-09 · Source for Related flaw, CISA KEV

Any CVSS (Common Vulnerability Scoring System, a general severity score) figure quoted is for reference. It did not set a tier.

Analysis

Both flaws sit in the PHP runtime, not in any application built on it, which is why the exposure is so wide. PHP's advisories rate attack complexity as high; the conditions they describe include session upload progress, which the CVE-2026-109619 stopgap above turns off.

A third, related flaw, CVE-2026-115560, is handled differently on purpose. It is not in the CISA catalogue, no source reports it being exploited, and it needs an unusual configuration, so it does not set the tier above. It matters because there is no fix yet: the fixed releases listed on this page do not cover it, and the mitigation PHP suggests is turning off session upload progress.

PHP's advisories are more cautious than some write-ups about which ways of serving PHP are affected: FrankenPHP and LiteSpeed are described as likely but not demonstrated.

Sources

11