Two critical PHP vulnerabilities leaked on October 20 before fixes were available. The PHP security team moved its release forward to October 21 at 14:00 UTC and rated both flaws 9.2 under CVSS v4.0. Anyone running PHP behind a website or inside bundled vendor software has a near-term inventory and patching job. The affected versions and the route into the flaws are due with the release, so use the official release details to decide which installations need a fix.
Huntress researcher John Hammond identifies the leaked issues as CVE-2026-109618 and CVE-2026-109619. Huntress describes them as remote-code-execution vulnerabilities and says watchTowr reproduced the first issue. PHP’s advance notice says it may ship earlier “should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.” Huntress says it had seen no exploitation of these two vulnerabilities in its partner environments when it published its analysis.
Leak brings forward PHP fixes
The disclosure schedule changed within hours. Hammond describes a removed Hacker News post about the flaws, screenshots spreading afterward, and researchers confirming the leak. PHP’s advance notice then brought the planned release forward. Its 2026 release archive lists the October 20 notice, with affected and fixed versions to accompany the security release.
PHP runs WordPress, Drupal, Joomla and Magento sites, but a PHP binary may also arrive inside a hosting control panel, vendor appliance or Windows application. Huntress specifically calls out php.exe and php-cgi.exe in bundled software. A site inventory alone can miss these installations, while a scheduled update for the CMS says little about the PHP interpreter installed beneath it.
The published account calls the flaws remote code execution in PHP core. A successful code-execution flaw would let an attacker run code in the server’s PHP process context. Prioritize publicly reachable PHP sites for inventory, then compare their interpreter builds with the vendor release when it arrives.
Watch for unexpected worker children
Huntress recommends looking for PHP worker processes such as php-fpm, php-cgi, php-cgi.exe, httpd or apache2 launching unusual children. Shells including sh, bash, cmd.exe and powershell.exe, and tools including curl, wget and certutil.exe, merit investigation when they descend from a web worker. Review the parent process, command line, user, web request and nearby file writes together; an alert on a tool name alone will catch legitimate maintenance too.
Hammond recounts a separate Huntress incident from the prior week in which a PHP FastCGI process wrote a short-lived file into a writable temporary directory, ran it and deleted it. That incident illustrates why retaining process and file events can matter even when the file has vanished by the time an analyst looks. It is an example of other PHP abuse, not an observed attack using these two CVEs. An exposed Linux web server without process monitoring leaves that worker-child signal hard to see; keep the web-server and PHP logs available for follow-up if a suspicious event appears.
Prepare exposed installations to update
Locate PHP interpreters on internet-facing web servers first, then in control panels and vendor products that bundle them. Record the installed build, package source and application owner for each system. Check the PHP support table: branches 8.2, 8.3, 8.4 and 8.5 are supported as of this notice, while older end-of-life branches require migration planning. Move an end-of-life deployment off the public internet or behind restricted access while arranging that upgrade. A web application firewall is an interim layer rather than a known fix for an unpublished entry path.
When PHP publishes the fixed builds, compare each recorded installation against the release’s affected-version list and the Linux distributor’s or hosting provider’s backport advisory. Patch internet-facing systems first. Verify the running PHP version or distributor package on each host after deployment, including the interpreter bundled with a product, rather than relying on a scheduled change ticket. A version-based test for these exact flaws must wait for PHP’s release details.
For any suspicious PHP worker child process, isolate the host and preserve process telemetry, web and PHP logs before removing files; Huntress also recommends looking for webshells, new web-root files, cron jobs, scheduled tasks and accounts. Inventory gives you a patch queue today. The vendor’s fixed-version notice will turn that queue into a testable list of systems that still need work.