PHP ships critical security fixes: what website owners should do now

The PHP project released emergency security updates on 21 October 2026 to fix two critical vulnerabilities. Both can allow an unauthenticated remote code execution attack, which means a stranger on the internet could run their own code on a web server without logging in. PHP is the language behind a huge share of the web, including WordPress, Drupal and Joomla, so this matters to anyone who runs a site, even if they never touch code.

What PHP released

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619, and the project's advance notice on 20 October rated both 9.2 on the CVSS v4.0 scale, where 10 is the maximum. The release notes say all users are strongly encouraged to update immediately and that there are no complete mitigations, so updating is the only safe choice.

The PHP team describes the first bug as a memory-handling problem and the second as stale internal state that can survive between requests handled by the same worker. According to PHP, every installation that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is considered highest for mod_php, where a demonstrated exploit can trigger the attack before any application code runs.

Support status matters too. PHP 8.1 and older no longer receive updates from the PHP project, although some Linux distributions and long-term support vendors provide their own backported fixes. PHP 8.2 reaches end of life on 31 December 2026, so a site on that branch should plan its next upgrade now.

Who found it, and how serious is the threat

BleepingComputer reports that researchers from Calif, OpenAI and Wiz discovered the flaws, and the bugs are being called PHP2Shell. TidBITS says Wiz Research used frontier AI models in the work, and Wiz itself says such models lowered the barrier to turning a long-standing flaw into a working exploit. The outlets we read differ on which specific models were involved, so we do not name them here.

On real-world attacks, the picture is mixed but worth taking seriously. Help Net Security reports that Amazon's MadPot honeypot recorded an exploitation attempt on 17 October, four days before public disclosure, and that how the attacker learned the details is unknown. BleepingComputer quotes Cloudflare's chief technology officer saying the company was already seeing early attacks. Neither report gives a count of compromised sites, and the PHP project itself has not confirmed widespread exploitation. The UK's National Cyber Security Centre has urged organizations to update immediately or take affected systems offline.

You may see the claim that 70 percent of websites are exposed. TidBITS attributes that figure to a Wiz blog post, and it is a rough estimate of PHP's share of the web, not a count of vulnerable sites. Treat it as a sense of scale.

What site owners should do

Start by finding out whether you run PHP and which version.

1. Check your PHP version. Most hosting control panels show it in a PHP or "software" settings page. WordPress users can open Tools, then Site Health, then the Info tab, and look under Server. Another option is a phpinfo page, but only create one temporarily and delete it right after, because it exposes details about your server.
2. Compare the version with the fixed releases: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. A version number can look old on a managed host that has patched it another way, so a lower number alone is not proof of a problem.
3. Ask your host directly. Good questions are: Has the October 21 PHP security update been applied to my plan? Which PHP version and handler (mod_php, PHP-FPM or other) do I run? If I am on PHP 8.1 or older, do you provide backported fixes, and can I move to a supported version?
4. If you manage your own server, install the updated packages from your Linux distribution or vendor, or update to a fixed release, then restart the web server or PHP workers as your setup requires.
5. If you cannot patch yet, the PHP project lists temporary settings that reduce exposure, but it states they do not make an installation safe. Read the official notes and treat them only as a stopgap.

For WordPress, Drupal and Joomla owners, the key point is that the problem sits in PHP itself, not in your plugins or themes. Updating the CMS will not fix it. The PHP version on your server has to change, and on shared or managed hosting that is the host's job. Confirm it in writing if you can, and keep regular backups in case you need to restore.

What to watch next

Expect hosting providers to roll out patches over the coming days, and expect scanning and attack attempts against slow-to-update sites in the meantime. Help Net Security notes that one third-party package repository had no updates on release day, so check your own source if you do not use stock distribution packages. If your host is slow to answer, consider whether it is the right home for your site.