PHP2Shell: What the Critical PHP Vulnerability Means for Your Website

PHP2Shell is the name for two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, that can let someone run their own code on a web server without logging in. PHP fixed them on 21 October 2026. Because the problem is in PHP rather than in WordPress, this PHP vulnerability affects WordPress sites whatever plugins or theme they use.

First we'll explain it simply: what happened, whether your site is affected, and what to do today. If you run servers or write code, the technical details come after that: the root causes, the temporary settings PHP suggests, and how to confirm a server is patched.

What is PHP2Shell, and why does it matter?

PHP is the engine your website runs on, and PHP2Shell is a fault in that engine. WordPress, Drupal, Joomla and many shops are written in PHP. Every time someone visits a page, PHP on your server reads their request and runs the code that builds the page.

The two flaws sit in the part of PHP that reads incoming requests. A carefully built request can confuse PHP's memory handling and, in the worst case, make the server run the attacker's code. That's what the "shell" in the name means: control of the server, not just one website.

No password or account is needed for the attack. That's why both flaws are rated 9.2 out of 10 (critical). The researchers who found them, from Wiz, OpenAI and the security firm Calif, say on the PHP2Shell site that they used WordPress, Drupal and Joomla only as test targets: "Exploitation does not require one of those applications."

Is my website affected by PHP2Shell?

If your site runs on PHP and the server hasn't been updated since 21 October 2026, assume it's affected. PHP's own security advisory says the risk covers "all PHP installations serving web requests", whichever way the server runs PHP.

What matters is your PHP version. Here's where each one stands:

A lot of WordPress sites are in the bottom two rows. WordPress.org's PHP version statistics, which we checked on 23 October 2026, show about 35% of WordPress sites on PHP 8.1 or older. PHP 7.4 alone is 15.5% of sites, and 8.1 is 10%.

The wider web looks similar. CybelAngel, citing Shodan counts published on 20 October 2026, reports about 2.24 million internet-facing servers advertising PHP. Of those that show a version, 59% run a branch with no official fix coming. Those are servers, not websites, and many hide their version, so treat it as a rough picture.

How to check your PHP version in WordPress

WordPress shows your PHP version in Site Health, no plugin needed. In your dashboard, go to Tools › Site Health, open the Info tab and expand Server. The "PHP version" line shows the exact number, such as 8.3.36.

On our own local test site, it shows 8.2.29. That's older than the fixed 8.2.35, so that server needs updating.

One catch: if your host runs Debian, Ubuntu, Red Hat or similar, they may have patched an older-looking number like 8.2.20 without changing it. So a "low" number isn't proof you're exposed, and only your host can confirm. The technical section below shows how they can check.

What should I do about PHP2Shell today?

Updating WordPress, your theme or your plugins does not fix PHP2Shell. Keep doing those updates, but this one lives on the server. Here's the short list:

1. Note your PHP version from Site Health.
2. Check your host's status page or blog. Many hosts have already patched. Automattic, for example, says sites on WordPress.com, WordPress VIP, WP Cloud and Pressable are "already protected". Hostinger says it has patched every plan except VPS, where you manage PHP yourself.
3. If you can't find an answer, ask. Open a support ticket. A message you can copy is below.
4. If you run your own server or VPS, update PHP from your distribution's packages or php.net, then restart PHP-FPM or Apache so the new version actually loads.
5. If you're on PHP 8.1 or older, ask whether a backported fix was applied, and put a PHP upgrade on this month's list either way.

If you look after client sites, check by host rather than by site. One answer from each hosting company usually covers every client on it. Chase clients on cheap, unmanaged or forgotten hosting first, especially anything still on PHP 7.4.

If a client asks what happened, our guide to explaining security problems to clients covers what to tell them.

Should I panic about PHP2Shell?

No, but don't leave it for next month. The facts so far point both ways, and both are worth knowing.

• Attempts are real. Amazon's threat intelligence team saw an exploit attempt on 17 October, four days before the announcement, and says PHP2Shell "is now seeing broad exploitation attempts in the wild".
• Success isn't confirmed. Amazon adds that "it's unclear if any of these attempts would have succeeded in real-world systems."
• The public exploits are picky. The security firm Sansec says they need specific knowledge of the target server and "do not work against a default PHP installation", and by 22 October it judged mass exploitation less likely.

Developers aren't treating it lightly, though. In the Hacker News discussion of the Wiz write-up, one commenter called it "worse than Log4Shell", the 2021 Java flaw that kept IT teams busy for months. That comparison is about how widely PHP is used, not about attacks seen so far.

Is my site already hacked? Probably not, but it's a fair question. If something looks off (new admin users, files you don't recognise, strange redirects), our guide to the signs your site has malware lists what to check, and what a webshell is explains the backdoor attackers usually leave behind.

PHP2Shell technical details (CVE-2026-109618 and CVE-2026-109619)

This section is for developers and server admins. Everything here comes from PHP's advisory and the two GitHub security advisories unless a different source is named.

The two vulnerabilities

