Two Critical PHP Vulnerabilities Added to CISA KEV, Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35: Patch and Restart Now

Update (31 Oct 2026): We updated the vendor-action section at the end of this advisory and added a direct way to talk to a Rescana expert. The technical details, CVEs, fixed PHP versions, KEV status and sources are unchanged and reflect our checks as of 27 October 2026.

Update (27 Oct 2026): CISA has added both flaws to its Known Exploited Vulnerabilities (KEV) catalog. On 26 October, CISA added CVE-2026-109618 ("PHP Memory Corruption Vulnerability") and CVE-2026-109619 ("PHP Stale Internal Request-State Vulnerability") to the KEV catalog and updated its PHP alert to reflect the addition (CISA). CISA says potential KEV additions "must have a CVE ID, evidence of exploitation, and clear mitigation guidance". The KEV catalog gives US federal civilian agencies a due date of 29 October 2026 for both CVEs, with the required action: "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." KEV flags both CVEs for forensic triage and lists known ransomware campaign use as "Unknown" (CISA KEV catalog; catalog version 2026.10.26, checked 27 Oct 2026, 08:08 Israel time (UTC+2)). BOD 26-04 applies only to federal civilian agencies, but CISA "encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities" (CISA). CISA's PHP alert no longer carries its 21 October line that CISA had not observed exploitation (CISA). SecurityWeek reports that on 24 October a researcher's honeypots, running PHP 8.4.26 under Apache mod_php with a single worker, recorded attackers running shell commands in activity the researcher called consistent with exploitation of CVE-2026-109618; SecurityWeek says no second-stage payload download was observed, and quotes the researcher as saying the evidence "is not a measurement of exploit reliability on other worker counts, PHP builds, or applications" (SecurityWeek). Rescana has not independently confirmed any compromise. Since our last update, watchTowr, Amazon, Hadrian and NCSC-NL have revised their pages, NVD has changed its score for CVE-2026-109619, and PHP has published an informational advisory on a related, "unlikely RCE vector"; we have updated those quotes and details below. Patch and restart now, and check exposed PHP servers for signs of compromise.

Update (22 Oct 2026, morning): Security companies now report exploitation attempts in the wild against CVE-2026-109618 and CVE-2026-109619, and Hadrian and Amazon now describe exploitation attempts happening at scale or broadly; CISA and the Canadian Centre for Cyber Security said in their 21 October alerts that they had not observed or identified exploitation, and at that time neither CVE was yet listed by CISA as known exploited (checked 22 Oct 2026, 08:24 Cyprus time (UTC+3), catalog version 2026.10.21; CISA added both on 26 October, see the update above). watchTowr says it "has observed exploitation of both CVE-2026-109618 and CVE-2026-109619 in the wild" (watchTowr), and its FAQ says this was "through watchTowr’s Attacker Eye global honeypot network" (watchTowr FAQ); SecurityWeek reported that watchTowr "has not observed successful attempts" (SecurityWeek). Amazon says its MadPot honeypot network recorded an exploitation attempt dated 17 October, "four days before public disclosure", that "it's unclear if any of these attempts would have succeeded in real-world systems", and, in its current wording, that "PHP2Shell is now seeing broad exploitation attempts in the wild" (Amazon). Hadrian now says "we are now seeing php2shell exploitation attempts in the wild" (Hadrian). Patchstack logged "Multiple active exploitation incidents reported to Patchstack by hosting partners" on the morning of 21 October; shortly after PHP's release, it said "our telemetry shows only probing attacks, with no hard evidence of breaches yet" (Patchstack). Cloudflare, as reported earlier, says it "observed attack traffic targeting our customers". CISA's alert said at the time that CISA had not observed exploitation (CISA has since removed that line), and the Canadian Centre for Cyber Security says there is "no active exploitation being identified at this time, but that can change quickly" (Canadian Centre for Cyber Security). Rescana has not independently confirmed any compromise. NSA has also revised its statement; we have updated its title and quotes below. Patch and restart now. Check exposed servers for signs of compromise from 17 October onward, the date Amazon advises investigating from (Rescana guidance).

