PHP2Shell: what website owners should do now

Updated: 23 October 2026. PHP2Shell is the name being used for two critical PHP vulnerabilities. For website owners, the immediate task is to establish whether the hosting environment has received the relevant fixes. A working website, a padlock in the browser or an updated CMS does not answer that question.

What has happened?

The issues are CVE-2026-109618 and CVE-2026-109619. They concern memory handling inside PHP and can, under relevant conditions, enable unauthenticated remote code execution: an attacker may run code with the web worker’s privileges. The official technical reports explain the out-of-memory flaw and the stale-state flaw.

PHP installations serving web requests need assessment; the risk is not confined to one CMS. ENISA’s joint statement urges organisations to identify PHP-based applications and coordinate with their hosting providers. A vulnerability warning is not proof that every affected website has already been compromised.

Which PHP security releases address the two flaws?

The security releases issued on 21 October 2026 are listed below. Use the appropriate maintained branch or a later approved release, and check the provider’s advisory if its packages contain backported fixes. A version number alone may not tell the full story. See the PHP security advisory.

Important update of 23 October

PHP has since published an additional notice concerning session.upload_progress.enabled and an unusual session configuration, with CVE-2026-115560 to be covered in a forthcoming advisory. Ask your provider to assess this notice as well as the 21 October patches. The project’s current recommendation and its limits are in the official PHP news archive.

Why a WordPress update is not enough

WordPress is an application running on a server environment that includes PHP. Updating WordPress, themes and plugins is different from updating that environment. The WordPress hosting requirements identify PHP as a separate dependency. Ask the host which patched PHP package is actually serving the website, including any subdomains, scheduled tasks and separate installations.

A practical checklist for website owners

1. Assign responsibility. Record who manages the server, application, backups and technical decisions. For managed hosting, request a written status confirmation rather than changing unfamiliar settings yourself.
2. Identify exposed services. Include shops, forms, customer portals and older installations. Prioritise public-facing systems, as recommended by the UK NCSC.
3. Coordinate the update. Ask for the package or advisory reference, completion time and confirmation that the active environment uses the fix. Arrange a backup and a recovery route without postponing urgent protection for a long redesign project.
4. Test the business functions. Check navigation, login, search, forms and any checkout in an authorised test workflow. Record what was actually tested and who confirmed the result.
5. Handle unresolved exposure. If immediate protection is unavailable, discuss isolating the exposed service with the responsible administrator. The Canadian Cyber Centre recommends isolation where prompt patching is not feasible.

What if an attack is suspected?

Preserve relevant logs and a timeline, and have qualified responders assess unexplained file changes, accounts or redirects. A patch addresses a vulnerability; it does not by itself establish whether a prior intrusion left a backdoor. The NCSC guidance specifically calls for compromise assessment where protection has been delayed. Avoid deleting potential evidence or treating an absence of visible errors as an all-clear.

Questions to send your hosting provider

Which PHP installation serves each site? Which vendor advisory confirms the fix? Have you checked the additional 23 October notice? What remains to be done, and who is responsible? These questions produce a more useful record than a general statement that the server is “up to date”.

For help planning the technical review, see our WordPress services. Agree on access, scope and responsibilities before work starts. This article does not certify the security status of an individual website.

Sources checked on 23 October 2026: PHP security advisories, ENISA, UK NCSC, Canadian Cyber Centre and WordPress.org. Follow their current notices for later developments.