PHP fixes two critical RCEs: Africa must verify servers, not only websites

The warning has become an urgent patch

On 21 October 2026, the PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both can lead to unauthenticated remote code execution. The official advisory says that PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where an unauthenticated request has been demonstrated to trigger exploitation before application code runs.

The first flaw involves out-of-memory handling. PHP can abandon a request while internal request data is only partly initialised; shutdown processing may then treat that invalid state as legitimate. The second involves stale global state: references owned by one request may remain after their backing memory has been freed and be consumed by a later request handled by the same worker. These are engine-level defects, not vulnerabilities limited to WordPress, Drupal or one business application.

The reviewed official sources do not establish a mass exploitation campaign against African organisations. That absence of confirmation does not lower the patch priority. The vulnerable behaviour occurs before or around normal application initialisation, where a CMS update or business-level validation cannot provide a complete remedy.

The fixed versions are now known

Maintained branches must reach at least PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12. PHP 8.1 and older branches no longer receive regular upstream security releases. Given the severity, the PHP team provided minimal source backports for operators compiling PHP 7.4, 8.0 or 8.1 themselves. Those patches do not restore supported status to those branches.

Linux distributions and long-term-support vendors may backport the fix without adopting the same upstream version string. Operators should therefore check the advisory and package revision from the vendor that actually supplies the runtime. Running php -v in a shell is not always sufficient evidence: the command-line binary may differ from the PHP-FPM pool, Apache module or container receiving public requests.

On 23 October, PHP issued a separate clarification concerning CVE-2026-115560. It requires an unusual combination in which specific session serialisation handlers are configured and then changed at runtime before session_start(), while session upload progress remains enabled. PHP recommends temporarily disabling session.upload_progress.enabled for this case until the next regular bug-fix release. This narrow condition should not be confused with the two critical 21 October RCEs, for which immediate updating remains the complete response.

Why African exposure is difficult to measure

Government agencies, universities, media companies, small businesses, healthcare providers and online shops often use PHP without operating it directly. The runtime may belong to a shared host, systems integrator, old Docker image or cPanel account. The team updating the application is therefore not necessarily the team responsible for patching its execution engine.

This fragmentation creates both false positives and false confidence. An X-Powered-By header proves neither the exact version nor exploitability. Hiding that header, conversely, fixes nothing. Useful evidence connects four things: the public service, the process handling its request, the package or image providing PHP, and the corrected version actually loaded after workers restart.

Supplier dependence makes governance central. A statement that “the server is secure” is not enough. Customers need the branch in use, the vendor's patch reference, deployment time and a way to validate the result. Contracts for important services should define deadlines for critical fixes and continuity arrangements where a runtime update introduces compatibility problems.

An evidence-producing audit method

Start with a read-only inventory of system packages, PHP-FPM services, Apache modules, CGI binaries, containers, base images, scheduled jobs and demonstration environments. Associate each runtime with its domains, ports, owner and data classification. Installed but inactive versions must be separated from those actually exposed.

Before remediation, preserve databases, uploaded files, volumes and configuration, then verify backups with cryptographic hashes. Retain web and PHP logs to investigate unusual requests, recently created files, unexpected processes or abnormal outbound connections. An absence of indicators in incomplete logs does not prove that compromise did not occur.

If patching cannot happen immediately, the PHP advisory lists exposure-reduction measures, including strict request limits and disabling session upload progress. It also makes clear that mitigations are incomplete. For a demonstration or non-essential application, removing its public route or stopping the vulnerable runtime is often more defensible than stacking untested WAF rules.

Remediation means rebuilding and verifying

Inside a container, editing the running binary is not a durable fix. Rebuild from a corrected base image, pin the version, deploy a replacement and remove the obsolete image after validation. On a conventional server, install the vendor package, restart the relevant workers and confirm the version from the context that actually handles traffic.

Validation should cover authentication, forms, uploads, payment, document generation, job queues and scheduled tasks. It should also confirm that PHP-FPM and databases are not directly published, that the application runs with minimum privileges and that secrets cannot be downloaded from the web root.

Recording only a version number is insufficient. Organisations should retain the remediation date, affected asset, evidence, accountable owner and residual risk. That record turns a global alert into a measurable local control.

The decision-makers' lesson

The two PHP flaws expose less a weakness of one language than a failure of inventory and accountability. An organisation can own a modern application while running it on a forgotten vulnerable layer. It may also pay for managed hosting without evidence of how quickly that layer is patched.

The priority is straightforward: identify every runtime serving the web, assign ownership, apply the real supplier's update and verify the process actually loaded. PHP 8.2 is approaching upstream end of life, so its urgent patch should come with a migration plan. Older branches without demonstrable vendor maintenance can only be isolated temporarily. The resilience of Africa's web services depends as much on this operational discipline as on the availability of patches.

— ◆ —