Update (21 Oct 2026, night): CISA has published an alert, "Critical Vulnerabilities in PHP Require Immediate Patching" (CISA). CISA "strongly urges organizations to immediately patch" CVE-2026-109618 and CVE-2026-109619 and says organizations "should immediately update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35". At the time, CISA's alert also said CISA had not observed exploitation; that line has since been removed. NSA has also published a statement, now titled "NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities", saying "If an immediate update is not feasible, it is recommended that organizations take the system offline until it can be fully mitigated" (NSA). The CISA alert was not itself a KEV listing: when we checked on 22 Oct 2026, 08:24 Cyprus time (UTC+3), neither CVE was yet listed (catalog version 2026.10.21). CISA added both to KEV on 26 October. We have added CISA's and NSA's recommended actions below, attributed to each. Patch and restart now.

Update (21 Oct 2026, evening): The researchers who found the flaws (Wiz Research, OpenAI Codex Security and Calif) have published their official disclosure site, php2shell.com. They say CVE-2026-109619 can also leak server memory, including passwords, authentication tokens, API keys and certificates from other requests, without remote code execution (PHP's own advisory also lists memory disclosure as a confirmed impact); that affected releases date back to PHP 5.4; and that Apache, PHP-FPM and long-running PHP workers must be restarted after upgrading. We have added their findings, investigation hints and restart guidance below, attributed to them. Cloudflare now says it "observed attack traffic targeting our customers" (Cloudflare); PHP's security team says it "did not identify any functional exploits at the time of release/public disclosure" (PHP Foundation). Status as of 22 Oct 2026, 08:24 Cyprus time (UTC+3): neither CVE was yet listed in KEV (catalog version 2026.10.21); NVD had analysed both and scored them CVSS v3.1 9.8 at that point; PHP, the CNA, rates them CVSS v4.0 9.2. Both are now in KEV, and NVD has since changed one score; see the CVE / KEV status below. Patch and restart now.

Update (21 Oct 2026): PHP has shipped its security release. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix the two vulnerabilities, which PHP now confirms are CVE-2026-109618 and CVE-2026-109619. PHP's CNA rates both CVSS v4.0 9.2 (Critical). Both CVEs are published on cve.org; NVD received both records on 21 October and listed them as "Received" at that time, with no NVD score yet (it showed PHP's 9.2). At that time, neither CVE was yet listed in CISA's Known Exploited Vulnerabilities (KEV) catalog (catalog version 2026.10.20, checked 21 Oct 2026, 17:29 Cyprus time). PHP says "updating is the only safe choice" (PHP 8.2.35 release announcement). Patch now.

PHP has released fixes for two critical vulnerabilities that can allow unauthenticated remote code execution (RCE) on servers that run PHP to serve web requests. PHP rates both CVSS v4.0 9.2 (Critical). The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. PHP's GitHub security advisories were published at 13:34 UTC (16:34 Cyprus time), ahead of the scheduled 14:00 UTC release time. On 26 October, CISA added both flaws to its Known Exploited Vulnerabilities catalog, with a 29 October due date for US federal civilian agencies (CISA).

PHP's security advisory says "all PHP installations serving web requests" are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers the risk "highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." The advisory says "only an update is a complete solution" (PHP security advisory), and PHP's release announcements say "There are no complete mitigations, updating is the only safe choice" (PHP 8.2.35 release announcement).

The researchers who found the flaws say PHP powers "approximately 70% of websites", including WordPress, Drupal and Wikipedia's MediaWiki (php2shell.com). It is very likely to be somewhere in your vendors' stacks.

Technical Information

PHP describes the two flaws as follows (php.net security advisory and GitHub advisories):

CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partly initialized, and request cleanup may then treat the invalid data as valid. CWEs listed by PHP: CWE-416, CWE-755, CWE-824, CWE-1325, CWE-1419.
CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its memory has been freed, and a later request handled by the same worker may use that stale state (a use-after-free). Same CWE list.

Both have the CVSS v4.0 vector AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (score 9.2) from PHP as CNA. For CVE-2026-109618, PHP says complete remote code execution "was validated over HTTP against mod_php", and that source analysis supports PHP-FPM as susceptible, "though no complete FPM exploit has been demonstrated". For CVE-2026-109619, PHP says "Session lifecycle RCE was validated against mod_php and FPM"; it adds that the FPM path "depends on a suitable application operation" (GHSA-6wmf-4rv5-p3rp). This advisory does not cover how to exploit the flaws.

