CISA adds both PHP2Shell flaws to its exploited list with a three day federal clock but names no evidence

Three days for federal agencies, and no evidence named

CISA's Known Exploited Vulnerabilities catalogue, read at 08:05 to 08:20 GMT on Tuesday 27 October 2026, carries CVE-2026-109618 and CVE-2026-109619, the two PHP flaws known as php2shell. Both entries say they were added on 26 October 2026 and carry a due date of 29 October 2026. That is three days after the addition and eight days after the fixed PHP releases of 21 October (both derived). The catalogue file that holds them, version 2026.10.26, carries a release stamp of 22:24 UTC on 26 October. That is 128.4 hours after the 14:00 UTC release time PHP announced for its fixes and 54.8 hours after the first confirmed shell on a decoy server, recorded in a honeypot operator's report (both derived). The stamp is the file's own; the entries were not separately timed.

What that does not establish is the part worth reading slowly. Neither the entries nor CISA's alert of 26 October says what evidence CISA relied on, where it was seen, or when. CISA's published criteria for the catalogue count attempted exploitation as exploitation, and they count successful code execution on a honeypot as an attempt. So the listing is reliable evidence that CISA judged exploitation had happened. It is not evidence that a production server anywhere was taken over, and it does not say how many were. The same CISA alert page said on 23 October that CISA had not observed successful exploitation; the 26 October revision no longer contains that sentence and replaces it with nothing.

This briefing is a development of two earlier ones, the emergency fixes and the honeypot report of 35 shell starts, both of which said the flaws were not in the catalogue when they were written. They are now. The briefing reads CISA's own pages, the CVE record, NVD and php.net directly. A Hacker News article about the listing is reported to exist, but its page returned a bot check and was not read, so nothing here rests on it. CISA is a government agency, not a vendor, and has no product to sell. Amazon, whose blog is cited once below, sells cloud security services.

The clock, from the first attempt to the due date

Every point on the clock below comes from a page read for this briefing, and every interval is arithmetic on those points (derived). Date only items sit at mid day on the drawing; only the release, the first shell and the catalogue release have a time of day.

Zoom

Three things stand out. First, the catalogue stamp came 5 days 8 hours after the fixes, longer than the three day clock it starts. NVD's change history, read the same morning, records its import of the listing at 01:00 UTC on 27 October, which fits a late evening release on 26 October. Second, the earliest exploitation report on the clock is 17 October, four days before the fixes, from Amazon's own honeypot telemetry. Amazon says the attempt came from an anonymisation network, that it is unclear whether any attempt would have succeeded on a real system, and that PHP2Shell is now seeing broad exploitation attempts in the wild. Its page also tells defenders to investigate from at least 17 October. That advice is Amazon's. Third, the catalogue stamp followed the first confirmed shell on decoys by 2 days 6 hours 49 minutes (derived). The record does not link the two. CISA names no sensor, so that the honeypot report prompted the listing is a reading that fits the order of events, not something any page states.

The 23 October point matters too. CISA's alert, revised that day, said it had not observed successful exploitation of the vulnerabilities in the wild as of publication (read in a copy saved on 26 October for the earlier briefing). The page as read on 27 October, revised 26 October, says only that CISA added the two entries to the catalogue and updated the alert. Between 23 and 26 October, the honeypot operator published the shells and the catalogue changed. SecurityWeek, on 23 October, reported attempts but no confirmed compromise (secondary). Whether CISA's evidence is the honeypot report, a private report, or something else is not stated.

What the entry binds, and for whom

Both entries cite BOD 26-04, not BOD 22-01, which many readers will remember as the directive behind the catalogue. BOD 26-04, Prioritizing Security Updates Based on Risk, was issued on 10 June 2026 and, in its own words, supersedes and revokes BOD 22-01 and BOD 19-02. CISA's criteria page says it carries the catalogue criteria forward. The directive binds Federal Civilian Executive Branch agencies only, and CISA's 26 October alert says so: BOD 26-04 "applies only to FCEB agencies", while CISA encourages everyone else to prioritise catalogue entries.

The directive replaces one fixed catalogue clock with a table. The days an agency has depend on four things: whether the asset is publicly exposed, whether the flaw is in the catalogue, whether an adversary can automate every step, and whether exploitation gives total or partial control. CISA's own figure is below.

Zoom

