Is your PHP site exposed to PHP2Shell, and what should you do this week?

At a glanceThe short answer

If you run PHP below 8.5.12, 8.4.27, 8.3.36 or 8.2.35, treat two critical flaws as urgent: update, restart workers and check logs. CISA lists both as exploited. A web firewall is only an interim control.

01CVE-2026-109618 and CVE-2026-109619 allow unauthenticated remote code execution; CISA added both to its exploited-vulnerabilities catalogue on 26 October 2026.
02Magento, Adobe Commerce and WordPress sites run on PHP, so ask your host which version and interface each site uses.
03PHP 8.1 and earlier are not among the fixed releases: CISA says to take such systems offline until patched or upgraded.
04Patching does not show whether the flaws were used earlier, so review logs as well.

Are you affected?

Probably, if any website or application you run uses PHP below 8.5.12, 8.4.27, 8.3.36 or 8.2.35. That includes many Magento, Adobe Commerce and WordPress sites, because they run on PHP. This is Noesis analysis of the advisories, not a statement by those vendors. CISA's alert, updated on 26 October 2026, covers every PHP installation serving web requests, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. CISA calls out PHP 8.1 and earlier as unsupported, and they are not among the fixed releases. Your hosting provider may patch for you, so ask rather than assume. See sources 1–3.

What is confirmed, and when.

The PHP project published two critical advisories on GitHub on 21 October 2026. php.net's changelog lists releases 8.5.12 and 8.4.27 on 22 October; we did not read its 8.3.36 and 8.2.35 entries. CISA updated its alert on 23 October and added both CVEs to its Known Exploited Vulnerabilities (KEV) catalogue on 26 October. Addition to the catalogue is CISA's signal that exploitation has been observed. The entries give a due date of 29 October and record use in ransomware campaigns as 'Unknown'. Neither the advisories nor CISA says who is exploiting the flaws or how widely. We checked these sources on 30 October 2026. See sources 1–5.

Fig. 1From the sources

From advisory to exploited-vulnerability listing in five days

21 Oct 2026Advisories publishedTwo critical php-src advisories name the fixed releases
22 Oct 2026Releases in php.net changelog8.5.12 and 8.4.27 are dated this day
23 Oct 2026CISA alert updatedDetection rule and mitigation guidance added
26 Oct 2026Added to CISA KEVBoth CVEs listed in the catalogue
29 Oct 2026Catalogue due dateAs recorded in the catalogue entries

Dates from the PHP advisories, php.net, CISA’s alert and its catalogue. Noesis checked them on 30 October 2026; we did not read the 8.3.36 and 8.2.35 changelog entries. Sources 1, 3, 4, 5.

What the advisories describe.

Each advisory carries a CVSS v4 score of 9.2 and lists the same affected and fixed versions. CVE-2026-109618, titled 'RCE via OOM corruption', concerns how PHP handles a failed memory allocation. CVE-2026-109619, titled 'RCE via stale global state', concerns state kept from an earlier request. The first advisory reports validated unauthenticated remote code execution over HTTP against mod_php with default settings. It judges PHP-FPM likely susceptible but unproven, and FrankenPHP and LSAPI likely susceptible. The second describes a confirmed route through session upload progress and PHP 8.5's fatal error backtraces on mod_php, and says exploitation needs the producing and consuming requests to reach the same worker. We do not repeat technical detail beyond the advisories. See sources 1–2.

Fig. 2From the sources

Two critical flaws, one fix

Aspect	CVE-2026-109618	CVE-2026-109619
Advisory title	RCE via OOM corruption	RCE via stale global state
Severity	Critical, CVSS v4 9.2	Critical, CVSS v4 9.2
Fixed in	8.5.12, 8.4.27, 8.3.36, 8.2.35	Same fixed releases
Confirmed route	Unauthenticated RCE over HTTP on mod_php, default settings	Session upload progress and PHP 8.5 fatal error backtraces on mod_php

Summarised from the two GitHub advisories. Both name the same affected and fixed versions; upgrading is the only complete fix. Sources 1, 2.

What to do this week.

Noesis recommendation, following CISA's steps. First inventory every system that runs PHP, including PHP embedded in other software, and put internet-facing systems first. Then update to a fixed release and restart workers so the new version is the one running. Confirm the running version afterwards, not just the package installed. If a system cannot be updated, or runs PHP 8.1 or earlier, CISA says to take it offline until it is patched or upgraded. Finally review logs for PHP worker processes launching shells or downloading tools, and use CISA's published SIGMA detection rule. Clean logs do not prove safety. See sources 1–3.

Fig. 3Noesis analysis

The week’s steps, in order

01Inventory PHPEvery system, including PHP embedded in other software
02Update to a fixed releaseInternet-facing systems first
03Restart and confirm versionThe running version, not just the installed package
04Offline if it cannot be updatedAlso for PHP 8.1 and earlier, per CISA
05Review logsWorker processes launching shells or downloading tools

Noesis recommendation, following the actions in CISA’s alert. Start with internet-facing systems. Source 3.

Interim controls and their limits.

A web application firewall may give some protection until systems are patched, according to CISA. The advisories say upgrading is the only complete fix. For 8.5 installations that cannot yet update, setting fatal_error_backtraces=0 and restarting all workers removes the confirmed producer for the second flaw but not other paths. Setting session.upload_progress.enabled=0 and restarting workers blocks the demonstrated session path; the advisory suggests it even after patching if the feature is unused. The first advisory also lists setting memory_limit=-1, keeping request size limits conservative and not using RLIMIT_AS or RLIMIT_DATA, none of which is a complete mitigation. See sources 1–3.

Fig. 4From the sources

If you cannot update yet

TestPass when
01Web application firewall in front of PHPPass when: May give some protection until patched (CISA)
02PHP 8.5, cannot update yetPass when: fatal_error_backtraces=0, workers restarted; removes the confirmed producer only
03Session upload progress not neededPass when: session.upload_progress.enabled=0, workers restarted
04PHP 8.1 or earlier, or cannot updatePass when: Offline until patched or upgraded (CISA)

Interim controls named by CISA and the advisories. None is a complete mitigation; upgrading is the only complete fix. Sources 1, 2, 3.

What not to conclude.

Do not conclude that your site has been compromised because it ran an older PHP, or that it is safe because a patch has been applied since. Patching closes the flaw going forward and does not show whether anyone used it earlier. Do not rely on press reports of scale; the sources we read do not state how many systems are affected. We did not verify a separate configuration-dependent issue, CVE-2026-115560, reported on 23 October, so this note does not cover it. This is not legal advice, and we have not tested any system against these flaws.

Make the first check concrete.

Noesis analysis: ask your hosting provider and your developers three questions today. Which PHP version and server interface runs each production site? When was it last restarted after updating? Who reviews the logs? If the answers are unclear, an inventory of the web estate is the useful first piece of work, ahead of any redesign.

Sources & context

Sources checked 2026-10-30. Recommendations and illustrative scenarios are Noesis’s analysis, not claims of client results.