PHP2Shell: what the PHP security alert means for your website

The fixes came out on 21 October

The two vulnerabilities are CVE-2026-109618 and CVE-2026-109619. They are rated critical, with a CVSS v4.0 score of 9.2. Under the right conditions, an attacker can run code on an affected server without logging in.

The PHP Foundation says the coordinated release was originally scheduled for 22 October. After the CVE identifiers circulated on 20 October, PHP brought the release forward to 21 October. Early claims of a 10.0 score were incorrect. That timing explains why a fix released yesterday is dominating the news today.

Reporting by The Record describes organisations taking services offline while they dealt with the risk. A precautionary shutdown is different from a confirmed break-in; the fact that a site went offline does not tell us it was hacked.

Source: The PHP Foundation: release, discovery and disclosure timeline; UK NCSC: critical security issue affecting PHP; The Record: organisations taking websites offline

What is wrong with PHP?

These are faults in the PHP runtime, the software on the server that runs PHP applications. The two advisories describe failures in how PHP manages memory and information left behind between requests.

Source: PHP advisory: CVE-2026-109618; PHP advisory: CVE-2026-109619

A current-looking website can still need the fix

PHP lists web-serving installations including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as at risk. It considers the risk highest for mod_php, where an attack has been demonstrated before application code runs. The exact attack paths vary by setup.

This needs checking even if your website was built recently. WordPress says no WordPress update is required or planned for these particular flaws: the fix belongs in PHP. Updating a theme or plugin doesn't install it.

In WordPress, Tools > Site Health > Info > Server shows the reported PHP version. Use that as a starting point for a conversation with your host. The full package revision and any vendor fixes still need checking.

Source: PHP: 21 October security advisory and fixed releases; WordPress: critical PHP security release

Which PHP versions contain the fixes?

The PHP project released these fixes on 21 October 2026. Vendor-maintained packages can use different numbers.

Source: PHP: 21 October security advisory and fixed releases

Why an older number does not always mean unpatched

Some operating-system and hosting vendors apply the security fix to an older release they maintain. This is called backporting. You need the vendor advisory and full package revision to check it properly.

For example, Ubuntu lists PHP 8.3.6-0ubuntu0.24.04.13 as a corrected package for Ubuntu 24.04 LTS in USN-8948-1. That is a specific Ubuntu package, with fixes to the version Ubuntu supplies. It does not mean an ordinary, unpatched PHP 8.3.6 installation is safe.

I'd want a host to name the installed package and confirm that it contains both CVE fixes. A generic reply saying the server is up to date leaves the important question unanswered. Equally, an outside checker that sees only a short version string may miss a legitimate vendor fix.

Source: Ubuntu: USN-8948-1; Red Hat: CVE-2026-109618 and backporting explanation

Patching and checking for an earlier break-in are separate jobs

Amazon Threat Intelligence reports a PHP2Shell exploitation attempt in its MadPot honeypot telemetry dating to 17 October, before public disclosure. Its account distinguishes observed attempts from uncertainty about whether those early attempts would have succeeded against real systems. It also reports broader exploitation after disclosure.

That is a reason to ask about the exposure period as well as the update. It is not evidence that your particular website has been compromised. A patched server can still need investigation into what happened beforehand.

Ask the person responsible for security to preserve the relevant logs and consider the earlier activity in their review. I'd want suspicious file changes or unexpected processes investigated before treating the job as complete. If a break-in is suspected, agree a recovery plan; applying the PHP update alone does not establish that an attacker has been removed.

Source: Amazon Threat Intelligence: PHP2Shell observations

A firewall helps, but PHP still needs patching

Cloudflare says it deployed PHP2Shell WAF protections, including for its Free plan, before disclosure. Its own advice still tells customers to patch PHP. A web application firewall is an additional defence, and its protections do not establish which PHP package is running at the origin server.

I'd ask whether the protection is active for the actual website and how the origin is reached. Having a Cloudflare account is not enough information to decide that the hosting has been fixed.

The UK NCSC advises finding PHP systems, prioritising those exposed to the internet and applying updates. Where updating is not possible, it points to temporary mitigations. If those cannot be applied, or would take too long, it says organisations should consider taking the system offline until it can be fully mitigated. Agree that decision with the person running the service, using the current official guidance.

Source: Cloudflare: PHP2Shell WAF protections; UK NCSC: critical security issue affecting PHP

AI helped the research. People still had to deliver the fix

OpenAI says Calif identified a critical flaw using its models through Patch the Planet, and that Wiz independently discovered and reported both vulnerabilities. Wiz describes using AI to develop and adapt exploits. PHP maintainers led the fixes and release.

There is a longer history too. The PHP Foundation traces early signs of the out-of-memory problem to work following a 2024 audit. It acknowledges delays caused by difficult compatibility decisions and limited resources. Its account says people still make the decisions and work on every patch, with AI helping validation.

I'd use this as a prompt to check who can apply an urgent server update when the normal maintainer is unavailable. Keep the hosting responsibilities and emergency contact route clear, with access available to the people authorised to act.

Source: OpenAI: Patch the Planet response; Wiz Research: PHP2Shell investigation; The PHP Foundation: release, discovery and disclosure timeline

What I would ask the hosting provider

Keep the website address and account details in the support request, and ask for an answer covering the actual installation. This is a useful starting list:

• Have both CVE-2026-109618 and CVE-2026-109619 been fixed for this site? Which PHP package or vendor build contains the fixes?
• Has the PHP service been restarted or replaced where required, so the running workers use the patched code?
• Does that confirmation cover staging sites, other PHP versions on the account, old containers and any retained public origin or rollback site?
• What firewall or temporary mitigations are active, and is there anything the account owner still needs to do?
• Has the exposure period been reviewed for suspicious activity? What logs have been preserved and what, if anything, needs further investigation?
• After the update, who will check forms, checkout, bookings and any custom integrations that the business relies on?

If the website still depends on older PHP

PHP 8.1 and older are outside the PHP project's normal support. Some vendors provide backported fixes, and PHP also supplied minimal source backports for 7.4, 8.0 and 8.1 for this incident. That does not restart normal upstream support for those branches.

Check the precise coverage with the vendor and make a plan for moving to a supported branch. PHP 8.2 still receives security support, but that ends on 31 December 2026 according to the PHP support table.

I'd deal with this incident promptly, then arrange compatibility testing for the longer-term upgrade. Record the plugins and custom code that need checking, keep a recoverable backup and test the routes that bring work into the business. An old site left online for rollback needs its own security decision too.

Source: PHP: 21 October security advisory and fixed releases; PHP: supported versions