Skip to main content
Change Risk Intel
Change Management

php2shell KEV Deadline: Evidence First, Then the Emergency Patch

Ben Ennis Founder, Ennis Studio · Editor, Change Risk Intel · 13 min read

No affiliate links appear in this article. It’s written for change owners and CAB members, and it doesn’t describe how the flaws are exploited. BOD 26-04 binds US federal agencies. For everyone else, this is a summary of published guidance, not compliance advice.

Table of contents

Why this matters

PHP fixed the two php2shell flaws on October 21. For many teams that looked like a routine patch week. Five days later, CISA’s KEV catalog listed both CVEs as exploited, with a due date of October 29. That’s the three-day tier under BOD 26-04. Both entries also carry forensicTriage: Yes in the catalog’s JSON feed. That flag changes the order of work, not just the deadline.

CISA’s BOD 26-04 implementation guidance tells teams to collect evidence before they patch. “Collect all required evidence prior to this step as patching may jeopardize the availability of artifacts.” A team that rushes the patch on a web server that was already compromised could destroy the evidence it needed. A team that waits on evidence can miss the date. The change plan has to handle both.

There’s a second problem. The question “is this host fixed” usually can’t be answered from the PHP version string. Ubuntu, Debian and Red Hat backport fixes into older version numbers. A version check alone will produce false alarms on fixed hosts and give false comfort on unfixed ones.

What is php2shell, and who is exposed?

PHP’s advisory describes two critical flaws, each rated CVSS v4.0 9.2, that “can allow unauthenticated remote code execution”:

  • CVE-2026-109618: memory corruption during out-of-memory handling.
  • CVE-2026-109619: stale request state that a later request on the same worker can use.

PHP says the risk applies to “all PHP installations serving web requests.” It names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. “We consider the risk highest for mod_php,” the advisory says. It adds, “There are no complete mitigations, updating is the only safe choice.”

Fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CERT-EU notes that PHP 8.1 and older are end of life and no longer get updates from the PHP project. Because of the severity, the PHP security team published minimal source backports for 7.4, 8.0 and 8.1. CERT-EU also warns that the volunteer-run remirepo “will not have updates on release day.”

Two related issues widen the change:

  • CVE-2026-115560, disclosed October 23, only affects apps that switch the session serializer at runtime. PHP will fix it in the next regular release and says to set session.upload_progress.enabled=0 until then.
  • CVE-2026-111497, a Brotli flaw, joined KEV on October 27 with a November 10 due date. Windows hosts need PHP’s updated 8.x.y-1 builds from October 26 to get the Brotli 1.2.1 fix.

CISA’s alert adds the step most inventories miss: “PHP is often a component of other software and prevalence may not be directly observable.” CERT-EU makes the same point: many commercial and open-source products use PHP as a backend and “could also be affected, even if they do not directly expose a PHP installation.” CISA also says organizations still on PHP 8.1 or earlier “should take PHP-based systems offline until they can be patched or updated.”

What does the forensic triage flag change?

Under BOD 26-04, a KEV entry with the triage flag requires an “adequate forensic triage analysis,” not just a patch. CISA’s guidance lays out six steps with recommended target timelines measured from the KEV addition. It says the timeline is guidance and “the specific timeline below is not required.”

Gantt chart of CISA's six BOD 26-04 forensic triage steps measured in hours after the October 26 KEV addition: scoping 0-2 hours, evidence collection 2-24, critical patching 2-24, containment 6-24, triage analysis 24-48, and escalation decision 48-72, ending at the October 29 due date

Evidence collection and patching share the same window, from 2 to 24 hours. CISA says to grab volatile data first: memory, caches and anything lost when a process restarts. It also says not to “alter or remediate systems prior to evidence/artifact collection when possible.” That matters more than usual here, because the fix also requires restarting every PHP worker, which wipes worker memory.

The last step produces a triage report with a timeline, findings framed as “who, what, where, and when,” containment taken and next steps. For a CAB, that report is the closure evidence. Patching alone doesn’t close the change.

What should you look for? CISA’s alert says to “monitor for suspicious activity, including PHP worker processes launching shells or downloading tools.” On October 23 it added a SIGMA detection rule to its repository. Our BOD 26-04 decision matrix maps each tier to an emergency change track. The Ivanti Connect Secure write-up explains why a patched host isn’t the same as a clean one.