What the researchers say. The researchers who found the flaws say they demonstrated unauthenticated ("pre-authentication") remote code execution on WordPress, Drupal and Joomla through CVE-2026-109618, and on WordPress and Drupal through CVE-2026-109619, "using their latest container images at the time of testing" (php2shell.com). They describe these as "representative targets" and say "Exploitation does not require one of those applications": "The vulnerable code is in PHP itself", and websites "can be affected even when their application code is secure, including a simple 'Hello World' application running on an affected PHP version." On PHP-FPM, the researchers say "PHP-FPM RCE was confirmed through application-level code paths". This sits alongside PHP's own FPM statements above (GHSA-6wmf-4rv5-p3rp).

The researchers also say CVE-2026-109619 can be used to "disclose worker memory" instead of executing code. They report demonstrating "application-agnostic remote memory disclosure", and say leaked PHP process memory may contain "passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself", which "can be disclosed without first achieving remote code execution". PHP's own advisory for CVE-2026-109619 also says "The confirmed impact is unauthenticated heap use-after-free, memory disclosure and remote code execution with the web worker's privileges" (GHSA-6wmf-4rv5-p3rp); the detail about which secrets the leaked memory may contain comes from the researchers.

PHP's CVE records credit Ryan at Calif.io, Wiz and OpenAI with reporting or finding the flaws, and PHP developers Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka and Nora Dossche with the fix. The researchers' disclosure site credits Wiz Research (Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz), OpenAI Codex Security (Amy Burnett) and Calif (Ryan A.).

Timeline (UTC):

