# PHP2Shell, CVE-2026-109618 and CVE-2026-109619 PHP RCE (/en/blog/php2shell-cve-2026-109618)
On 21 October 2026 at 14:00 UTC, PHP shipped **PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35** to fix two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both are rated 9.2 under CVSS 4.0 and can allow unauthenticated remote code execution. Details leaked a day before the fix, so the internet spent the morning waiting: DigiD, the Dutch parliament, newsrooms and Root-Me took their sites offline, and CERT-EU told organisations to find their PHP applications.
The first question most teams have is simple: **am I using PHP, and where?** If you run more than a handful of sites, the answer is often "somewhere, probably". The quickest check from the outside is our free [Technology Checker](/tools/tech-checker): paste a URL and it lists the technologies the page reveals, including PHP and the PHP applications built on it (WordPress, Drupal, Magento, Laravel, MediaWiki and many more), with versions, end-of-life status and known CVEs.
*An illustrative result on example data: PHP 8.1.27 is flagged as end of life, with a critical known CVE.*
The short answer, depending on what you find:
* **PHP 8.2 to 8.5:** update now to 8.2.35, 8.3.36, 8.4.27 or 8.5.12.
* **PHP 8.1 or older:** no official release. Apply your vendor's backported package or the PHP source backport, or isolate the site until it runs a fixed version.
* **Managed hosting (WP Engine, Kinsta, WordPress.com and similar):** the host runs and updates PHP, not you. Check its status page to confirm the fix is applied.
This post sums up what PHP2Shell is, how the day unfolded, how to tell whether your sites run PHP, and what to do now. It stays at the level of what and why: no exploitation details.
## What is PHP2Shell, CVE-2026-109618 and CVE-2026-109619 [#what-is-php2shell-cve-2026-109618-and-cve-2026-109619]
They are two vulnerabilities in the PHP interpreter, not in a framework or a plugin. According to the [PHP security advisory](https://www.php.net/archive/2026.php), both can allow unauthenticated remote code execution (RCE): an attacker who can send a request to a vulnerable PHP server may be able to run code on it with the web worker's privileges, without an account.
* **CVE-2026-109618, "RCE via OOM corruption"** ([GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)). An out-of-memory error can stop PHP while request data is only partly set up, and the cleanup that follows then works on invalid data.
* **CVE-2026-109619, "RCE via stale global state"** ([GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)). Internal state from one request can outlive its memory, and the next request handled by the same worker can use it.
| | |
| --------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| CVEs | CVE-2026-109618, CVE-2026-109619 |
| Component | PHP core (the interpreter itself) |
| Type | Remote code execution, no authentication required |
| Severity | Critical, 9.2 under CVSS 4.0, as rated by the PHP security team |
| Nickname | PHP2Shell, used by researchers and the press, not by PHP |
| At risk | Every PHP installation serving web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php highest |
| Affected | PHP below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 |
| Fixed | 8.2.35, 8.3.36, 8.4.27 and 8.5.12, released 21 October 2026 |
Because the bug sits in PHP and not in application code, no code change in WordPress, Drupal or Laravel closes it. PHP lists a few configuration changes that reduce exposure to specific attack paths, and states that they do not make an installation safe: updating PHP is the only complete fix.
## How the day unfolded [#how-the-day-unfolded]
The release was planned for a coordinated disclosure, then the schedule broke.
* **20 October.** The two CVE identifiers spread on social media and Hacker News ahead of the planned embargo date ([Tenable](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote)). The PHP security team published an [advance notice](https://www.php.net/archive/2026.php) of a release for the next day and said it could ship earlier if details became public or exploitation appeared. CERT-EU published [Security Advisory 2026-018](https://cert.europa.eu/publications/security-advisories/2026-018/) the same evening.
* **21 October, morning.** watchTowr confirmed the flaws are remote code execution vulnerabilities in PHP and said it believed it had reproduced CVE-2026-109618. Exploit code described as a proof of concept circulated, with its validity unconfirmed. Reports on exploitation differ: Cloudflare's CTO said the company was seeing early attacks and Cloudflare deployed WAF rules for the known vectors, while watchTowr, Huntress and the Dutch NCSC reported no confirmed exploitation in the wild ([Tenable](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote), [SecurityWeek](https://www.securityweek.com/php2shell-mass-exploitation-looms-for-leaked-critical-php-flaws/), [NOS](https://nos.nl/artikel/2636055-websites-als-mijnoverheid-en-digid-offline-vanwege-lek-risico-op-hacks)). [Sansec](https://sansec.io/research/php2shell) expects mass attacks within 15 minutes of the release.
* **21 October, 14:00 UTC.** PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with a [security advisory](https://www.php.net/archive/2026.php). It says Linux distributions and long-term support vendors received the patches in advance, and that an exploit was demonstrated against Apache with mod_php.
The scale is what worried defenders: public estimates of internet-exposed PHP hosts range from 1.3 million (Silas Cutler) to 1.9 million (a Shodan search by Henk Poley), as compiled by [Tenable](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote).
## Lights out, the sites that went dark before the patch [#lights-out-the-sites-that-went-dark-before-the-patch]
Many organisations did not wait for 14:00 UTC. [CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-018/) told those unable to patch right away to consider isolating internet-facing applications, and several governments, media groups and platforms switched their sites off as a precaution. Going offline does not mean a site was hacked: it closes the door until the fix is installed.
**Netherlands.** According to [NOS](https://nos.nl/artikel/2636055-websites-als-mijnoverheid-en-digid-offline-vanwege-lek-risico-op-hacks), these went offline as a precaution:
* The National Cyber Security Centre (NCSC), the national cybersecurity agency itself
* MijnOverheid.nl and the DigiD website, the citizen portal and the government login service
* The Tweede Kamer, the lower house of parliament
* The Autoriteit Persoonsgegevens, the data protection authority
* RTL Nieuws, its website and app
* Tweakers, the tech news site
* Notubiz, the meeting platform used by about 100 municipalities
* ANP, the national news agency, which took its systems offline
**Belgium.** [DPG Media](https://www.lalibre.be/dernieres-depeches/2026/10/21/faille-de-securite-dans-php-dpg-media-suspend-plusieurs-de-ses-sites-internet-apres-la-decouverte-dune-faille-GUCV4X2BYZFIZCZJIYSIJPO44U/) suspended several of its Belgian and Dutch sites. [Roularta](https://www.dhnet.be/actu/belgique/2026/10/21/des-milliers-de-sites-web-menaces-par-une-faille-critique-plusieurs-plateformes-belges-deja-mises-hors-ligne-AQCXC5THHVB2FIE4DQGLIAMTZY/) took down the websites of its magazines, including Le Vif and Trends Tendances, and the school platform Smartschool was unreachable. The [RTBF](https://www.rtbf.be/article/le-groupe-belge-dpg-media-a-annonce-avoir-temporairement-mis-hors-ligne-plusieurs-de-ses-sites-internets-par-precaution-11803667) also lists the energy price comparator of the regulator CREG and official sites of the Flemish Region.
**Finland.** A Finnish government agency took sites offline, according to [Reuters reporting](https://www.globalbankingandfinance.com/cyber-agency-warns-websites-go-dark-php-prepares-critical/).
**France.** [Root-Me](https://www.root-me.org/), the hacking training platform, replaced its whole site with a maintenance notice. It says the platform is offline as a precaution, after the disclosure of critical PHP vulnerabilities, while the team assesses the impact on its infrastructure and applies the fixes.
The [YesWeHack login page](https://yeswehack.com/auth/login), the bug bounty platform, showed an "Under maintenance" page the same afternoon. YesWeHack had not stated a reason when we checked, so the link to PHP is ours, not theirs.
The list kept growing through the day. The [NOS liveblog](https://nos.nl/liveblog/2636066-websites-kwetsbaar-voor-softwarelek-rtl-nieuws-digid-en-mijnoverheid-uit-de-lucht) adds the Schiphol airport app, the Dutch football federation KNVB and the clubs FC Twente, Fortuna Sittard and Willem II, the Unie van Waterschappen, the province of Groningen, six Dutch hospitals including Haaglanden MC and St. Antonius Ziekenhuis, and in Belgium the AZ Monica hospital and all Flemish government websites. Every one of them had to answer the same question first: where do we run PHP?
## Which PHP versions are affected and fixed [#which-php-versions-are-affected-and-fixed]
Both advisories list the same ranges: every PHP version below the releases in this table is affected, and only the [supported branches](https://www.php.net/supported-versions.php) get an official release.
| Branch | Status | Fixed in | Security support until |
| ------------- | ------------------- | ------------------- | ---------------------- |
| 8.5 | Active support | 8.5.12 | 31 Dec 2029 |
| 8.4 | Active support | 8.4.27 | 31 Dec 2028 |
| 8.3 | Security fixes only | 8.3.36 | 31 Dec 2027 |
| 8.2 | Security fixes only | 8.2.35 | 31 Dec 2026 |
| 8.1 and older | End of life | No official release | Ended |
Source downloads and Windows builds are on the [PHP downloads page](https://www.php.net/downloads.php). Most servers get PHP from a distribution or a container image, so update through your package manager or rebuild on a patched base image. PHP warns that the volunteer-run `rpms.remirepo.net` repository would not have updates on release day, and advises switching to distribution packages or building from source.
PHP 8.2 is fixed, but its security support ends on 31 December 2026. If you patch an 8.2 server today, plan its move to 8.4 or 8.5 now.
### Is PHP 8.1 vulnerable? No official release for 8.1 and older [#is-php-81-vulnerable-no-official-release-for-81-and-older]
Yes. The advisories mark every version below the fixed releases as affected, and [Sansec](https://sansec.io/research/php2shell) says the bugs reach back to PHP 5.4. PHP 8.1 reached [end of life](https://www.php.net/eol.php) on 31 December 2025, so there is no PHP 8.1 release with the fix.
Given the severity, the PHP security team made an exception and published minimal source backports for [PHP 7.4](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619), [PHP 8.0](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619) and [PHP 8.1](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619), for people who build PHP from source or have no long-term support vendor. Some distributions and LTS vendors ship their own backported packages, so check with yours. For PHP 7.3 and older, nothing was published: treat those servers as exposed until they are upgraded.
## Am I using PHP? Check if a website uses PHP [#am-i-using-php-check-if-a-website-uses-php]
You may run PHP without ever choosing it. Most PHP on the web arrives through an application: a CMS, a shop, a forum, a wiki, an admin tool. If a site is built on one of these, the server runs PHP.
To check one site from the outside, paste its URL into the [Technology Checker](/tools/tech-checker). It reports PHP directly when the server reveals it, and it reports the applications that imply PHP, such as WordPress or Magento, even when PHP itself stays hidden. When a version can be read, it shows whether that version is end of life and which known CVEs affect it.
Two signs give PHP away in a response: an `X-Powered-By: PHP/8.1.27` header, and a `PHPSESSID` cookie. Many sites hide both, which is why the checker also looks for the applications. That header is an information leak in its own right, and a version banner like `PHP/8.1` tells an attacker no patch is coming. For the general method behind reading a site's stack, read [What technology is this website using, and is any of it outdated](/en/blog/what-technology-is-this-website-using).
From the inside, on a server you control, check the PHP that serves the site, not only the command-line one, since they can differ:
```bash
php -v # command-line PHP
php-fpm8.3 -v # PHP-FPM, name depends on your version and distribution
dpkg -l 'php*' # Debian and Ubuntu packages
rpm -qa 'php*' # Red Hat, Rocky, Alma packages
```
Distribution packages with a backported fix keep the old upstream version string, so read the package changelog rather than the version number alone. In a running application, the hosting control panel shows the PHP version the site uses.
### Is WordPress, Drupal or Magento affected? Apps that run on PHP [#is-wordpress-drupal-or-magento-affected-apps-that-run-on-php]
Yes, when the PHP underneath them is affected. Each of these runs on PHP, so if the checker finds one on your site, the site runs PHP, even when the PHP version itself is hidden. Here are the best known, grouped by category.
**CMS and site builders.** WordPress, Drupal, Joomla, TYPO3, Craft CMS, Concrete CMS, Contao, MODX, ProcessWire, Grav, Kirby, Statamic, Silverstripe, Backdrop CMS, October CMS, Winter CMS, Pimcore, Ibexa DXP, ExpressionEngine, SPIP, 1C-Bitrix.
**E-commerce.** Magento, PrestaShop, Shopware, OpenCart, osCommerce, CS-Cart, X-Cart, OXID eShop, Sylius, Thelia, Drupal Commerce, VirtueMart, Craft Commerce. WooCommerce runs on WordPress, so it runs on PHP too.
**Frameworks.** Laravel, Symfony, CodeIgniter, CakePHP, Yii, Nette, ThinkPHP, Livewire (Laravel), Neos Flow.
**Forums, wikis and blogs.** MediaWiki, DokuWiki, phpBB, MyBB, vBulletin, XenForo, Invision Community, Flarum, Vanilla Forums, Discuz!, Dotclear.
**Business and admin tools.** Moodle, Nextcloud, ownCloud, phpMyAdmin, Adminer, Roundcube, osTicket, GLPI, Zabbix, BookStack.
**Managed WordPress hosts.** WP Engine, Kinsta, WordPress.com and WordPress VIP. A site on these platforms runs PHP, but the host manages the PHP runtime, so check its status page rather than your server. For WordPress core flaws of the year, see [WordPress vulnerabilities in 2026](/en/blog/wordpress-vulnerabilities-2026).
## Am I vulnerable to the PHP RCE? [#am-i-vulnerable-to-the-php-rce]
If a public site runs PHP, it is in scope until you know its PHP version and patch it. The checks, in order:
1. **Find every site that runs PHP.** Start from your list of domains and subdomains, run the [Technology Checker](/tools/tech-checker) on each, and look for PHP or any technology in the list above. Do not forget staging sites, old marketing microsites, admin panels and the WordPress blog nobody owns anymore.
2. **Read the PHP version.** On the server with the commands above, in the hosting panel, or in the checker result when the server exposes it.
3. **Compare it with the fixed versions** in the table above. For a distribution package, check the vendor advisory instead.
A version outside the affected range rules the advisory out. A version inside it means the site is exposed until it is patched, whatever the application on top.
## What to do now [#what-to-do-now]
Our recommendations, from the most urgent:
1. **Take offline any public site you cannot patch today.** That means PHP 8.1 and older, unless you apply your vendor's backported package or build from the PHP source backport, and any supported server you cannot update right away. Put the site behind authentication, restrict it to internal IPs, or switch it off until it runs a fixed version, and plan the move of end-of-life servers to a supported branch. CERT-EU recommends isolating internet-facing applications from public networks until a fix can be applied.
2. **Patch now.** For PHP 8.2 to 8.5, update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, through your distribution packages, your container base image, or your hosting provider. Container images and CI runners count: rebuild them, do not only patch the hosts.
3. **Put a well-configured WAF in front of your PHP applications.** Cloudflare deployed rules for the known attack vectors, including on its free plan, and calls them a stopgap ([Tenable](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote)). A WAF buys time and blocks known payloads, but it does not fix PHP, and it only protects traffic that actually goes through it. Check that your origin servers are not reachable directly.
4. **Monitor your servers for unusual behaviour.** Watch for new or modified `.php` files in web roots, unexpected processes spawned by the PHP or web server user, outbound connections from web servers, new admin accounts in your applications, and spikes in errors. [Aikido](https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell) advises checking for compromise after patching, going back at least to June 2026: web shells, unexpected files, new admin users, unusual outbound connections and modified PHP files.
## Keep an inventory before the next one [#keep-an-inventory-before-the-next-one]
This week's question, "do we run PHP, and which version?", comes back with every critical CVE. It was [WordPress](/en/blog/wordpress-vulnerabilities-2026) and [Next.js](/en/blog/nextjs-vulnerabilities-2026) earlier this year, it is PHP today. A one-off check answers for one URL on one day.
For server-side software like PHP, the free [Technology Checker](/tools/tech-checker) is the quick outside view. For the code that runs in your visitors' browsers, CentralCSP keeps the inventory current: it lists the scripts each page loads, identifies the library and version behind each one, and alerts you when a new CVE affects a version you serve. The inventory is described in [Technologies](/en/docs/platform/features/technologies), and the [supply-chain feature page](/platform/supply-chain) has the tour. [Start free with CentralCSP](/register) to see your own sites.
## FAQ [#faq]
### What is PHP2Shell? [#what-is-php2shell]
PHP2Shell is the nickname researchers and the press gave to CVE-2026-109618 and CVE-2026-109619, the two critical PHP remote code execution flaws announced on 20 October 2026. It is not an official PHP name.
### Is PHP 8.1 affected? [#is-php-81-affected]
Yes, and there is no official 8.1 release with the fix: see [Is PHP 8.1 vulnerable? No official release for 8.1 and older](#is-php-81-vulnerable-no-official-release-for-81-and-older).
### Is PHP 8.2 fixed? [#is-php-82-fixed]
Yes, in PHP 8.2.35. Its security support ends on 31 December 2026, so plan the move to 8.4 or 8.5.
### Does disabling session.upload_progress protect against PHP2Shell? [#does-disabling-sessionupload_progress-protect-against-php2shell]
Only partly. PHP lists `session.upload_progress.enabled=0` among the measures that reduce exposure if you cannot update right away: it blocks the confirmed paths for CVE-2026-109619 but not other variants, and does nothing for CVE-2026-109618. PHP states that only an update is a complete solution.
### Is PHP2Shell being exploited in the wild? [#is-php2shell-being-exploited-in-the-wild]
On 21 October, reports differed: Cloudflare said it was seeing early attacks, while watchTowr, Huntress and the Dutch NCSC reported no confirmed exploitation. PHP's advisory mentions a demonstrated exploit against Apache with mod_php. Treat any unpatched, internet-facing PHP server as a target.
### Is WordPress affected by PHP2Shell? [#is-wordpress-affected-by-php2shell]
A WordPress site is exposed when the PHP version on its server is affected. Updating WordPress does not help, because the flaws are in PHP. On managed WordPress hosting, the host manages PHP, so check its status page.
### Does updating Drupal, Magento or Laravel fix it? [#does-updating-drupal-magento-or-laravel-fix-it]
No. The flaws are in PHP itself, so updating the application does not change the PHP interpreter running it. You need to update PHP.
### How do I know if a website uses PHP? [#how-do-i-know-if-a-website-uses-php]
Paste its URL into the free [Technology Checker](/tools/tech-checker). It shows PHP when the server reveals it, and the PHP applications (WordPress, Magento, MediaWiki and others) that imply PHP when it does not. On your own server, run `php -v`.
### Is my site vulnerable if it is behind Cloudflare? [#is-my-site-vulnerable-if-it-is-behind-cloudflare]
It is less exposed to the known attack vectors, because Cloudflare deployed WAF rules for them, but it is still vulnerable. WAF rules cover known payloads only, and an attacker who reaches the origin server directly bypasses them. Patch PHP anyway.
## Related [#related]
* [What technology is this website using, and is any of it outdated](/en/blog/what-technology-is-this-website-using)
* [WordPress vulnerabilities in 2026](/en/blog/wordpress-vulnerabilities-2026)
* [Next.js vulnerabilities in 2026, the AVIF RCE and the version to run](/en/blog/nextjs-vulnerabilities-2026)
* [How to detect vulnerable JavaScript libraries on a live website](/en/blog/detect-vulnerable-javascript-libraries)
* [What a technology checker is for, from security ratings to PCI scans](/en/blog/technology-checker-use-cases)
## Sources [#sources]
* [PHP, news archive 2026, security advisory and advance notice](https://www.php.net/archive/2026.php)
* [GitHub, GHSA-w8hw-w9fx-j79w, RCE via OOM corruption, CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
* [GitHub, GHSA-6wmf-4rv5-p3rp, RCE via stale global state, CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
* [PHP, Supported versions](https://www.php.net/supported-versions.php)
* [CERT-EU, Security Advisory 2026-018, Critical Vulnerabilities in PHP](https://cert.europa.eu/publications/security-advisories/2026-018/)
* [Tenable, php2shell FAQ](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote)
* [SecurityWeek, PHP2Shell mass exploitation looms](https://www.securityweek.com/php2shell-mass-exploitation-looms-for-leaked-critical-php-flaws/)
* [Sansec, Critical PHP RCE, CVE-2026-109618 and CVE-2026-109619](https://sansec.io/research/php2shell)
* [NOS, Websites like MijnOverheid and DigiD offline over the flaw](https://nos.nl/artikel/2636055-websites-als-mijnoverheid-en-digid-offline-vanwege-lek-risico-op-hacks)
* [NOS liveblog, websites offline after the software flaw](https://nos.nl/liveblog/2636066-websites-kwetsbaar-voor-softwarelek-rtl-nieuws-digid-en-mijnoverheid-uit-de-lucht)
* [La Libre, DPG Media suspends several of its websites](https://www.lalibre.be/dernieres-depeches/2026/10/21/faille-de-securite-dans-php-dpg-media-suspend-plusieurs-de-ses-sites-internet-apres-la-decouverte-dune-faille-GUCV4X2BYZFIZCZJIYSIJPO44U/)
* [DH, Belgian platforms already offline](https://www.dhnet.be/actu/belgique/2026/10/21/des-milliers-de-sites-web-menaces-par-une-faille-critique-plusieurs-plateformes-belges-deja-mises-hors-ligne-AQCXC5THHVB2FIE4DQGLIAMTZY/)
* [Global Banking and Finance Review (Reuters), Cyber agency warns websites may go dark](https://www.globalbankingandfinance.com/cyber-agency-warns-websites-go-dark-php-prepares-critical/)
* [Aikido, Critical vulnerabilities in PHP](https://www.aikido.dev/blog/critical-vulnerabilities-in-php-php2shell)
* [PHP, Unsupported branches](https://www.php.net/eol.php)
* [RTBF, DPG Media takes several sites offline as a precaution](https://www.rtbf.be/article/le-groupe-belge-dpg-media-a-annonce-avoir-temporairement-mis-hors-ligne-plusieurs-de-ses-sites-internets-par-precaution-11803667)