Summary

• The PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October to address CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0.
• The vulnerabilities involve out-of-memory corruption and stale internal state, with demonstrated unauthenticated remote code execution under particular conditions.
• Updating PHP is the only complete remedy. WordPress users need the underlying PHP runtime patched, not a separate WordPress core update; unsupported installations require vendor support or migration.

Two critical vulnerabilities in PHP have prompted urgent security updates across the software used to operate websites, business applications and online services, after researchers demonstrated conditions in which unauthenticated attackers could execute code on affected servers.

The PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October, addressing two weaknesses assigned CVE-2026-109618 and CVE-2026-109619. Both have received a severity rating of 9.2 under the Common Vulnerability Scoring System version 4.0.

The PHP project advises immediate updates for installations serving web requests, including those using PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Its assessment identifies particular risk in mod_php configurations, where an unauthenticated request has been demonstrated triggering exploitation before ordinary application code begins running.

The UK’s National Cyber Security Centre has also warned organisations to prioritise remediation, especially where PHP services are accessible from the internet. Although temporary measures can reduce exposure to particular attack paths, PHP’s maintainers say none provides complete protection without installing the security fixes.

Two flaws affect the PHP runtime

PHP is a programming language commonly used to operate websites and server applications. It processes requests, generates web content and connects applications to databases and other services.

Because the language runtime underpins many different products, a vulnerability in PHP itself can affect applications whose own code has not introduced the underlying defect.

The first issue, CVE-2026-109618, concerns the way PHP handles an out-of-memory condition during request processing.

If a request reaches the configured memory limit at a particular moment, internal information may be left partly initialised. Subsequent cleanup can then treat that information as valid, causing memory corruption.

Researchers demonstrated circumstances in which an attacker could exploit the weakness to execute code remotely without needing an authorised account.

The second issue, CVE-2026-109619, involves internal state remaining accessible after the memory supporting it has been released.

A later request handled by the same worker can encounter that stale state before normal initialisation has reset it, creating another route to memory corruption and potential code execution.

These problems arise within fundamental PHP processing rather than a single optional website plugin. Their impact can therefore extend across different applications and deployment arrangements.

Whether an individual server is exploitable depends on its configuration and the conditions required to trigger the vulnerability. Nevertheless, maintainers have identified sufficiently serious attack paths to advise immediate action across affected installations.

Four supported versions provide the fixes

The newly released versions contain the coordinated security changes for the supported PHP branches.

Organisations running PHP 8.5 should update to 8.5.12, while those using PHP 8.4 require 8.4.27. The corresponding fixed releases are 8.3.36 and 8.2.35 for the other supported branches.

Administrators must confirm which runtime their production applications actually use before determining whether the update has been completed.

Some organisations operate PHP directly on their servers, while others rely on hosting companies, Linux distribution packages, containers or commercial applications that incorporate the runtime.

Those arrangements affect how patches are supplied. A managed hosting provider may update PHP centrally, whereas an organisation maintaining its own infrastructure may need to obtain vendor packages, test compatibility and coordinate installation.

Linux distributions and long-term support vendors received the fixes in advance, allowing them to prepare packages for their supported systems.

Consequently, a distribution’s corrected package may have a different version string from the upstream PHP release while still incorporating the relevant security fixes. Administrators should verify the vendor’s security advisory rather than relying exclusively on a numerical comparison.

Versions older than PHP 8.2 no longer receive security releases through the project’s normal supported branches.

However, the PHP project has also provided minimal source backports for PHP 7.4, 8.0 and 8.1 to help organisations without access to suitable long-term support packages.

Those backports do not restore ordinary upstream support for the older branches or make them equivalent to currently maintained releases.

Organisations retaining legacy installations must therefore assess the immediate availability of a suitable vendor fix and establish a longer-term migration plan.

PHP 8.2 itself is approaching the end of its supported life on 31 December 2026, meaning administrators using that branch should also prepare for a supported upgrade rather than treating the October patch as a permanent maintenance solution.

Temporary controls cannot replace updating

The PHP security advisory identifies configuration measures that can reduce exposure to particular exploitation paths while an update is being prepared.

Some measures address memory limits and request processing, while others restrict features associated with the persistence of internal state between requests.

However, the project explicitly warns that these controls do not eliminate every relevant attack path.

Applying a temporary configuration change without installing the patch may therefore leave an installation vulnerable, even where a known demonstration no longer operates successfully.

Such changes can also affect application behaviour, particularly when resource limits or request handling procedures are altered.

Organisations should assess them against their specific environment and vendor guidance rather than treating a generic workaround as a verified substitute for remediation.

The NCSC has advised that exposed systems may need to be taken offline when timely remediation is not feasible.

That decision must take account of service availability and the risks of continued operation, but maintaining a vulnerable internet-facing application can expose the wider organisation to consequences beyond the individual website.

Successful code execution may provide an attacker with opportunities to access application credentials, examine data or interact with connected infrastructure, depending on the permissions and controls present on the affected server.

Separating services and limiting privileges can reduce some potential consequences, but neither measure corrects the underlying PHP vulnerabilities.

WordPress users must patch PHP itself

WordPress has issued its own security notice because PHP supports the content management system and many of the websites built on it.

The WordPress project makes clear that the weaknesses are not specific to WordPress and do not require a WordPress core security update.

Instead, website owners must ensure that the PHP runtime supplied by their hosting environment has received an appropriate fix.

Administrators can check their installed PHP version through the Site Health information available in WordPress or through their hosting provider’s management interface.

However, a version display alone may not establish whether a vendor has incorporated a backported security fix, making supplier confirmation important in some environments.

Organisations using managed hosting should establish whether updates have been completed across all relevant sites, including staging environments and applications that may operate on different servers.

Those running their own infrastructure must also consider packages installed separately from the main operating system, including container images and software distributed by commercial suppliers.

Updating an application plugin or installing the latest WordPress release without addressing PHP would not remove these runtime vulnerabilities.

Disclosure exposes a longstanding maintenance problem

The PHP Foundation has acknowledged that work related to one underlying memory management problem began in 2024, before researchers demonstrated its more serious exploitation potential.

Early attempts to resolve the issue encountered difficult trade-offs involving compatibility and the potential introduction of additional problems.

The Foundation says the issue did not progress quickly enough, in part because complex security work depended on a limited number of maintainers.

Further research in 2026 established additional exploitation paths, leading to a coordinated effort involving external security researchers, vendors and PHP developers.

The coordinated disclosure became more difficult after the vulnerability identifiers circulated online shortly before the planned release.

The Foundation says proof-of-concept material subsequently appeared, although its security team had not identified a functional publicly circulating exploit at the point of coordinated release.

That statement concerns observations at a particular time. It does not establish that exploitation is impossible or that the vulnerabilities will remain unused by attackers.

The Foundation has since expanded its security resources and revised aspects of its reporting and response processes, recognising that the number of vulnerability reports is increasing as automated research tools improve.

For businesses, the episode exposes dependence on software maintained by relatively small teams even where the technology supports commercially important services.

Organisations need reliable processes for identifying vulnerable components, establishing which supplier is responsible for updates and deploying fixes when a foundational dependency develops a critical security problem.

The immediate priority is to install the appropriate PHP update and verify that every affected production runtime has been addressed. The longer-term requirement is to reduce reliance on unsupported branches and maintain enough visibility of software dependencies to respond when new vulnerabilities are disclosed.