On 21 October 2026 CISA urged immediate patching of CVE-2026-109618 and CVE-2026-109619, the “php2shell” flaws that allow unauthenticated remote code execution in PHP. Amazon says the first exploitation attempts came on Saturday 17 October, four days before the patches. So PHP RCE patching is two jobs: upgrade every server, then check whether anything got in first.

The flaws sit in PHP itself, not in the applications you host on it. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and both CVEs score CVSSv4 9.2. The injected code runs with the privileges of the web worker.

CERT-EU lists every web-serving setup as exposed: PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest-risk one. CVE-2026-109618 is memory corruption during out-of-memory handling; CVE-2026-109619 is a use-after-free involving state kept between requests.

The timeline matters more than the version list. The PHP team brought the release forward after details leaked, patched on 21 October and had told admins to prepare only a day earlier. Amazon’s honeypots logged attempts from 17 October and more between 02:00 and 08:00 UTC on 21 October; BSI’s vice president expected large-scale exploitation within hours of the updates.

One caution on the evidence: Amazon describes attempts, not confirmed compromises, and the PHP team said none of the proofs of concept published before the patch worked. CISA itself said at publication that it had not observed exploitation, and watchTowr noted that as of 22 October neither CVE was in CISA’s KEV catalog, so check the catalog’s current state yourself. Treat the compromise check below as a precaution, not an assumption of breach.

Who owns the patch on each of our products

The answer depends on what you bought, and a mixed fleet usually has all of it. Here is how we draw the line:

  • VPS, VDS and MEM (unmanaged): we operate the KVM hosts and the network; the PHP runtime inside the instance is yours to upgrade.
  • Bare Metal, unmanaged: a single-tenant server is yours end to end, including the web stack on it.
  • Bare Metal with the managed option: we take care of the operating system. Whether PHP as your application runtime is covered is something to confirm with us in writing, not to infer.
  • MNG instances: they are managed, but which software on your instance the management covers is not something to assume for PHP. Ask us before you count an MNG instance as handled.

The expensive mistake in a PHP vulnerability response is an instance everyone believes someone else is patching. Settle ownership per server before you start upgrading.

Build a PHP server inventory before you patch

CISA tells you to inventory every system running PHP, because it is often embedded and its presence is not obvious. A PHP server inventory for this event needs only a few fields per host:

  • PHP version and SAPI (php -v and how the web server calls PHP)
  • Whether the host faces the internet; those go first, as CISA advises
  • Who patches it: you, us, or an application vendor
  • Whether PHP is bundled inside a product you did not install as PHP

For that last case, CERT-EU points to the NCSC-NL list NCSC-NL/php2shell, which tracks software that embeds PHP. A vendor appliance can carry a vulnerable runtime that no package manager on your side will ever show.

Versions with no upstream fix

PHP 8.1 and older get no routine upstream updates, though the PHP team supplied limited source backports for 7.4, 8.0 and 8.1. CERT-EU says some distributions and LTS vendors backport fixes. watchTowr says PHP 7.3 and older, including PHP 5, have no fix at all, and BSI says every known version back to at least PHP 5 is vulnerable.

If a host runs one of those, you have three options: move to a fixed branch, take a vendor backport, or isolate the host. ExecutiveGov reports that NSA and CISA say systems that cannot be updated should be taken offline; CERT-EU’s wording is softer, to consider isolating them. Also check your repositories: the volunteer repo rpms.remirepo.net will not have same-day updates.

Temporary php2shell mitigation while you wait

CERT-EU is explicit that the temporary settings reduce exposure and “do not make an installation safe”. For CVE-2026-109618 it suggests a non-overridable memory_limit=-1, a low post_max_size and cgroup memory limits, and it warns against RLIMIT_AS and RLIMIT_DATA. For CVE-2026-109619 you disable upload progress tracking:

session.upload_progress.enabled=0
; PHP 8.5 only
fatal_error_backtraces=0

Set the first line in php.ini, the FPM pool or the server config, then restart all workers, as CERT-EU says. AWS WAF’s PHP managed rule group v2.3 adds a PHP2Shell_BODY rule for CVE-2026-109619 if you already filter traffic that way. It is a stopgap in front of an unpatched server, not a substitute.

A 30-day patch SLA assumes the attacker waits for you. For this one, Amazon logged exploitation attempts four days before the patch.

Check for compromise as well as upgrade

Patching closes the door; it does not tell you who was already inside. AWS advises investigating from at least 17 October. A community checklist cites an earlier lookback to June 2026, but the reason for that date is unexplained, so decide your window by how much log history you can afford to read.

AWS’s hunting hint is to search web logs for POST requests containing PHP_SESSION_UPLOAD_PROGRESS in form uploads. Beyond that, look for files in the webroot that your deploys did not create, child processes spawned by the web worker, and outbound connections from the web user. Because the code runs as that worker, map what its account can read: configuration files, database credentials, mounted storage.

On our Cloud instances, take a snapshot before you change anything, so you keep the pre-patch disk to examine. Then rotate credentials the web worker could read on any host where the hunt finds something, or where logs from 17 October onward are missing.

The order of work

  1. Inventory PHP, including embedded copies, and mark who patches each host.
  2. Upgrade internet-facing hosts first, to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor backport.
  3. Apply the temporary settings where an upgrade has to wait, and restart all workers.
  4. Isolate hosts on branches with no fix.
  5. Hunt in logs from 17 October, and widen the window if you can.

AWS’s advice is to measure critical patch timelines in hours, because 7- or 30-day SLAs assume a delay that no longer exists. Know today which of your servers you own and which you have asked us to own, so those hours go to patching rather than to finding out.

Sources