What changed

This is a runtime problem, not a CMS update

PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October to address two critical remote-code-execution flaws. CVE-2026-109618 concerns cleanup after an out-of-memory failure. CVE-2026-109619 concerns request state that can outlive the memory behind it. The project says web-serving installations using PHP-FPM, mod_php, php-cgi, FrankenPHP or LiteSpeed should update promptly.

That means checking the interpreter actually running behind each site. Updating WordPress, a plugin or an application image reference does not prove every web worker has picked up a corrected PHP build. Older PHP branches no longer receive ordinary upstream fixes; a distribution or long-term-support vendor may have a backport, but the operator needs to verify it covers both CVEs.

A partial workaround is not a fix

PHP lists settings that can narrow particular attack paths, but says none makes an unpatched installation safe. Treat them as temporary exposure reduction while the runtime is replaced.

The look-back

The patch date is not the start of the investigation

Amazon Threat Intelligence reports an exploitation attempt against its MadPot honeypot on 17 October, followed by additional attempts around the coordinated release. It says the post-release activity became broad across its sensors. Amazon also says it is unclear whether the earlier attempts would have succeeded on real systems. A honeypot observation is not a victim count, but it is enough reason to avoid setting the search window at disclosure day.

  1. 1

    Find every runtime. Include public sites, admin portals, staging hosts, containers, vendor-managed appliances and long-lived workers. Record the running PHP version and who controls the patch.

  2. 2

    Deploy and verify. Install a fixed release or a vendor-confirmed backport, restart workers, and confirm the live process uses the corrected build on every node.

  3. 3

    Review from at least 17 October. Preserve web, proxy and host logs. Check unusual POST uploads, unexpected child processes, modified web files, outbound connections and use of secrets the web worker could read. Amazon specifically points defenders to PHP_SESSION_UPLOAD_PROGRESS in form uploads as one lead, not a universal signature.

Defender note

Keep remediation and compromise assessment separate

A clean scan after patching answers whether the known entry point remains. It does not answer whether an attacker got in earlier or left another way back. Conversely, a suspicious request is a lead, not proof of successful code execution. Record which hosts and log periods were checked, where evidence is missing, and which credentials or files would have been reachable if a web worker was compromised.