PHP2Shell, ten days later: African operators must now prove remediation

A warning becomes an operational incident

Ten days after PHP published emergency fixes on 21 October 2026, the urgency has changed. CVE-2026-109618 and CVE-2026-109619, commonly grouped under the PHP2Shell name, are no longer only critical vulnerabilities described by their discoverers. The Canadian Centre for Cyber Security reports that proof-of-concept code is available and that open sources indicate exploitation in the wild. On 26 October, the US CISA added both references to its Known Exploited Vulnerabilities catalogue.

Those signals do not prove that every observed attempt succeeds, or that a particular African organisation has been compromised. They do make a response based only on the absence of an antivirus alert or a hosting provider's generic assurance inadequate. Each exposed application must be classified by the runtime actually loaded, its execution mode, the vendor's patch and the quality of the available logs.

Both flaws affect the PHP engine while it processes web requests. One can leave internal structures inconsistent after an out-of-memory failure; the other can allow stale state to survive between requests handled by the same worker. Under the required conditions, the resulting corruption can lead to unauthenticated code execution. The visible CMS is therefore not the decisive boundary: WordPress, Drupal, Laravel and bespoke applications may all depend on the same vulnerable runtime.

Fixed versions and acceptable evidence

The fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older branches are no longer under normal upstream support, although Linux distributions, extended-support providers and hosting companies may have backported the fix. The Dutch NCSC operational register illustrates why a displayed version is insufficient: some suppliers identify corrected old-version builds, some declare products unaffected and others are still investigating.

Acceptable evidence must connect the public domain to the process receiving its requests. For PHP-FPM, operators need the active pool, the package or image providing its binary, the vendor revision and the last worker restart time. For Apache mod_php, evidence must cover the module loaded by the Apache process. For Docker, teams should retain the rebuilt image digest and demonstrate that the obsolete container no longer serves traffic. Running php -v in an administrator's shell can inspect a different binary and does not close the audit.

This distinction matters for shared hosting used by African SMEs, media organisations, universities, local authorities and civil society. Customers may not have operating-system access. They should request an advisory reference, build identifier, deployment date and confirmation that web workers were replaced. A hidden HTTP banner or an up-to-date CMS version does not provide that assurance.

A third CVE requires separate treatment

PHP also clarified CVE-2026-115560. This vulnerability requires an unusual combination of configuration and application behaviour: selected session serialisation handlers are changed at runtime before session_start(), while session upload progress remains enabled. The Canadian Cyber Centre states that the 21 October releases do not address this narrower case. Where the conditions exist, the temporary recommendation is to disable session.upload_progress.enabled until an appropriate fix is released.

Teams should neither ignore this third reference nor describe it as the same universal exposure as the first two. They must inspect the relevant configuration and code path. If those prerequisites are absent, that result should be documented. If they are present, the mitigation and the next PHP release need explicit tracking.

Hunt for compromise without overstating evidence

Remediation and investigation are separate workstreams. An update closes the flaw for future requests; it does not remove access established earlier. Teams should preserve reverse-proxy, web-server, PHP-FPM, endpoint and cloud-provider logs before retention policies rotate them. They can then review unexpected child processes launched by the web account, recently created executable files, unknown scheduled tasks, changes to accounts or keys, and unusual outbound connections.

None of those observations alone proves PHP2Shell exploitation. Conversely, a clean search through incomplete logs does not prove that no compromise occurred. When several indicators converge, operators should isolate the host, preserve evidence suitable for analysis, rotate accessible secrets and rebuild from a known baseline instead of merely deleting a suspicious file.

WAF rules published by several providers reduce exposure to recognised request patterns. They do not replace the PHP fix. Memory limits, temporary session-feature changes and removal of a public route are risk-reduction measures, not a security certificate.

What African leaders should require

For each exposed service, the remediation register should identify the domain, business owner, PHP SAPI, active version or build, patch source, worker restart date, validation evidence and indicator-review outcome. Products embedding PHP need separate treatment: a management portal, network appliance or integrator-delivered application may ship its own engine and remain absent from a conventional server inventory.

The defensible answer is no longer, “we ran updates.” It is, “this is the process that served the domain, this is the corrected build it now loads, this is when the old workers disappeared, and this is what our evidence review could and could not establish.” That discipline is achievable for African organisations even under resource constraints, and it provides stronger assurance than a surface scan or an undocumented statement.

— ◆ —