---
title: Site Owners Should Check Their PHP Version Now as PHP2Shell Attacks Spread
description: Two critical PHP flaws are under attack. Which PHP versions fix PHP2Shell, how to check your site's PHP version, and what to do if you cannot patch yet.
author: Darie Nani (Editor-in-Chief)
date: 2026-10-26T13:17:39.131Z
updated: 2026-10-26T13:17:39.152Z
canonical: https://www.sovereignmagazine.com/article/how-to-check-if-my-site-is-vulnerable-to-php2shell
image: https://cdn.nanimediahouse.com/pexels-a-developer-working-on-a-laptop-typing-code-showcasing-progr-4974912.jpg
categories: Science & Tech
content_type: News
region: Global
publication: Sovereign Magazine
schema_type: Article
---

Attackers are now sending exploit attempts at PHP websites by the million, two days after the PHP project fixed two critical flaws in the language that Wiz Research says powers 70% of the world's websites. The project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on Oct. 21 to close CVE-2026-109618 and CVE-2026-109619, a pair of bugs known together as PHP2Shell that can let an attacker run code on a server without logging in. Both are rated critical, at 9.2 on the CVSS v4.0 scale. "Updating is the only complete mitigation," Jakub Zelenka of the PHP security team wrote in the team's announcement on the oss-security mailing list.

The PHP project says every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where an unauthenticated request can trigger the attack before any application code runs; its security team says source analysis indicates PHP-FPM is also susceptible, although no complete FPM exploit has been demonstrated. Wiz Research, which found the flaws with Calif and OpenAI, combined them into one exploit script and ran code remotely on the standard WordPress, Drupal and Joomla container images. Wiz says even a simple "Hello World" application on an affected PHP version can be vulnerable, and that attackers can read passwords, tokens and API keys from the PHP process's memory without getting as far as running code.

## Amazon Logged an Exploit Attempt Four Days Before the Patch

Amazon Threat Intelligence found [a PHP2Shell exploitation attempt dated Oct. 17](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) in MadPot, its honeypot network, four days before public disclosure. The attempt came from an IP address tied to a commercial anonymization network, and Amazon says it is unclear how the attacker got the exploit information early. Details of the flaws then leaked online on Oct. 20, ahead of the coordinated disclosure, SecurityWeek reported. Amazon says it identified multiple proof-of-concept exploits from around 02:00 UTC on Oct. 21, 12 hours before the embargo lifted at 14:00 UTC.

Matthew Prince, Cloudflare's chief executive, said the company's network saw "thousands of attempts to exploit it" in the 10 hours before the announcement. "That jumped to tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now," Prince said, as quoted by SecurityWeek. Jake Knott of the security firm watchTowr said the exploits in circulation "either don't work at all, test for timing-based differences, or crash the target", and Amazon says it is unclear whether any of the attempts it has seen would have succeeded against real systems.

Of 2.58 million internet-facing hosts Censys saw on Oct. 21, about 1.58 million showed an identifiable PHP version, and about 1.57 million of those had not been patched, SecurityWeek reported.

The US Cybersecurity and Infrastructure Security Agency urged organizations on Oct. 21 to update immediately. The UK's National Cyber Security Centre told British organizations to update PHP or take systems offline until they can be patched.

Amazon advises operators to investigate from Oct. 17 at the latest, not from the disclosure date. It recommends looking for POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS in form uploads, reviewing web server logs, and checking web servers for unexpected processes or modified files.

> "With PHP2Shell, compromise may predate the advisory."
> — Amazon Threat Intelligence

## About a Third of WordPress Sites Run PHP Versions the Project No Longer Updates

WordPress.org's statistics on the PHP versions its sites run put about 34.7% of WordPress sites on PHP 8.1 or older, and PHP 8.1 and older no longer get updates from the PHP project, though its security team posted minimal source backports for 7.4, 8.0 and 8.1. Its fixed releases cover only the four supported branches, while Wiz says every PHP version released in the last decade, going back to 5.4, is affected by at least one of the two flaws.

## A Server's Reported PHP Version Does Not Always Show Whether It Is Patched

A site is patched if it runs PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a later release on the same branch. WordPress lists the server's PHP details in the dashboard under Tools, Site Health, Info, in the Server section; hosting control panels show the version too, and over SSH the php -v command prints it.

The php -v command reports the command-line PHP, which is not always the program the web server is using to answer requests. Linux distributions and long-term-support vendors received the patches in advance, the PHP project says, and distributions that package PHP may ship the fix under their own version numbers, so on those servers the vendor's security advisory shows whether PHP is patched. On managed hosting, the host runs PHP and has to confirm the update.

