PHP2Shell Patches Are Available: What Website Owners Need to Verify After the Emergency Release

PHP has released security updates for two critical vulnerabilities that can permit unauthenticated remote code execution. Security agencies are urging rapid action, while website owners need to verify both their running software and the status of any hosting services or products that bundle PHP.

Website operators are responding to an emergency PHP security release addressing two vulnerabilities collectively discussed as PHP2Shell. The PHP project published fixes on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and encouraged users to update immediately. The central development is that fixes are available: this is no longer simply advance notice of a patch expected later. PHP’s official security announcement.

The implications extend beyond a developer choosing a programming language. PHP can be part of a website’s underlying runtime, a hosting package or a product installed for another purpose. Establishing exposure therefore requires an inventory of what actually runs, rather than checking only the name of the application visible to customers.

What the two vulnerabilities allow

The issues are tracked as CVE-2026-109618 and CVE-2026-109619. Both can permit remote code execution without authentication. In plain terms, a vulnerable server may be exposed before an attacker has obtained an ordinary account. That is why a strong application login cannot, by itself, be treated as a remedy for the runtime flaws. European security agencies’ joint statement.

The first official advisory concerns memory handling when a request runs out of memory. An interrupted operation can leave request data incompletely initialised, and cleanup can subsequently treat that invalid state as usable. The project identifies Apache’s mod_php as a particularly high-risk arrangement because the demonstrated path can occur before application-specific code starts. PHP advisory for CVE-2026-109618.

The second advisory concerns state retained by a worker after memory belonging to an earlier request has been released. A later operation can encounter that stale state before normal initialisation replaces it. It is a distinct defect, even though both advisories describe serious consequences and were addressed in the same coordinated release. PHP advisory for CVE-2026-109619.

Why a CMS update is not the same as a PHP update

A content-management system and the runtime executing it occupy different layers. Updating an application can address problems in that application while leaving the underlying PHP package unchanged. Conversely, replacing PHP does not automatically update every plugin, extension or other component of the application. The relevant evidence is the status of the layer named in the advisory.

This distinction is particularly useful for owners who manage a site through a dashboard but do not administer its server. A dashboard message that the website software is current may answer a different question from whether the hosting provider has deployed a PHP fix. The owner needs a clear response about the affected runtime and the provider’s action on the specific vulnerability identifiers.

The UK National Cyber Security Centre recommends identifying PHP systems across infrastructure, prioritising internet-facing assets and checking products that bundle the language. It also calls for ongoing attention to vendor updates. Those recommendations address the discovery problem: a system can contain an affected dependency even when its main product name does not mention PHP. NCSC guidance.

Use the correct fixed release or vendor package

For the upstream branches covered by the emergency release, the fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The supported branch matters when choosing a package. This is not an instruction that every installation must jump to the numerically newest major branch during an incident; compatibility and vendor packaging still have to be considered while applying the relevant security fix. Upstream fixed releases.

Distribution and long-term-support vendors may backport a security correction into a package whose public version string differs from the upstream release. CERT-EU explicitly advises checking vendor packages and identifies options for older branches. The reliable question is whether the vendor documents the correction for the CVEs in the installed package, rather than whether a superficial version comparison looks reassuring. CERT-EU advisory.

Amazon Linux’s advisory provides one example of that packaging layer, naming affected PHP packages and their corrected builds. It is evidence about Amazon Linux packages, not a declaration that every AWS customer application or third-party image has already been updated. Responsibility depends on what service or software the customer is running. Amazon Linux advisory.

Installing a package and running it are separate milestones

A useful completion check asks what is serving live requests after deployment. An update downloaded into a package cache is not necessarily installed. An installed binary may not yet have replaced a long-running worker. A rebuilt image may coexist with an older instance still handling part of the traffic. These are general deployment distinctions, not claims that a particular host has made any of those mistakes.

