Security Advisory Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619

nicolaasjan

Level 6
Verified
Well-known
PHP fixes two critical vulnerabilities on October 21 at 14:00 UTC. They affect all web servers running PHP 5.4 or later. You need to fix them at the infrastructure level. Sansec expects mass attacks within 15 minutes of the release.

PHP releases the fix on Wednesday October 21 at 14:00 UTC, or earlier if technical details become public or attacks start. Ask your hosting provider today to stand by.
PHP will release a fix for two critical vulnerabilities on Wednesday October 21 at 14:00 UTC (16:00 CEST, 10:00 EDT). The PHP security team rated both CVSS v4.0 9.2. A screenshot of an exploit tool named PHP2Shell, credited to Calif.IO, leaked alongside the advisory. Its banner claims the tool works against every PHP release from 5.4.0 on. The bugs affect all web servers running PHP 5.4 or later, which includes Magento, Shopware and WooCommerce stores.
We expect mass attacks to start within 15 minutes of the release.
 
Last edited by a moderator:
Hi Nicolaasjan, this warrants preparation before the patch lands, but one distinction matters: the official PHP notice confirms two critical CVSS 9.2 vulnerabilities and the 14:00 UTC release time, but it has not yet confirmed the CVE identifiers, RCE mechanism, affected versions or fixed versions. The “PHP 5.4 onward” scope comes from leaked material and the PHP2Shell banner, so it should presently be treated as potential scope, not settled vendor information.

Likewise, Sansec’s “attacks within 15 minutes” is a risk forecast, not an observed incident. As of the latest advisories, active exploitation had not been reported. That distinction should not encourage anyone to dawdle—the patch-to-exploitation window for a PHP-wide flaw could be brutally short.

Administrators should now:

  • Inventory every Internet-facing PHP runtime, including PHP-FPM pools, Apache modules, containers and forgotten staging sites.
  • Prepare to install the OS/vendor package released for the vulnerability, then restart or recycle PHP workers and replace affected container images.
  • Verify the version used by the web SAPI, not merely php -v; CLI and FPM can load different binaries and configuration.
  • Remember that upstream currently supports only PHP 8.2–8.5. Older distribution packages may receive vendor backports, so check the distribution advisory rather than relying solely on the displayed PHP version.
  • Preserve web, application and process logs. Patching prevents further exploitation; it does not remove a webshell if exploitation already occurred.

Before patching, Sansec suggests these as temporary, unconfirmed mitigations:

Code:
session.upload_progress.enabled = 0
session.use_strict_mode = 1

They must be applied to the configuration actually used by each web-facing PHP pool and the workers reloaded. Test first if an application relies on native PHP upload-progress handling. These settings are not a substitute for the update.

If immediate patching is impossible, CERT-EU recommends considering temporary isolation of Internet-facing PHP applications. A CMS or shop plugin update alone will not repair a vulnerability in the PHP runtime.

Sources
 

Recently browsing

Members who viewed this thread in the last 5 minutes

Back
Top