Astra Security released a free PHP2Shell Checker on Oct. 23 that compares the PHP version a public website appears to serve against the fixed releases, and needs no account. The company says the result "is a first signal, not a verdict", because proxies, hosting providers and server settings can hide or alter version information. For servers a team runs itself, Astra also offers php2shell-triage, an open-source tool whose read-only script inspects the binaries behind running PHP workers instead of the command-line version, which the company says catches servers that report a patched PHP while old workers still serve the vulnerable one.

## Updating PHP and Restarting Every Worker Is the Only Complete Fix

Patching a server means installing the fixed release for its branch, or the vendor's patched package, and then restarting PHP-FPM, Apache or whatever runs the PHP workers, since workers started before the update keep running the old code. After the restart, operators need to confirm that the patched runtime is the one serving requests. Where a compromise is suspected, evidence should be captured before anything is restarted.

Sites on PHP 8.1 or older can install a vendor's backported package, apply the minimal source backports the PHP security team published for 7.4, 8.0 and 8.1 for people who build PHP from source or have no access to a long-term-support vendor, or move to a supported branch. For servers that cannot be updated right away, Amazon says there are no configuration-only workarounds that fully address both issues, and the PHP project says its stopgap settings "reduce exposure to specific attack paths but do not make an installation safe." Isolating vulnerable systems until they are patched is the other option.

## PHP Recommends Turning Off Session Upload Progress Even on Patched Servers

On Oct. 23 the PHP project published an informational advisory about a further flaw, CVE-2026-115560, which [Cloudflare says affects fully patched PHP releases, including 8.5.12](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/). PHP says it can only occur under an unusual combination of configuration and application code, in which an application sets session.serialize_handler to php_binary or php_serialize, then switches it to php at runtime with ini_set() before session_start(), while session upload progress is enabled. PHP suggests setting session.upload_progress.enabled=0 until its next regular bugfix release "to fully protect from an unlikely RCE vector", and says it will publish a full advisory with that release. "Applications that never change the serialize handler at runtime can keep the feature enabled," the project adds.

PHP's advisories and fixed releases are at [php.net](https://www.php.net/archive/2026.php).

## FAQ

**Q: What is the PHP vulnerability?**
PHP2Shell is the name for two memory-handling bugs in PHP's core runtime. In CVE-2026-109618, out-of-memory handling can interrupt PHP while internal request data is only partly set up, and PHP's request cleanup can then treat that invalid data as valid. In CVE-2026-109619, internal state belonging to one request can survive after its memory has been freed, and a later request handled by the same worker can use that stale state. Wiz compares the find to Heartbleed in 2014 and Log4Shell in 2021, and says frontier AI models let its researchers develop and adapt working exploits across multiple applications in hours.

**Q: Is PHP 7.4 vulnerable?**
Yes. The PHP project has no official fixed release for 7.4, so a site on 7.4 needs the source backport, a vendor package or an upgrade. A CrowdStrike blog post, quoted on the oss-security mailing list, says the code behind CVE-2026-109618 first shipped in PHP 7.3.0 in December 2018. About 15.5% of WordPress sites still run PHP 7.4, by WordPress.org's figures.

**Q: How do I check whether my website is vulnerable?**
Compare the PHP version your web server actually runs, from Site Health or your host rather than php -v, with the four fixed releases or your vendor's patched package; on managed hosting, ask the host to confirm. Then search web server logs from Oct. 17 onward for POST requests containing PHP_SESSION_UPLOAD_PROGRESS, the string Amazon tells operators to look for. Online checkers only see a version the server announces, and most PHP servers do not announce one: VirusTotal sees about 5.1 million IP addresses running PHP, of which about 1.1 million state a version, SecurityWeek reported.

**Q: How do I fix the PHP vulnerability?**
Update PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or your vendor's patched package, and restart every PHP worker. Updating WordPress, Drupal, Joomla or a plugin does not fix PHP2Shell, because the flaws are in PHP itself and Wiz showed they can be exploited regardless of the application's code. If the update has to wait, the PHP project lists stopgaps: for CVE-2026-109618, set memory_limit=-1 in a way applications cannot override and set a low post_max_size (8M without uploads, 32M with them); for CVE-2026-109619, set session.upload_progress.enabled=0. These settings have to go in php.ini, an FPM pool or the server configuration, not ini_set() or .user.ini. On PHP 8.5, PHP also advises setting fatal_error_backtraces=0.

**Q: Does a web application firewall such as Cloudflare's protect my site?**
Only in part. Cloudflare switched on WAF protection by default for its free and paid WAF customers from 03:02 UTC on Oct. 21, but says "Customers should patch their PHP repos even with WAF protections." For CVE-2026-115560, Cloudflare's rule covers sites using PHP's default upload progress field name; sites that changed session.upload_progress.name are not covered.