Both are memory-safety bugs triggered before application code runs. Sansec describes them as use-after-free bugs: a fatal error, typically a request crossing memory_limit, interrupts PHP before cleanup, and a later request or reused worker reads freed memory. It says the first involves the upload-progress unserializer and the second the fatal-error backtrace plus OPcache type confusion.

Sansec also reports that CVE-2026-109618 can leak server memory in the PHPSESSID cookie, even if the application never calls session_start(). That memory "can contain passwords, session tokens, API keys and TLS private keys from other requests". If an unpatched server faced the internet, consider rotating secrets after patching.

Which server setups are affected

PHP lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers mod_php the highest risk, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." Sansec says the vulnerable code goes back to PHP 5.4.0 and that the triggers are multipart/form-data requests, which PHP parses before your code starts.

That's also why an application-level firewall, including a WordPress security plugin like ours at SecurynAI, can't reliably stop it: by the time WordPress loads, PHP has already parsed the request. Filtering has to happen in front of PHP, at a CDN, a server firewall or the web server itself.

Temporary mitigations if you can't update yet

PHP is blunt here: "There are no complete mitigations, updating is the only safe choice." Its advisory lists these settings for servers that can't update immediately, and says they "do not make an installation safe":

• CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, an FPM pool or server config that applies before request parsing, then restart every worker. Don't rely on ini_set() or FPM .user.ini.
• CVE-2026-109618: set memory_limit=-1, ideally via php_admin_value, and keep post_max_size small (8M with no uploads, 32M if uploads are needed), with upload_max_filesize below it. Don't use RLIMIT_AS or RLIMIT_DATA instead.
• PHP 8.5 only: set fatal_error_backtraces=0 and restart every worker.

Removing the memory limit has a cost: Sansec points out that one request can then use all of the server's memory. Its other stopgap, blocking multipart/form-data at the web server, breaks file uploads and some checkout forms, so test an order afterwards.

Cloudflare has added WAF rules for known exploit patterns on all plans, free included, while still telling customers to patch. All of these buy time, not safety.

On 23 October, PHP added a follow-up: keep session.upload_progress.enabled=0 until the next regular release, to close an "unlikely" related path (CVE-2026-115560) that only affects apps switching the session serializer at runtime.

PHP 8.1, 8.0 and 7.4

The PHP project ships no release for 8.1 or older, but it did publish minimal source backports for 7.4, 8.0 and 8.1. Distributions and LTS vendors got the patches in advance. One developer's write-up on patching PHP 7.4 in a container shows it can be done, but an upgrade to a supported branch is the lasting fix.

How to confirm a server is patched

Check the package changelog, not just the version number. Distribution packages often keep an older upstream version and add the fix. Sansec suggests searching the changelog for the CVE, for example:

# Debian / Ubuntu
zgrep -i "CVE-2026-109618" /usr/share/doc/php8.2*/changelog.Debian.gz

# RHEL, AlmaLinux, Rocky
rpm -q --changelog php-common | grep -i "CVE-2026-109618"

Then confirm the web server actually runs the patched build: restart PHP-FPM or Apache and check the version from a request, not just php -v on the command line, which can be a different binary. A frequent question in the same Hacker News thread was where to find "a reputable source for code which can be used to validate fixes". OpenAI's php2shell-checker sends no exploit probes; it compares the PHP version a site advertises with the fixed releases. It can't see backported fixes, so treat its answer as a hint, and only check sites you own or may test.

How PHP2Shell unfolded

The fix was planned, but the details leaked a day early. Sansec's timeline has Calif reporting the first bug to PHP on 11 August and Wiz Research reporting on 24 August. Details leaked on 20 October, attack attempts started before the release, and PHP published fixed versions at 14:00 UTC on 21 October.

The researchers also say AI models helped. The PHP2Shell site credits frontier models with helping "work through complex exploit chains" during discovery and patch validation. Expect more bugs in old, widely used code to be found this way, which is one more reason to keep servers on supported versions.

PHP2Shell FAQ

Does updating WordPress fix PHP2Shell?

No. The flaws are in PHP, the software your server uses to run WordPress, so only a fixed PHP version closes them. Updating WordPress, plugins and themes is still good practice, it just doesn't touch this. Our automatic updates guide covers that side.

Can a WordPress security plugin block PHP2Shell?

Not reliably. PHP reads and processes the incoming request before WordPress or any plugin loads, which is where these bugs sit. Firewalls in front of the server, like the rules Cloudflare and some hosts have added, can filter known attack patterns, but PHP says only updating is a complete fix.

My site runs PHP 7.4. What now?

The PHP project won't release a fixed 7.4. Your host or Linux distribution may have backported the fix, so ask them directly. If they haven't, moving to PHP 8.2 or newer fixes this and gets you back on versions that receive security fixes. Test the upgrade on a copy of the site first.

Has PHP2Shell been used to hack websites?

Attack attempts are real and widespread: Amazon saw one four days before the public announcement, and many more on release day. As of 23 October 2026, no successful compromise has been publicly confirmed, and researchers say the public exploits don't work against a default PHP setup.

We'll update this post as PHP, hosts and researchers publish more. If you only do one thing today, check your PHP version in Site Health and get a yes or no from your host.