17 Oct 2026: Amazon says its MadPot honeypot network recorded a PHP2Shell exploitation attempt dated 17 October, "four days before public disclosure", and that "it remains unclear how the actor acquired exploit information prior to disclosure" (Amazon).
20 Oct 2026: The PHP Foundation says the two CVE IDs "began circulating on online forums and social media" at around 15:00 UTC, with a wrong release time and a wrong CVSS score of 10.0, and that "No technical details leaked" at that point. PHP posts an advance notice on php.net: one release, two critical vulnerabilities, both CVSS v4.0 9.2, now scheduled for 21 October at 14:00 UTC. The PHP Foundation says PHP moved the release forward from 22 October (PHP Foundation).
21 Oct 2026, around the release:
CERT-EU updates Security Advisory 2026-018 to v1.1 after the release; its version history dates v1.0 to 20 October and v1.2, which adds information about a third vulnerability, to 23 October (CERT-EU).
Cloudflare says its WAF protections were on by default from 03:02 UTC and that "we observed attack traffic targeting our customers"; it has not published indicators of compromise (Cloudflare).
At 07:34, Patchstack logs "Multiple active exploitation incidents reported to Patchstack by hosting partners"; at 13:57, shortly after PHP's release, it says "our telemetry shows only probing attacks, with no hard evidence of breaches yet" (Patchstack).
At 11:35, Hadrian says it is seeing php2shell exploitation attempts in the wild; at 14:35, after the release, it says "exploitation attempts are still happening at scale" (wording as currently on Hadrian's page) (Hadrian).
The PHP Foundation says proof-of-concept code circulated after the leak, but that PHP's security team "did not identify any functional exploits at the time of release/public disclosure" (PHP Foundation).
After the release, CERT-EU said "initial proofs of concept (PoCs) have begun to circulate" and that this "raises the likelihood that attackers are already exploiting the vulnerabilities" (CERT-EU).
21 Oct 2026, 13:34: PHP publishes the two GitHub security advisories.
21 Oct 2026, 13:48 and 13:54: PHP, as CNA, publishes the CVE-2026-109618 and CVE-2026-109619 records on cve.org.
21 Oct 2026: PHP announces PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on php.net, each "a security release fixing two critical vulnerabilities (CVE-2026-109618, CVE-2026-109619)". PHP's releases feed and announcements date the releases 21 October; PHP's ChangeLog lists them under 22 October, the original disclosure date.
21 Oct 2026, 14:17: NVD receives both CVE records (status "Received").
21 Oct 2026, 14:19: watchTowr publishes its analysis; its revised page now says "watchTowr has observed exploitation of both CVE-2026-109618 and CVE-2026-109619 in the wild" (watchTowr). Its FAQ now says "Exploitation has been observed in the wild since October 21, 2026, through watchTowr’s Attacker Eye global honeypot network" (watchTowr FAQ). SecurityWeek reported that watchTowr "has not observed successful attempts" (SecurityWeek).
21 Oct 2026, by 16:32: The researchers' official disclosure site, php2shell.com, is live (Rescana checked it at 16:32 UTC, 19:32 Cyprus time). NVD lists both CVEs as "Undergoing Analysis" at that point. CISA's KEV catalog version 2026.10.21, released at 14:04 UTC, did not include either CVE.
21 Oct 2026, 17:00 and 17:01: NVD completes its initial analysis of CVE-2026-109618 and CVE-2026-109619 (status "Analyzed") and initially scores both CVSS v3.1 9.8, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (NVD).
21 Oct 2026 (CISA gives the date only): CISA publishes the alert "Critical Vulnerabilities in PHP Require Immediate Patching". It says the flaws "allow for unauthenticated remote code execution in PHP" and that "The vulnerabilities affect all PHP installations serving web requests" (CISA). As first published, the alert said CISA had not observed exploitation; it did not then add either CVE to the KEV catalog.
21 Oct 2026 (NSA gives the date only): NSA publishes a press release, since revised and now titled "NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities". The current version says "All users should immediately conduct an inventory, where feasible, of hardware/software services reliant on now-vulnerable PHP versions" and recommends "Adding enhanced logging within network/operational environments" and "Replacing end-of-life PHP services which will not be compatible with patching" (NSA); Rescana read the revised statement on 22 Oct 2026, 08:08 Cyprus time (UTC+3).
21 Oct 2026 (the Cyber Centre gives the date only): The Canadian Centre for Cyber Security publishes Alert AL26-026. It says the Cyber Centre "has observed open-source reporting indicating that a Proof of Concept (PoC) is available, with no active exploitation being identified at this time, but that can change quickly" (Canadian Centre for Cyber Security).
21 Oct 2026 (Amazon gives the date only): Amazon says it saw "additional exploitation attempts of PHP2Shell targeting MadPot" between 02:00 and 08:00 UTC, and that "it's unclear if any of these attempts would have succeeded in real-world systems". After the release, it says "PHP2Shell is now seeing broad exploitation attempts in the wild" and "With PHP2Shell, compromise may predate the advisory" (Amazon).
22 Oct 2026, 20:45: NVD changes its CVSS v3.1 score for CVE-2026-109619 to 8.1, vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (attack complexity high) (NVD).
23 Oct 2026: CISA updates its alert to "provide a SIGMA detection rule to help identify potentially suspicious activity", "incorporate partner resources" and "reinforce existing mitigation guidance" (CISA). PHP publishes an informational advisory suggesting session.upload_progress.enabled=0 "to fully protect from an unlikely RCE vector", a related issue it will publish a full advisory for (CVE-2026-115560) with the next release (PHP). Siemens publishes SSA-566512 for RUGGEDCOM APE1808 devices running Palo Alto Networks PAN-OS (Siemens).
24 Oct 2026: A researcher's honeypots record attackers running shell commands, in activity the researcher called consistent with exploitation of CVE-2026-109618 on a deliberately favourable single-worker mod_php setup, according to SecurityWeek's report of 26 October (SecurityWeek).
26 Oct 2026: CISA adds CVE-2026-109618 and CVE-2026-109619 to the KEV catalog, with a due date of 29 October 2026 for federal civilian agencies, and updates its PHP alert "to reflect the addition" (CISA; CISA alert). KEV catalog version 2026.10.26 was released at 22:24 UTC (CISA KEV catalog).

CVE / KEV status (checked 27 Oct 2026, 08:08 Israel time (UTC+2)): Both CVEs are published on cve.org by PHP. Both are in CISA's KEV catalog, added on 26 October 2026 with a due date of 29 October 2026, required action as quoted in the update above, forensic triage flagged, and known ransomware campaign use "Unknown" (catalog version 2026.10.26) (CISA KEV catalog). NVD lists both as "Analyzed". NVD scores CVE-2026-109618 at CVSS v3.1 9.8, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (NVD). On 22 October NVD changed its score for the second flaw to 8.1 (High), vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, so NVD now rates its attack complexity high (NVD: CVE-2026-109619). PHP, the CNA, still rates both at CVSS v4.0 9.2, vector AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, which NVD shows as a secondary score. CISA's ADP enrichment on both CVE records still shows the SSVC rating it set on 21 October (exploitation "none", automatable "no", technical impact "total"); the KEV listing is CISA's newer statement on exploitation.

Affected Product Versions

Branch	Affected (PHP CNA record)	Fixed version
PHP 8.5	8.5.x before 8.5.12	8.5.12
PHP 8.4	8.4.x before 8.4.27	8.4.27
PHP 8.3	8.3.x before 8.3.36	8.3.36
PHP 8.2	8.2.x before 8.2.35	8.2.35
PHP 8.1 and older	No longer supported by the PHP project	No official release; see below

PHP 8.1 and older: PHP says these branches "no longer receive updates from the PHP project". Some distributions and LTS vendors provide backported fixes. PHP's security team also "provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor". In our reading, these are source branches in PHP's GitHub repository, linked from PHP's advisory, not official releases. PHP has not said whether versions older than 7.4 are affected. The researchers who found the flaws say they "identified affected releases dating back to PHP 5.4, with nearly every PHP version affected by at least one issue before the fix", and that exposure "depends on the version, configuration and individual vulnerability" (php2shell.com). PHP itself has not published an affected range below its supported branches: its CVE records list only 8.2 to 8.5. NVD's own configuration now lists PHP from 7.3.0 before 8.2.35 as vulnerable for CVE-2026-109618 and from 5.4.0 before 8.2.35 for CVE-2026-109619, plus 8.3.0 before 8.3.36, 8.4.0 before 8.4.27 and 8.5.0 before 8.5.12 for both (NVD: CVE-2026-109618, NVD: CVE-2026-109619). These ranges are NVD's product configuration, not a statement by PHP about which older versions are affected.
Distribution and vendor packages: PHP says Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
Products that embed PHP: Vendors are publishing their own assessments. Palo Alto Networks has published "Impact of Critical Vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619) on Palo Alto Networks Products", says it "is not aware of any malicious exploitation of this issue against our products", and says the risk on PAN-OS and Panorama "is minimized by restricting access to the management interface to only trusted internal IP addresses" (Palo Alto Networks). Siemens lists RUGGEDCOM APE1808 devices running affected PAN-OS versions in SSA-566512 (Siemens). Check each vendor's advisory for affected versions and fixes.
PHP also notes that PHP 8.2 reaches end of life on 31 December 2026.

Workaround and Mitigation

Update now. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (PHP security advisory, downloads), or install your distribution's or vendor's patched package. Then restart Apache, PHP-FPM and any long-running PHP workers so the fixed runtime is actually loaded. The researchers who found the flaws call installing a fixed release and restarting "the only complete fix", and warn: "Updating an application does not update the PHP runtime beneath it." A WordPress, Drupal or other application update on its own does not fix these flaws (php2shell.com). Prioritise internet-facing PHP applications, starting with mod_php deployments, which PHP rates as highest risk. (PHP rates the risk highest for mod_php, but do not defer PHP-FPM: PHP says it validated remote code execution against FPM for CVE-2026-109619.) CISA likewise says: "Apply the patch immediately, prioritizing internet-facing systems" (CISA).
Inventory PHP everywhere. Look beyond your web servers: include PHP runtimes bundled inside applications, container images, hosting control panels, and vendor appliances or virtual appliances that ship their own PHP. Record the version and who maintains each one. (Rescana guidance.) CISA says to "Identify and inventory systems running any version of PHP across your organization", warning that "PHP is often a component of other software and prevalence may not be directly observable" (CISA). To find third-party software that embeds PHP, CERT-EU recommends the NCSC-NL GitHub repository (CERT-EU), which NCSC-NL describes as operational information, including detection and mitigation material and inventory lists of software products with a PHP dependency potentially affected by the vulnerabilities; NCSC-NL says "The repository is being updated as the situation develops" (NCSC-NL php2shell repository).
Unsupported branches. For PHP 8.1 and older, PHP says to contact your distribution or LTS vendor for backported fixes, or upgrade to a supported version (PHP security advisory). PHP's source backports for 7.4, 8.0 and 8.1 are a fallback for people who build from source.
If you cannot update immediately. These steps are only for systems that cannot be patched right away. PHP says its temporary measures "reduce exposure to specific attack paths but do not make an installation safe" (PHP security advisory). For CVE-2026-109618, PHP's measures include setting memory_limit=-1 "preferably in a way applications can't override", a low post_max_size, and request-size limits at the web server or proxy. PHP says an underlying allocation failure "can still reach the vulnerable path". PHP also warns: "Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure"; the researchers repeat this warning. The researchers add that memory_limit=-1 "transfers memory-exhaustion handling to the operating system", so memory-exhausted workers "may be terminated, interrupting requests and affecting stability and availability of the server", and that the measure "does not cover application-specific large-allocation paths or non-memory-related triggers" (php2shell.com). For CVE-2026-109619, PHP says to set session.upload_progress.enabled=0 (and on PHP 8.5, fatal_error_backtraces=0) in php.ini, an FPM pool or server configuration, not with ini_set() or .user.ini, and to restart every worker. PHP says this "blocks the confirmed session paths but not other variants". See PHP's advisory for the full list and caveats. On 23 October, PHP also suggested setting session.upload_progress.enabled=0 "until the next regular bugfix release", "to fully protect from an unlikely RCE vector"; PHP says this issue "can only occur under an unusual combination of configuration and application code", that anyone who already applied the setting needs no further action, and that it will publish a full advisory for CVE-2026-115560 with the next release (PHP informational advisory).
Compensating controls (if you can't patch or apply PHP's measures). The UK NCSC says that if you are unable to apply the temporary mitigations, or applying them would take too long, you "should consider taking the system offline until it can be fully mitigated". CERT-EU says that where patching is not feasible, "organisations should consider isolating internet-facing applications from public networks until a fix is applied and verified". CISA says organizations "that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated", and that "A web application firewall may provide some protection until systems are updated or patched" (CISA). NSA likewise says: "If an immediate update is not feasible, it is recommended that organizations take the system offline until it can be fully mitigated" (NSA). Cloudflare says "Customers should patch their PHP repos even with WAF protections providing an additional layer of defense-in-depth mitigation" (Cloudflare).
Check for compromise. The NCSC says that if you cannot update or disable a system immediately, you "should assess the system for any evidence of compromise prior to your upgrade or mitigation and look for backdoors installed by an attacker". CISA says to "Monitor for suspicious activity, including PHP worker processes launching shells or downloading tools", and has published a SIGMA detection rule "to help identify potentially suspicious activity in relevant log sources" (CISA, CISA SIGMA rules). CISA's KEV entries flag both CVEs for forensic triage under BOD 26-04, which CISA says "establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied" (CISA; BOD 26-04 implementation guidance). Amazon advises: "Start investigations from the earliest known exploitation, not from the disclosure date. For PHP2Shell, investigate from at least starting on October 17th." (Amazon). The researchers have published investigation hints; see Indicators of Compromise below.

Indicators of Compromise

PHP, CERT-EU and the NCSC have released no indicators of compromise, and the researchers' disclosure site lists none. Amazon has published IP addresses linked to the exploitation attempts against its honeypots (defanged here): 103.216.220[.]92, 31.223.184[.]166, 37.19.200[.]5, 134.209.159[.]64, 103.114.163[.]188 and 95.217.98[.]37. Amazon says these "include shared anonymization infrastructure and are not exclusive to this threat activity" and that organizations "should investigate any observations involving these addresses as opposed to blocking" (Amazon). watchTowr, Hadrian, Patchstack and Cloudflare report exploitation activity but have not published indicators of compromise in their posts; PHP's security team says it found no functional exploits at the time of release. SecurityWeek's 26 October report of shells on a researcher's honeypots does not list indicators of compromise (SecurityWeek). CISA added both CVEs to its KEV catalog on 26 October; neither CISA's KEV announcement nor its updated alert lists indicators of compromise (CISA). The Canadian Centre for Cyber Security's alert, last updated 23 October, still says "no active exploitation being identified at this time" (Canadian Centre for Cyber Security). Rescana has not independently confirmed any compromise.

Investigation hints (from the researchers, not indicators of compromise): The researchers who found the flaws say "A single detection rule is unlikely to cover every exploitation path". They list these investigation signals: "unexpectedly large or malformed PHPSESSID response cookies, unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, and unexplained PHP worker crashes or restarts" (php2shell.com). They caution that these signals "do not establish exploitation on their own" and that "Their absence does not establish that a system is unaffected", because some attacks can disclose memory without running malicious code and application logs "may contain little context". A clean result does not prove a system was not hit. Patch and restart regardless.

Why this matters for vendor risk

The fix is now out, but you are only protected once every vendor running PHP in its stack has deployed it, and many of those dependencies are invisible from the outside. CISA makes the same point: "PHP is often a component of other software and prevalence may not be directly observable." The memory-disclosure impact, confirmed by PHP and detailed by the researchers, sharpens the third-party risk: the researchers say an attacker can read passwords, authentication tokens, API keys and certificates from a vulnerable PHP server's memory without running any malicious code, which "can make the activity harder to detect with tools focused on malicious code execution". If a vendor's PHP application handles your data or holds credentials to your systems, those secrets could leak even if the vendor never sees signs of a break-in. With CISA now listing both flaws as known exploited, and Amazon reporting an exploitation attempt dated four days before disclosure, a vendor that patched promptly may still have been probed before it did. Ask your critical vendors now whether they run PHP, including bundled runtimes and appliances, whether they are on 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a patched vendor build, whether they have restarted their PHP services since upgrading, and when they will finish. Ask whether they have checked exposed PHP servers for signs of compromise from 17 October onward (Rescana guidance). For vendors that were exposed before patching, ask whether they plan to rotate the credentials and API keys their PHP applications hold, especially any that reach your systems (Rescana guidance). Then follow up until each one confirms.

What we will update: We will update this post if PHP revises its advisories or publishes its full advisory for CVE-2026-115560, if CISA or the Canadian Centre for Cyber Security updates its alert or CISA changes the KEV entries, if CISA's SSVC rating or NVD's scores change, or if a national CERT or vendor reports confirmed compromises.

Sources

PHP project and PHP Foundation: PHP security advisory, "Security advisory: Critical remote code execution vulnerabilities, update now" (21 Oct 2026) https://www.php.net/archive/2026.php#2026-10-21-5. PHP 8.2.35 release announcement https://www.php.net/archive/2026.php#2026-10-21-1. Release pages for 8.5.12, 8.4.27, 8.3.36 and 8.2.35 https://www.php.net/releases/8_5_12.php · https://www.php.net/releases/8_4_27.php · https://www.php.net/releases/8_3_36.php · https://www.php.net/releases/8_2_35.php. Advance notice, "Upcoming Critical PHP Security Release" (20 Oct 2026) https://www.php.net/archive/2026.php#2026-10-20-1. "Informational advisory: Session upload progress" (23 Oct 2026) https://www.php.net/archive/2026.php#2026-10-23-1. PHP 8 ChangeLog https://www.php.net/ChangeLog-8.php. Downloads https://www.php.net/downloads.php. GitHub security advisories (php/php-src): GHSA-w8hw-w9fx-j79w (CVE-2026-109618) https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w · GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp. PHP Foundation, "Today's PHP Security Release, and How We're Strengthening PHP Security" (21 Oct 2026) https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/.
CISA and NSA: CISA, "CISA Adds Two Known Exploited Vulnerabilities to Catalog" (26 Oct 2026) https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog. CISA Known Exploited Vulnerabilities Catalog https://www.cisa.gov/known-exploited-vulnerabilities-catalog (data feed, catalog version 2026.10.26: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json). CISA alert, "Critical Vulnerabilities in PHP Require Immediate Patching" (21 Oct 2026, last revised 26 Oct 2026) https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching. CISA, BOD 26-04 implementation guidance (Forensics Triage Requirements) https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk. CISA SIGMA rules repository https://github.com/cisagov/SIGMA_Rules. NSA press release, "NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities" (21 Oct 2026, since revised) https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4630238/nsa-advisory-critical-patches-recommended-for-php-vulnerabilities/.
CVE and NVD records: cve.org https://www.cve.org/CVERecord?id=CVE-2026-109618 · https://www.cve.org/CVERecord?id=CVE-2026-109619. NVD https://nvd.nist.gov/vuln/detail/CVE-2026-109618 · https://nvd.nist.gov/vuln/detail/CVE-2026-109619.
Other national CERTs and agencies: UK NCSC, "Critical security issue affecting PHP" https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php. CERT-EU Security Advisory 2026-018, "Critical Vulnerabilities in PHP" (v1.2, 23 Oct 2026) https://cert.europa.eu/publications/security-advisories/2026-018. NCSC-NL, php2shell operational information and list of software with a PHP dependency (GitHub, linked from CERT-EU 2026-018) https://github.com/NCSC-NL/php2shell. Canadian Centre for Cyber Security, Alert AL26-026, "Critical vulnerabilities impacting PHP - CVE-2026-109618 and CVE-2026-109619" (21 Oct 2026, updated 23 Oct 2026) https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619.
Researcher disclosure and vendor advisories for products that embed PHP: Official researcher disclosure (Wiz Research, OpenAI Codex Security, Calif), "PHP2Shell" https://www.php2shell.com. Palo Alto Networks, "Impact of Critical Vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619) on Palo Alto Networks Products" https://security.paloaltonetworks.com/CVE-2026-109618. Siemens ProductCERT SSA-566512 (23 Oct 2026) https://cert-portal.siemens.com/productcert/html/ssa-566512.html.
Security companies and media (secondary, attributed in the text): watchTowr, "PHP Remote Code Execution (“PHP2Shell” CVE-2026-109618 & CVE-2026-109619)" (21 Oct 2026) https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/ and FAQ https://watchtowr.com/intelligence/php-cve-2026-109618-faq/. Amazon (AWS Security Blog), "Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot" (21 Oct 2026) https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/. Hadrian, "php2shell: Leaked critical PHP RCEs (CVE-2026-109618, -109619)" (21 Oct 2026) https://hadrian.io/vulnerability-alerts/php2shell-leaked-critical-php-rce-cve-2026-109618-cve-2026-109619. Patchstack, "Major security alert: PHP vulnerable to critical RCE, attacks ongoing" (21 Oct 2026) https://patchstack.com/articles/php-major-vulnerability-alert-10-2026/. Cloudflare, "Cloudflare deploys protections against php2shell vulnerability" (21 Oct 2026) https://blog.cloudflare.com/php-vulnerabilities-waf-protection/. SecurityWeek, "PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors" (21 Oct 2026), cited only for its report that watchTowr had not observed successful attempts https://www.securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/. SecurityWeek, "PHP2Shell Exploitation Moves From Probes to Working Shells" (26 Oct 2026, updated 27 Oct), cited only for its report of a researcher's honeypot findings https://www.securityweek.com/php2shell-exploitation-moves-from-probes-to-working-shells/.

What to do with this vendor today

Both flaws are now in CISA's KEV catalog. For each critical vendor running PHP-based web apps, portals or appliances, forward this to your TPRM owner and ask today (Rescana guidance):

PHP in the stack. Do you run PHP anywhere that handles our data or connects to our systems, including bundled runtimes and appliances?
Fixed version deployed. Have you deployed PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a patched vendor build, and if not, when will you finish?
Restarted. Have you restarted your PHP services since upgrading, so the fixed version is the one actually running?
Compromise check. Have you checked exposed PHP servers for signs of compromise from 17 October onward?
Credential rotation. Because the researchers say one flaw can leak secrets such as passwords, authentication tokens and API keys without running code, will you rotate the credentials and API keys your PHP applications hold, especially any that reach our systems?

Record each vendor's answers with a follow-up date and follow up until each one confirms. A vendor that cannot confirm it has deployed a fixed version and restarted its PHP services should stay on your watch list.

Need help working out which of your vendors run PHP-based services and tracking their answers? Our team can help you prioritize them alongside the rest of their security posture.

Talk to an expert

Questions about this advisory? Contact us.