How do you prove a host is fixed?

We put each major channel’s own fix notice in one table. Only the official Docker images ship the upstream version numbers. Every distro row shows a different version you’d need to check.

ChannelExample “fixed” versionSeverity it assignsSource
PHP upstream8.5.12, 8.4.27, 8.3.36, 8.2.35Critical, CVSS v4.0 9.2PHP
Ubuntu 24.04 LTS (php8.3)8.3.6-0ubuntu0.24.04.13CriticalUbuntu
Ubuntu 22.04 LTS (php8.1)8.1.2-1ubuntu2.28CriticalUbuntu
Ubuntu 20.04 and olderESM builds via Ubuntu ProCriticalUbuntu
Debian 13 trixie8.4.27-1~deb13u1 (DSA-6574-1)Not statedDebian
Debian 12 bookworm8.2.35-1~deb12u1 (DLA-4848-1)Not statedDebian
RHEL 10RHSA-2026:87070 (php), RHSA-2026:87071 (php8.4), Oct 21Important, CVSS v3 8.1Red Hat
RHEL 9.6 EUSRHSA-2026:88834 (php:8.2) Oct 23; RHSA-2026:89111 (php:8.3) Oct 26Important, CVSS v3 8.1Red Hat
Docker official imagephp:8.x.y tags matching upstreamNot statedDocker Hub

Three things in this table belong in the change plan.

Version-string scanners mislead. A fixed Ubuntu 24.04 host still reports PHP 8.3.6. A scanner that compares against 8.3.36 will flag it. Meanwhile, a pinned container still running 8.3.35 will pass a scanner that only checks the OS package database. Check the distro’s fixed package version or advisory ID instead. For containers, check the image tag or digest.

Severity ratings disagree. Red Hat rates the flaw Important rather than Critical. Its reasoning is that RHEL 8 and later default to PHP-FPM, whose workers “exit on early initialization failures,” making code execution “difficult in practice.” That’s fair for default RHEL builds, but it doesn’t change the KEV due date or cover mod_php hosts. Red Hat’s own bulletin says “environments running mod_php with default configuration are at higher risk.” Use the KEV tier for scheduling, and the deployment type to decide which hosts go first.

A reload is not a fix. Red Hat says to restart every worker after a change, because “a reload is insufficient because existing workers may retain affected state.” For containers, it says to replace the running container or pod. The bulletin also says to check settings with a temporary phpinfo() page, “rather than php -i, which reports the command-line configuration.” The CLI and web SAPI can load different ini files.

What do the mitigations cost?

PHP, CERT-EU and Red Hat publish the same set of temporary measures. All three say they reduce exposure to specific attack paths but don’t make a host safe. Each one is a change in its own right, with its own breakage risk.

  • session.upload_progress.enabled=0 blocks the confirmed session paths for CVE-2026-109619 and fully covers CVE-2026-115560. Red Hat warns the directive is commented out in RHEL’s shipped /etc/php.ini and defaults to on. Uncommenting the line as shipped leaves the feature enabled, so you have to set it to 0 explicitly. Apps that use PHP’s native upload-progress reporting lose that data.
  • memory_limit=-1 removes the controllable out-of-memory trigger for CVE-2026-109618. Red Hat says not to apply it without a container or cgroup memory limit, because a runaway request could exhaust the host. CERT-EU adds a warning against RLIMIT_AS or RLIMIT_DATA, which “can trigger the vulnerable allocation failure.”
  • A low post_max_size (8M without uploads, 32M with them) narrows the request-size path. It breaks apps that accept larger form posts or uploads.
  • fatal_error_backtraces=0 on PHP 8.5 blocks one confirmed path. It also removes the backtraces your developers use for debugging.

Every setting must be applied with php_admin_value, or wherever it takes effect before request parsing. CERT-EU says not to rely on ini_set() or .user.ini files. Red Hat says to audit .htaccess, virtual-host php_value and .user.ini entries that could switch a setting back per directory.

How should the CAB run it?

We’d run php2shell as one emergency parent change with three linked tracks.

Track A: scope and evidence (hours 0-24). List every host that serves PHP to untrusted traffic, including vendor products that bundle PHP. Our live KEV tracker shows the entries and due dates. Put internet-facing mod_php hosts first. For each in-scope host, capture volatile data and logs before any restart, and keep an evidence log of what you collected and when. CISA’s guidance asks for exactly that.