Here is the derived reading. The CVE.org record for each flaw carries a CISA ADP block, dated 21 October, with technical impact total and automatable no. For a publicly exposed asset, with those values, the table gives row 7, 14 days, while the flaw is out of the catalogue. Once it is in, the same asset falls in row 3: 3 days and forensic triage. That matches the entries as printed, which say three days and forensicTriage Yes. So the listing did not change what the flaw can do. It cut the time an exposed federal asset has from 14 days to 3 and added a duty to check whether the machine was already compromised. CISA's implementation guidance says the due date in the catalogue is the one to follow, and that each agency decides for itself whether an asset is exposed. For scale, 141 entries in the same file carry a dateAdded of 10 June 2026 or later; 115 of them have a three day due date and 93 are marked forensicTriage Yes (all derived). A three day clock with triage is now the usual outcome for an exposed, total control flaw, not a special alarm for PHP.

One more observation, offered as an observation. The CVE.org and NVD records for both flaws still carry that ADP block as read on 27 October, with its 21 October time stamp and an exploitation value of none, even though the CVE.org record itself was last updated at 03:55 UTC that morning. Two CISA data points read the same morning therefore disagree on exploitation. The table keys on catalogue membership, not on that field, so the clock is unaffected, but anyone scoring from the ADP block alone would still read these flaws as unexploited.

Stated and not stated: the record, line by line

"Not stated" means not found in the catalogue entries, CISA's alert pages, the criteria page, BOD 26-04 or its guidance as read. It does not mean the information does not exist.

Zoom

The criteria page is short and worth quoting once. It says active exploitation is shown by "reliable evidence that the vulnerability has been actively exploited in the wild", that this includes attempted exploitation, and that a successful run on a honeypot counts as an attempt. It also says scanning, security research and public proof of concept code do not qualify. That last rule is relevant here. Amazon says proof of concept code appeared within hours of the fixes on 21 October, and the entries came five days later. Why CISA waited, and what tipped it, is not stated.

The labels around the listing, and what each one does not do

The friendly name fallacy here is the word known. A catalogue called Known Exploited Vulnerabilities invites a reader to assume a known victim, a known attacker and a known method. The entries give none of the three. What the catalogue does give is a reason to move a flaw up a queue, and that is exactly how CISA says to use it. A security lead who reads the listing as proof of compromise will overreact to some servers and, worse, may under react to the rest by assuming only the listed pattern matters.

What the two flaws are, and which builds are affected

The CVE.org records, published by PHP as the CNA on 21 October and read on 27 October, name them. CVE-2026-109618 is titled "RCE via OOM corruption": PHP uses longjmp() for out of memory errors to abandon a request, some contexts leave request memory uninitialised, and cleanup may then read or branch on it. CVE-2026-109619 is "RCE via stale global state": global state that points into request memory may not be reset, or may be repopulated after being reset, and a later request may use the stale state. The catalogue's names, memory corruption and stale internal request state, are CISA's own words for the same two defects.

Both records list PHP 8.2.x below 8.2.35, 8.3.x below 8.3.36, 8.4.x below 8.4.27 and 8.5.x below 8.5.12 as affected. NVD's configuration data, read the same morning, is wider: it lists 7.3.0 and later for CVE-2026-109618 and 5.4.0 and later for CVE-2026-109619, plus embedded products such as Siemens RUGGEDCOM APE1808 firmware and Palo Alto Networks PAN OS versions. CISA's alert says all PHP installations serving web requests are affected, including Apache with mod_php, which it notes PHP considers highest risk, PHP FPM, php cgi, FrankenPHP and LiteSpeed. PHP 8.1 and older no longer receive project updates, and CISA says to take such systems offline until they are patched or updated.

PHP's own advisory says the risk is highest for mod_php, with a demonstrated exploit where an unauthenticated request triggers the attack before any application code runs. The honeypot operator's report matches that profile: PHP 8.4.26, one Apache worker, a 128 MiB memory limit. It is the same report as before, covering decoys only, and it calls the profile intentionally favourable. Nothing read for this briefing shows how the chain fares on a busy server with many workers or on PHP FPM, which is the open question the honeypot briefing left.

The third flaw, CVE-2026-115560, is not in the catalogue: the KEV JSON as read holds no entry for it, and the CVE services API answers that no record exists for that identifier. PHP's 23 October note says it will publish a full advisory with the next regular release and suggests session.upload_progress.enabled=0 until then. Earlier briefings cover the unpatched session upload flaw and the serialization bypass. A catalogue listing for the first two says nothing about it.

Technical details

Everything in the code blocks below was copied or generated from pages saved on 27 October 2026 (GMT), with the source named in each caption. Attacker addresses are defanged. This site adds no exploit detail: the sources print no working exploit, and request bodies and offsets are left out.