For an illustrative service with several application nodes, checking one node would leave uncertainty about the others. A deployment record should connect the corrected package or image to the instances actually receiving requests. It should also establish who verified that relationship and when. That is more informative than a single message saying that the upgrade command completed.

Routine functionality matters too. A service returning its homepage does not establish that checkout, uploads or scheduled tasks still work. Appropriate checks should cover the meaningful functions of the application without deliberately exercising an exploit against a live system. Verification should show both that the security change is present and that the service remains usable.

Temporary measures do not provide an equivalent fix

The PHP and CERT-EU advisories distinguish temporary reductions in exposure from a full correction. The project states that an update is the safe resolution; configuration changes target particular paths and do not make a vulnerable installation generally safe. Copying a fragment of a mitigation without its limitations can therefore create false confidence. CERT-EU on temporary mitigations.

Security agencies also discuss isolating exposed systems when prompt remediation is not feasible. That is an operational decision with availability consequences, rather than a universal instruction to disconnect every website regardless of its circumstances. The relevant team should connect exposure, the available fix and the time needed to deploy it to an explicit decision.

A web application firewall may supply another layer of protection, but it should not be silently substituted for the runtime update. Akamai’s advisory describes detection and protection rules alongside its discussion of the vulnerabilities. That is a vendor-specific control claim, not evidence that all attack paths on every PHP installation have been eliminated by a generic firewall setting. Akamai’s security advisory.

Patching does not prove there was no earlier compromise

The NCSC advises organisations unable to update or disable a system immediately to assess evidence of compromise and look for attacker persistence. That identifies a second workstream. Correcting the vulnerable code addresses future exposure through that defect; investigating what happened beforehand asks whether an attacker has already used access to make other changes. NCSC response priorities.

A vulnerability announcement is not proof that a specific website was breached. Equally, a successfully completed update is not proof that no breach occurred. Public reporting should preserve that distinction, particularly while proof-of-concept material and agency warnings circulate. Claims about exploitation need a named source and a clearly defined scope, rather than an assumption that every exposed installation had the same outcome.

For an organisation documenting its response, an exposure timeline can help separate those questions. When was the affected service present? When did the corrected build begin serving requests? What evidence was retained and reviewed? The answers make the state of knowledge clearer, even when an investigation cannot immediately resolve every uncertainty.

Support lifetimes still matter after the emergency

PHP’s published support policy provides two years of active support followed by two years of security support for a branch. It lists PHP 8.2’s security-support end date as December 31, 2026. Applying this emergency fix therefore does not remove the need to plan for the end of that branch’s upstream support. PHP support calendar.

An emergency correction and a planned branch migration answer different needs. The first reduces an immediate exposure. The second keeps the service on a maintainable path. Combining them may sometimes be practical, but the existence of a longer-term migration plan should not be confused with evidence that an urgent fix is already deployed.

A provider can make that status especially clear by distinguishing work that is scheduled, in progress, deployed and verified. Each label answers a different question. A maintenance appointment shows an intention to act; it does not establish that the service is corrected already. Where an organisation relies on several providers, those statuses can differ across systems.

This also improves communication with nontechnical owners. They do not need an exploit demonstration to understand the response. They need to know which service is covered, whether anything remains exposed and who is responsible for the next step. A precise completion statement is more useful than reassurance detached from an identifiable system.

What a useful provider confirmation should contain

For a managed website, a useful confirmation identifies the relevant CVEs, the corrected vendor package or runtime, the affected service and whether deployment and live verification are complete. Where several environments exist, production, staging and administrative services may need separate status. A broad assurance that infrastructure is routinely maintained does not provide the same evidence.

Our coverage of the Google Cloud London outage examined another distinction between an announced recovery and verified service behaviour. During a security response, the same discipline helps: describe the action actually completed and the uncertainty that remains.

As of October 22, the required upstream fixes have been published and multiple security agencies are urging action. The meaningful end state is a verified corrected service, supported by a clear account of exposure and any investigation needed—not merely a patch announcement passed along to someone else.