PHP2Shell: Emergency PHP Patches Close Two Critical Remote Code Execution Flaws

What happened

On 21 October the PHP project published emergency updates for two critical flaws in the language runtime, together named PHP2Shell. They are tracked as CVE-2026-109618 and CVE-2026-109619, and each is rated 9.2 on the CVSS v4.0 scale. Either one lets an attacker with no account run code on a web server. The fixes ship in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Researchers at Wiz, Calif and OpenAI found and reported the flaws, which reach back to PHP 5.4. Because the weakness is in the engine, a site is exposed even if its own code is sound. Details leaked a day before the planned 22 October disclosure, and the release came out around its scheduled time.

The advisory names Apache's mod_php as the highest risk, with a demonstrated exploit in which one unauthenticated request triggers the attack before any application code runs. PHP-FPM behaves differently, and no complete FPM exploit has been shown for the first flaw. An attacker can also read memory from a worker process, which may hold passwords, tokens, API keys and certificates from other requests. The PHP team says configuration changes only narrow specific attack paths and that updating is the only complete fix. Cloudflare reported early exploit attempts and deployed firewall rules as a stopgap. watchTowr, which reproduced the first flaw, saw no exploitation in the wild at the time of its report, and neither flaw was in CISA's Known Exploited Vulnerabilities catalogue then. No source has confirmed a successful break-in. Even so, BambooHR took its service offline in several countries, and a number of Dutch government and education services went offline as a precaution.

Why it matters for organisations in Africa, the Gulf and beyond

The first lesson is about ownership. Application teams routinely update frameworks and content platforms, but the PHP runtime beneath them arrives through a server package, a hosting provider or a container image. Updating the application does not update the runtime. Organisations in Africa, the Gulf and beyond often run web estates spread across in-house servers, agencies and hosted platforms, so nobody may be clearly accountable for that layer. A flaw in the engine exposes that gap quickly, and it exposes it on every site at once, including simple ones with no custom code.

The second lesson is that uncertainty has an operational cost. The precautionary outages at BambooHR and in the Netherlands came without any confirmed compromise, and they still interrupted payroll and public services. For banks, government portals and other critical operators in DAAKYI's markets, the same trade-off applies. Availability usually outranks confidentiality in critical infrastructure, and many systems cannot be patched or restarted freely. Leaders need to decide before an incident whether to patch in place, isolate or take a service down, and who has the authority to choose.

The third lesson concerns data. Because an attacker can read worker memory, credentials and tokens belonging to other users may be at stake even without code execution. Where personal data is involved, regimes such as GDPR expect notification of the supervisory authority within 72 hours where feasible, and Ghana's Act 1038 provides for incident reporting. Regulatory references here are high-level and not legal advice. Organisations that cannot say which servers run which runtime will struggle to answer a regulator or a board with confidence.

What leaders should do now

Treat this as an emergency change with clear owners, and confirm each step has been completed rather than assumed.

• Inventory every system that serves web requests with PHP, including container images, hosted platforms and servers run by agencies or suppliers, and name an owner for each.
• Update the runtime itself, then restart Apache, PHP-FPM and any long-running workers. Check the package changelog for the CVE rather than relying on the version number, as distributions may backport fixes.
• Use the published configuration measures only as a short-term bridge. The PHP team states they do not make a server safe, so do not close the ticket on the strength of them.
• After patching, review memory_limit and post_max_size against application needs, since the fix adds a hard memory limit. Watch logs for unusual multipart requests followed by memory errors, repeated HTTP 500 responses, oversized session cookies and unexplained worker restarts.
• Plan for unsupported branches. PHP 8.1 and older no longer receive project updates, and PHP 8.2 reaches end of life on 31 December 2026, so set migration dates now.
• Agree in advance the triggers for a precautionary shutdown, credential rotation and regulatory notification, and who decides.

How DAAKYI can help

Responding to a runtime flaw is a vulnerability remediation problem as much as a patching one. DAAKYI's managed vulnerability remediation treats known exploitation as a reason to move a finding to the top of the queue. An emergency change applies the fix or mitigation, a rescan verifies it, and logs are reviewed for signs of earlier compromise. That sequence suits PHP2Shell, where the open questions are whether every runtime was found, whether the fix took effect and whether anything happened before it did.

Where logs suggest earlier activity, DAAKYI's digital forensics and incident response team can help establish what was reached and what must be rotated or reported. For web estates that depend on application and API controls, DAAKYI's secure engineering services can review how the runtime, the web server and the surrounding application are configured and maintained.

• managed vulnerability remediation
• digital forensics and incident response
• application and API security

Sources

• PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge (The Hacker News)