PHP2Shell is two critical PHP flaws (CVE-2026-109618 and CVE-2026-109619) that let an unauthenticated attacker run code on a web server. PHP fixed them on 21 October 2026 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35; CISA added both to its Known Exploited Vulnerabilities catalog on 26 October. It matters for consent because on most WordPress sites the cookie banner, its blocking rules and the consent records all live on that PHP server. Whoever controls the server controls what the browser receives, banner included. And the scripts you load from other hosts are only as safe as those hosts. Patch first, then check your PHP version, your consent setup, and which third-party requests your pages make.
What PHP2Shell is
The PHP security advisory of 21 October describes two bugs, both rated CVSS v4.0 9.2:
- CVE-2026-109618, “RCE via OOM corruption” (GHSA-w8hw-w9fx-j79w): running out of memory can interrupt PHP while internal request data is only partly set up, and cleanup may then treat that invalid data as valid.
- CVE-2026-109619, “RCE via stale global state” (GHSA-6wmf-4rv5-p3rp): internal state from one request can survive after its memory has been freed, and a later request on the same worker may use it.
The flaws are in PHP itself, not in WordPress or any plugin. PHP says the people at risk are “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed”, with the risk highest for mod_php, where “an unauthenticated request can trigger the attack before any application code runs”. Wiz, which found the bugs, says every PHP version from the last decade is affected by at least one of them, back to 5.4, and demonstrated code execution against stock WordPress, Drupal and Joomla images.
Versions and timeline
| Branch | Fixed in |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 7.4 – 8.1 | No official release. PHP published minimal source backports; distributions and LTS vendors may ship fixes. |
| Older than 7.4 | No fix from the PHP project. |
- 19–24 August: Wiz found the first bug and reported it to PHP.
- 17 October: Amazon Threat Intelligence saw an exploitation attempt four days before disclosure, according to Tenable’s FAQ, and recommends starting investigations from that date.
- 21 October: fixed releases and advisory.
- 26 October: CISA added both CVEs to the Known Exploited Vulnerabilities catalog. It urges organisations to patch immediately and to take PHP 8.1-or-older systems offline until they are updated.
PHP lists configuration workarounds for people who cannot update at once, but says they “do not make an installation safe”. Its release notes are blunter: “There are no complete mitigations, updating is the only safe choice.”
Why a PHP bug is a cookie banner problem
On a WordPress site, the consent banner is not a separate system. It is a plugin, or a script tag in your theme, served by the same PHP process as everything else. That has three consequences if the server is compromised. These follow from what remote code execution means; we have not seen reports of PHP2Shell attacks targeting consent tools specifically.
1. The banner only blocks what the page lets it block. Prior blocking works because your page loads the consent manager first and the trackers only after a choice. An attacker who can change your files or your database can add a script above the banner, rewrite the Consent Mode default from denied to granted, or switch off the plugin’s blocking. The banner may still appear and still record clicks while the page underneath does something else. Visitors would not see a difference; a network capture would.
2. Consent records are personal data on that server. Many WordPress consent plugins keep a log of choices in your database, because GDPR Article 7(1) requires you to be able to demonstrate consent. If the server was compromised, those records may have been read or altered. A personal data breach has to be reported to the supervisory authority within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people (Article 33). Whether a given incident meets that bar is a question for your DPO or counsel.
3. Your “external” scripts run on someone else’s server. Every tag, widget and analytics script your page loads from another host reaches your visitors with your site’s authority. If that host is compromised, the code changes without anyone touching your site. This has happened: in June 2024 Sansec reported that the polyfill.io domain, bought by a new owner months earlier, was serving code that redirected mobile visitors, on a domain embedded by more than 100,000 sites. That case was not PHP. It shows how far one changed script travels. For PHP2Shell, the hosts to think about are the PHP ones you depend on:
- Self-hosted analytics. Matomo On-Premise runs on PHP (Matomo 6 requires PHP 8.1 or newer). If your
matomo.jscomes from your own analytics server, that server needs the patch too, even if your main site is not PHP. - Self-hosted consent or tag tools. Consent log endpoints, server-side tagging proxies and banner configuration files hosted on a PHP stack are part of the same exposure.
- Agency and partner servers. Scripts loaded from an agency’s or a partner’s domain are only as patched as that domain. Ask.
Large SaaS consent platforms serve their banner scripts from CDNs, and we have no information that any of them were affected. The point is not that every external script is at risk. It is that you should know which ones you load and who runs them.
What to do this week
- Check the PHP version actually running. In WordPress, go to Tools → Site Health → Info → Server. On shared hosting, your host’s panel usually has a PHP info page; ours showed 8.3.36, built on 20 October. You need 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later on your branch. On 8.1 or older, move to a supported branch: there is no official release for you.
- Restart PHP after updating. Tenable notes that installing new packages does not patch PHP workers that are already running. Managed hosts handle this; on your own server, restart PHP-FPM or Apache.
- Look back to 17 October. New administrator accounts, plugins you did not install, files changed in
wp-content(especiallymu-plugins), unknown cron jobs. Wiz suggests watching for multipart requests followed by memory-limit errors, bursts of HTTP 500s and unusually largePHPSESSIDcookies; CISA suggests PHP workers launching shells or downloading tools. - Re-check what your pages send before consent. Open your site in a clean browser profile, do not click the banner, and list every third-party domain in the Network panel. Compare it with what your consent setup is supposed to allow. A new domain you do not recognise is worth investigating. Our network-tab guide and pre-consent tracking checklist walk through it.
- Inventory your external scripts. Write down every host your pages load code from and who runs it. Patch the ones you own; ask about the ones you don’t. Where you can, limit allowed script hosts with a Content Security Policy.
One practical note from Tenable: PHP 8.4.27 and 8.5.12 can crash some applications that use SimpleXML (php-src issue #24488). If that hits you, the fix is the next patch release, not staying on a vulnerable one.
Nothing here is legal advice.
A compromised page usually shows up first as a request you did not expect. Scan your site and list every third-party request made before consent with CookieInspector, and keep the result as your baseline.