The two PHP2Shell flaws are now confirmed exploited in the wild and listed in CISA's Known Exploited Vulnerabilities catalog. The fixed PHP releases have been out since 21 October, so the remaining gap is unpatched sites rather than an unavailable fix.
What happened
PHP2Shell is two bugs in the PHP engine. CVE-2026-109618 leaves request memory in an uninitialised state when PHP aborts a request on an out-of-memory condition. CVE-2026-109619 lets global state keep pointing at request memory after it has been freed. Both allow an unauthenticated attacker to execute code as the web server account, and each scores 9.2 under CVSS v4.0.
On 24 October a researcher at Perplexity recorded an 800 KiB memory disclosure followed by an execution payload against Apache mod_php running PHP 8.4.26, which is the first working in-the-wild proof rather than a crash. Expel's Marcus Hutchins corroborated it. Before that, Amazon, Cloudflare and several other firms had seen only scanning and non-functional exploits since 17 October, and Sophos and Hunt.io have tied some of that traffic to a Mirai-derived botnet.
CISA added both records to the KEV catalog on 26 October and gave US federal civilian agencies until Thursday 29 October to patch.
Who is affected
- Any site or application running PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27, or 8.5 before 8.5.12.
- WordPress, Laravel, Magento, Joomla and custom PHP applications on hosting where the PHP version is your choice rather than the host's.
- Anything still on PHP 8.1 or older. Those branches get no upstream fix, so the exposure does not expire.
- Windows PHP builds, which also need the newer -1 rebuilds to pick up the separate Brotli fix.
What to do now
Upgrade PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, restart the PHP-FPM or Apache workers, then confirm the version the site is actually serving.
- Record the PHP version per site, not per server. A single host often runs several pools on different branches.
- Ask your hosting provider which PHP version your shared plans really serve, and get it in writing.
- Move anything on 8.1 or older to a supported branch. Waiting is not a strategy here.
- As a stopgap, set session.upload_progress.enabled=0, which PHP recommends as a mitigation.
- Hunt web logs back to 17 October for POST requests with oversized cookies or long, unusual query strings, and use CISA's published SIGMA rule if you have a SIEM.
What this means for South African businesses
Most South African SME web estates are PHP, and the majority of those sites sit on shared hosting where nobody on the customer side tracks the runtime version. A marketing site, a client portal or a booking form built three years ago and never touched again is exactly the profile that is still on an unpatched branch today. My read is that the real risk here is not the firewall or the ERP, which usually have an owner and a patch window, but the forgotten website with neither. If your host cannot state the PHP version in writing, treat that site as unpatched.
Source: BleepingComputer - CISA confirms PHP2Shell vulnerabilities now exploited in attacks.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.