The catalogue entry. The block below prints the entry for CVE-2026-109618 and the header of the catalogue file. The entry for CVE-2026-109619 is identical in every field except the ones printed in the second block. The requiredAction text cites BOD 26-04 and the forensic triage requirements; the notes field holds links, not indicators. Agencies and anyone mirroring the catalogue can match on these field names, and the forensicTriage field appears on every entry in the file.

catalogVersion: 2026.10.26
dateReleased: 2026-10-26T22:24:24.6101Z
count: 1758

cveID: CVE-2026-109618
vendorProject: PHP Group
product: PHP
vulnerabilityName: PHP Memory Corruption Vulnerability
dateAdded: 2026-10-26
shortDescription: PHP contains an out-of-memory corruption vulnerability that allows for unauthenticated remote code execution.
requiredAction: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
dueDate: 2026-10-29
knownRansomwareCampaignUse: Unknown
forensicTriage: Yes
notes: This vulnerability affects an open-source component, third-party library, protocol, or proprietary implementation that could be used by different products. For more information, please see: https://www.php.net/ ; https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching ; BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk ; Forensics Triage Requirements: https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk ;  https://nvd.nist.gov/vuln/detail/CVE-2026-109618
cwes: CWE-416, CWE-755, CWE-824, CWE-1325, CWE-1419

cveID: CVE-2026-109619
vulnerabilityName: PHP Stale Internal Request-State Vulnerability
shortDescription: PHP contains a stale internal request-state vulnerability that allows for unauthenticated remote code execution.
notes: This vulnerability affects an open-source component, third-party library, protocol, or proprietary implementation that could be used by different products. For more information, please see: https://www.php.net/ ; https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching ; BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk ; Forensics Triage Requirements: https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk ;  https://nvd.nist.gov/vuln/detail/CVE-2026-109619

Versions and scores. These are the affected ranges, the CVSS 4.0 vector and the CISA ADP block as the CVE.org records print them. Check the PHP that serves web requests, not only the command line binary, because a server can run a different build.

CVE-2026-109618 (RCE via OOM corruption), state PUBLISHED, published 2026-10-21T13:48:34.845Z
  affected 8.2.* lessThan 8.2.35 (semver)
  affected 8.3.* lessThan 8.3.36 (semver)
  affected 8.4.* lessThan 8.4.27 (semver)
  affected 8.5.* lessThan 8.5.12 (semver)
  CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N  base 9.2 CRITICAL (assigned by the CNA, PHP)
  CISA ADP SSVC block: timestamp 2026-10-21T00:00:00+00:00, options Exploitation none, Automatable no, Technical Impact total, role CISA Coordinator
CVE-2026-109619 (RCE via stale global state), state PUBLISHED, published 2026-10-21T13:54:43.866Z
  affected 8.2.* lessThan 8.2.35 (semver)
  affected 8.3.* lessThan 8.3.36 (semver)
  affected 8.4.* lessThan 8.4.27 (semver)
  affected 8.5.* lessThan 8.5.12 (semver)
  CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N  base 9.2 CRITICAL (assigned by the CNA, PHP)
  CISA ADP SSVC block: timestamp 2026-10-21T00:00:00+00:00, options Exploitation none, Automatable no, Technical Impact total, role CISA Coordinator

Checking a distribution package. Fixes are often backported without a version change, so php -v alone can mislead. Cloudflare's post offers a prompt for an assistant that prints two ways to look in the package changelog; the placeholder is Cloudflare's.

apt changelog <php-pkg> | grep -E "CVE-2026-10961[89]"
rpm -q --changelog <php-pkg> | grep -E "CVE-2026-10961[89]"

Stopgap settings. PHP lists these for when an update is impossible and says they reduce exposure to specific attack paths but do not make an installation safe. CISA's own alert says a web application firewall may provide some protection until patched.

If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

RCE via OOM corruption (CVE-2026-109618):

Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.

Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.

Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

RCE via stale global state (CVE-2026-109619):

Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.

On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.

Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.

Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.

What to hunt for. CISA's alert tells defenders to watch for PHP worker processes launching shells or downloading tools. CISA's Sigma rule, published on 21 October and last modified on 23 October, searches request, error and process strings. The excerpt below keeps its detection strings and its own warning that the false positive rate is medium to high, so tune it. Its list of 36 indicators, which includes live addresses and hashes, is in CISA's repository and is omitted here.