Track B: patch and restart (hours 2-24, after evidence). Install the distro’s fixed package or upstream release, then restart every worker or replace the pod. Record the advisory ID or image digest for each host. Where patching has to wait, apply the mitigations through php_admin_value, record each one, and plan to remove it. memory_limit=-1 in particular shouldn’t outlive the patch.

Track C: triage and close (hours 24-72). Review logs for signs of compromise, starting with PHP workers spawning shells or downloading tools. Write the triage report and decide whether to escalate. Close the parent change only when every host has three things: patch evidence, a web-SAPI verification and a triage result.

Teams that patched on October 21, before the KEV listing, aren’t done either. The KEV listing means CISA has evidence of exploitation. Any host that was internet-facing before its patch still needs Track C.

PHP’s support schedule ends security support for PHP 8.2 on December 31, 2026. If you’re patching 8.2 hosts this week, schedule their upgrade to 8.3 or later now, as a normal change, so the next emergency doesn’t land on an unsupported branch. More runbooks like this live on our change management hub.

What to do about it

  1. Open one emergency parent change for CVE-2026-109618 and CVE-2026-109619, due October 29. Link CVE-2026-111497 for Windows hosts, due November 10.
  2. Inventory every PHP runtime serving web requests. Include vendor products and appliances that bundle PHP, and mark each by SAPI (mod_php, FPM, CGI, FrankenPHP, LiteSpeed).
  3. Collect evidence before patching on internet-facing hosts: volatile data first, then logs, recorded in an evidence log.
  4. Patch to a fixed package, checking the distro advisory ID or package version rather than the upstream version string.
  5. Restart every worker or replace the pod. A reload doesn’t count.
  6. Verify through the web SAPI with a temporary phpinfo() page, then remove it.
  7. Document any temporary mitigations with a removal date. Apply them via php_admin_value, and check for per-directory overrides.
  8. Finish forensic triage and attach the report to the change before closing it.
  9. Schedule the PHP 8.2 upgrade before its December 31 end of security support, and take any 8.1 or older host offline until it’s upgraded or covered by an LTS vendor.

FAQ

What is php2shell?

php2shell is the name for CVE-2026-109618 and CVE-2026-109619, two PHP flaws rated CVSS v4.0 9.2 that can allow unauthenticated remote code execution. They affect PHP installations that serve web requests. PHP fixed them on October 21, 2026 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

When is the KEV deadline for php2shell?

CISA added both CVEs to the KEV catalog on October 26, 2026 with a due date of October 29. That’s the three-day tier under BOD 26-04. Both entries are also flagged for forensic triage, so a patch alone doesn’t meet the requirement.

Does the forensic triage flag mean I should delay patching?

Not for long. CISA’s guidance puts evidence collection and patching in the same 2-24 hour window and says to collect evidence first where possible. Capture memory and logs on exposed hosts, then patch. Waiting for a full investigation before patching would leave the host exposed.

My Ubuntu server still reports PHP 8.3.6. Is it vulnerable?

Not necessarily. Ubuntu backports fixes without changing the upstream version number. On Ubuntu 24.04, the fixed php8.3 package is 8.3.6-0ubuntu0.24.04.13. Check the installed package version against Ubuntu’s CVE page rather than the PHP version string.

Why does Red Hat rate it Important instead of Critical?

Red Hat says RHEL 8 and later default to PHP-FPM, whose workers exit before reaching the corrupted structures, so code execution is difficult in practice. It also says default mod_php setups are at higher risk. The KEV due date applies whatever the vendor’s rating.

Are the temporary mitigations enough?

No. PHP, CERT-EU and Red Hat all say only an update fully fixes the flaws. Settings like disabling session upload progress or removing the memory limit reduce exposure to known paths. Each one can break functionality, so track it as a change with a removal date.

What about PHP 8.1 and older?

The PHP project no longer supports them. The security team published minimal source backports for 7.4, 8.0 and 8.1, and some distributions ship backported fixes. CISA says organizations on 8.1 or earlier should take PHP systems offline until they’re patched or upgraded.

Sources

#php #php2shell #cisa kev #bod 26-04 #emergency change #forensic triage #patch management

Published October 28, 2026.