PHP administrators have an urgent patching job after the project released fixes for two critical vulnerabilities that can allow a remote attacker to execute code without logging in. The 21 October releases cover PHP 8.2, 8.3, 8.4 and 8.5, and the warning extends across the major ways PHP is used to serve websites.

The fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP’s official announcement says installations should update immediately. For Zimbabwean agencies, online shops and organisations using PHP hosting, the practical priority is to confirm that their hosting provider has applied the relevant fixes.

Two failures inside the runtime

The first issue, CVE-2026-109618, concerns how PHP recovers when memory allocation fails. Internal request data can be left partly initialised, then treated as valid during cleanup. The advisory describes a demonstrated attack against Apache’s mod_php integration that reaches the vulnerable processing before application code runs.

PHP-FPM handles failed request startup differently by terminating the affected worker. However, the advisory says vulnerable situations can still arise after normal startup. Its authors consider FPM susceptible, while distinguishing that assessment from a complete demonstrated FPM exploit.

The second flaw, CVE-2026-109619, involves internal state that outlives the request memory it refers to. When a persistent worker handles a later request, it can encounter that stale state before normal initialisation replaces it. Exploitability depends on the combination of operations and configuration involved.

That advisory also warns that hiding errors does not remove the underlying problem. Settings that suppress displayed warnings cannot be treated as protection against unsafe internal state.

A further session warning on 23 October

Today PHP added advice to disable session upload progress temporarily with session.upload_progress.enabled=0 pending the next regular bugfix release. The follow-up concerns a specific combination: an application configured for one session serialisation handler switches to php at runtime before starting a session, while upload progress remains enabled.

PHP identifies the follow-up as CVE-2026-115560 and says applications that never change the handler at runtime can retain the feature. Administrators who already disabled it following the earlier advisory should keep that mitigation in place. This detail is worth checking alongside the critical updates rather than assuming every session configuration has the same exposure.

What website owners should ask their hosts

Ask which patched PHP build serves the website, whether the relevant service has been restarted or reloaded, and whether the application uses the session configuration described in the follow-up. Hosting panels can expose several PHP versions, so a command-line version alone is not sufficient evidence that a public website uses the same executable.

Likewise, updating a content management system or a framework dependency does not replace an update to PHP itself. Application maintenance and runtime patching are separate responsibilities, even when one company handles both.

Organisations should request confirmation for each production site, then check logins, uploads, background work and other important operations after the update. On a managed platform, the provider should be able to identify the package carrying the fixes, including any vendor backport.

The immediate task is concrete: establish which runtime handles public requests and confirm the critical patches have reached it. The session follow-up adds a targeted configuration check to that work.