title: Detects PHP2Shell CVE-2026-109618 CVE-2026-109619 RCE Exploitation Attempts
tlp: CLEAR
author: CISA
date: 2026-10-21
modified: 2026-10-23
detection:
    keywords:
        - 'POST'
    keywords_1:
        - 'index.php'
    keywords_2:
        - 'PHPSESSID'
    keywords_3:
        - 'PHP_SESSION_UPLOAD_PROGRESS'
    keywords_4:
        - 'php2shell'
        - 'B7kQpoc61'
        - 'BNDRY12345'
        - 'filename'
        - 'multipart/form-data'
        - 'Content-Disposition: form-data'
        - 'application/x-www-form-urlencoded'
        - 'aaaaaaaaaaa'
        - 'AAAAAAAAAAA'
        - 'bbbbbbbbbbb'
        - 'BBBBBBBBBBB'
        - 'VVVVVVVVVVV'
        - 'SSSSSSSSSSS'
        - 'ppppppppppp'
        - 'pwn'
    keywords_5:
        - 'PHP_SESSION_UPLOAD_PROGRESS'
    keywords_6:
        - 'php-cgi'
        - 'apache2'
        - 'httpd'
        - 'php-fpm'
        - 'mod-php'
    keywords_7:
        - '/bin/sh'
        - '/bin/bash'
        - 'cmd'
        - 'powershell'
        - 'python'
        - 'curl'
        - 'wget'
        - 'netcat'
        - 'nc'
        - 'whoami'
        - 'id'
        - 'uname '
    keywords_8:
        - 'PHP Fatal error:'
    keywords_9:
        - 'Allowed memory'
    keywords_10:
        - ' in Unknown '
    keywords_11:
        - '<'
    keywords_12:
        - 'php'
    keywords_13:
        - 'echo'
    keywords_14:
        - 'system'
    keywords_15:
        - "($_GET['"
    keywords_16:
        - '>'
    keywords_17:  [36 entries, omitted here: 14 IPv4 addresses, 9 hashes, 3 domains and 10 other strings]
falsepositives:
    - Rate of FP medium-high with some strings/branches. 
    - Use this rule in an infected environment/logs.
    - Analyst may need to tune and make adjustments to the query as required.
level: critical

What a confirmed execution looked like. This is the first execution timeline the honeypot operator printed for a decoy running PHP 8.4.26 under Apache mod_php. It shows the shape defenders can look for in their own logs: two memory errors before application code, a large cookie, then a shell whose parent is Apache and a worker that crashes. The report says HTTP 200 on the earlier requests is not the success test. It is one captured chain on a favourable profile, not a rate.

15:35:32.793  15[.]204[.]59[.]70:54952  A1 POST begins; complete 1,060,211-B decoded body
15:35:33      PHP: Allowed memory size of 134217728 bytes exhausted
                (tried to allocate 4096 bytes) in Unknown on line 0
15:35:34.127  15[.]204[.]59[.]70:38108  B1 POST begins; 33,128,677-B decoded body
15:35:34.205  Apache access record (request timestamp): worker PID 31;
                disclosure-sized Set-Cookie reported for this request
15:35:37.429  15[.]204[.]59[.]70:38122  A2 POST begins; 279,369-B body
15:35:37      PHP: Allowed memory size of 134217728 bytes exhausted
                (tried to allocate 20480 bytes) in Unknown on line 0
15:35:38.238  15[.]204[.]59[.]70:38126  B2 POST begins; 451,384-B body
15:35:38.673  Tetragon: apache2 → /bin/sh, UID 33; /bin/sh → /usr/bin/id
15:35:39.379  Apache: child PID 31 exited on Segmentation fault (11)

UK: what the NCSC alert says, and what it predates

The UK National Cyber Security Centre published its alert on 21 October 2026. It says organisations using any version of PHP are affected, tells them to identify PHP systems and update internet facing ones first, and to consider taking a system offline if it cannot be updated or mitigated. It adds that anyone unable to update or disable a system immediately should assess it for evidence of compromise before the upgrade and look for backdoors. The page, as read on 27 October, shows no later revision, does not mention the catalogue and does not say the flaws are being exploited. BOD 26-04 and the 29 October date do not apply to UK organisations. What carries over is the order of work: the NCSC and CISA both say to find PHP first, and CISA's guidance puts evidence collection before changes on a suspect machine.

What to do, in the order worth doing it

The question that exposes the gap

CISA's listing says someone has reliable evidence that these flaws were used, and it does not say where. If that evidence includes attempts from 17 October onward, which of your servers answered a request that fits the sequence between then and your patch, and who is reading those logs today?

Key facts