php2shell: Is Your Site Patched? A 2-Minute Check (No SSH Needed)

Q: What is php2shell?

Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Both let an attacker run code on a server without logging in. PHP rates both 9.2 on CVSS v4.0.

Q: My site shows PHP 8.1 or 7.4. Am I vulnerable?

Not necessarily. PHP itself doesn't release fixes for these branches any more, but many hosts and vendors patched them without changing the version number. Check the build date (21 October 2026 or later means patched) or your host's statement, then plan an upgrade, because the next fix may not come.

Q: My hosting panel shows "8.3". Does that mean I'm patched?

No. Panels usually show only the branch. You need the full version (8.3.36 or later) or the build date. The WordPress Site Health screen or a temporary phpinfo file shows them.

Q: I'm on Hostinger. Do I need to do anything?

Not on web, cloud or cPanel hosting. Hostinger says the fix was installed on every server except VPS by 22 October. To confirm, open PHP Info in hPanel and check the build date is 21 October 2026 or later. On a Hostinger VPS, you update PHP yourself.

Q: Does Cloudflare's free plan protect me from php2shell?

It blocks known attack patterns: Cloudflare's rules have been on by default for Free plans since 21 October. But a firewall isn't a patch, and Cloudflare itself tells customers to update PHP.

Q: Is WordPress vulnerable to php2shell?

The bug is in PHP, not WordPress, so any WordPress site on unpatched PHP is exposed, however well its plugins are written. WordPress says no WordPress update is required for it. A different bug, wp2shell, affected WordPress core in July 2026 and is fixed by updating WordPress.

Q: Will updating PHP break my site?

A patch release inside your branch (8.3.35 to 8.3.36) almost never breaks anything. Moving to a new branch (8.2 to 8.3) can upset old plugins or themes: update them first and take a backup.

Q: Are the PHP mitigations enough if I can't update yet?

No. PHP says they "reduce exposure to specific attack paths but do not make an installation safe". Use them only while you wait for the update.

Q: Has php2shell been exploited?

Security vendors including watchTowr and Amazon report exploitation attempts, and Amazon traced one back to 17 October, before the fix was public. That's why sites that were unpatched should be checked for signs of compromise, not just updated.

Q: Is it safe to leave a phpinfo.php file on my site?

No. It exposes your server's paths, modules and configuration, which helps attackers. Create it, read the version and build date, and delete it straight away.

Is your site patched against php2shell (CVE-2026-109618)? Why your PHP version can mislead, how to find the build date in cPanel, hPanel or WordPress.

October 26, 2026 Updated October 26, 2026

Dark terminal screen filled with green package-install log lines, photographed at an angle

This article contains affiliate links. If you purchase through these links, we may earn a commission at no extra cost to you. Learn more

Verified 26 October 2026 against php.net, the distributions' security notices and each host's own announcement.

Overview

On 21 October 2026 the PHP project shipped an emergency release for two flaws, nicknamed php2shell, that can let an attacker run code on a server without logging in. Both are rated 9.2 out of 10. If your website runs on PHP (WordPress, WooCommerce, Joomla, Drupal), is the PHP on your server fixed?

Many hosts installed the fix without changing the version number, so this guide gets you to a real answer with a panel, a WordPress login, or nothing at all.

Key Takeaways

Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything at or above those on its branch is patched.
Below those numbers you're not necessarily exposed: hosts and panel vendors backported the fix into older builds. The build date (21 October 2026 or later) is the check that works.
Eleven hosts and platforms published statements on their own pages, dated 21 to 23 October, including Hostinger, GoDaddy, Kinsta and SiteGround.
On a self-managed VPS, nobody patches PHP unless you do, and some older systems (Debian 11, Ubuntu 20.04 without Ubuntu Pro) got no free fix.
Cloudflare's firewall blocks known attack patterns on every plan, including Free, but Cloudflare itself says to patch anyway.
PHP 8.2 stops getting security fixes on 31 December 2026, so if you're on 8.2 or older, this is a good week to plan the upgrade.

Who this guide is for

Anyone with a PHP website: shared hosting customers who have never opened a terminal, WordPress site owners, freelancers who look after client sites, and people running their own VPS.

What happened, in one line

17 Oct
First exploit attempt seen
In Amazon's honeypots, four days before the patch. Amazon
20 Oct
PHP announces the release
Two critical flaws, both CVSS v4.0 9.2, release scheduled for 21 Oct at 14:00 UTC. php.net
21 Oct, 03:02 UTC
Cloudflare rules go live
About nine hours before public disclosure, on every plan with the WAF. Cloudflare
21 Oct
PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
The fixed releases ship.
21–23 Oct
Hosts roll out fixes
Statements dated 21 to 23 October (see the host list).
23 Oct
CVE-2026-115560 advisory
A third, narrower issue in session upload progress.
31 Dec
PHP 8.2 support ends
No security fixes for 8.2 after this date.

Check your site in 2 minutes

Nothing you type leaves your browser, and nothing here touches your site.

Step 1 of 3

Who runs PHP for your site?

This is a self-check, not a scan. It can only be as accurate as the version and build date you give it.

How to find your PHP version and build date (no SSH needed)

You need the full version (8.3.36, not "8.3") and, if it's below the fixed release, the build date. Most panels show only the branch. WordPress's own announcement points to Tools → Site Health → Info → Server.

Where do you log in? Tap one to see the steps.

This method shows: Full version: yes Build date: no

Log in to WordPress as an administrator.
Go to Tools → Site Health.
Open the Info tab and expand Server.
Read the "PHP version" line.

Works on any host, no hosting login needed. If the version is below the fixed release, use the phpinfo method or ask your host: Site Health can't show whether a backported build includes the fix.

Source: WordPress.org: Critical PHP Security Release

This method shows: Full version: may vary Build date: yes

Log in to hPanel.
Go to Websites → Dashboard for your site.
Search the sidebar for PHP Info and open it.
Read the PHP version at the top and the Build Date.

Hostinger: a Build Date of October 21, 2026 or later means your site has the fix (all plans except VPS).

Source: Hostinger: how to check the PHP version

This method shows: Full version: no Build date: no

Log in to cPanel.
In Software, open Select PHP Version (hosts running CloudLinux) or MultiPHP Manager.
Note the branch your site uses (for example 8.2).
For the full version and build date, use the phpinfo method.

Both screens show the branch, not the full version or the build date.

Source: cPanel docs: MultiPHP Manager

This method shows: Full version: may vary Build date: may vary

Log in to Plesk.
Go to Websites & Domains, find your domain, and click PHP.
To see the full version and build date, click "View the phpinfo() page" on that screen, or use the phpinfo file method.

Plesk's own advisory says that for PHP 7.4, 8.0 and 8.1 the version number stays the same and only a build dated 21 October 2026 carries the fix.

Source: Plesk docs: PHP Settings

This method shows: Full version: no Build date: no

Log in to DirectAdmin.
Open Domain Setup and select your domain.
Find the PHP version selector (only if your host enabled it) and note the branch.
For the build date, use the phpinfo method.

Source: DirectAdmin docs: multiple PHP versions

This method shows: Full version: yes Build date: yes

Open your host's File Manager (or FTP).
Go to your site's main folder, often public_html.
Create a file with a hard-to-guess name, like check-7f3a.php.
Put one line in it: <?php phpinfo();
Open https://yoursite.com/check-7f3a.php and read "PHP Version" and "Build Date" in the top table.
Delete the file straight away.

Careful. phpinfo shows server paths, modules and settings that help attackers. Never leave the file online.

This method shows: Full version: yes Build date: yes

Run php -v.
Read the version and the "built:" date.

The command-line PHP can be a different build from the one serving your site. Red Hat recommends a temporary phpinfo page over php -i for this reason.

Animated cartoon character peering closely at something through a magnifying glass

You, reading a version number that might not mean what it says. via GIPHY

Why the version number can be misleading

A backport copies a fix into older code and rebuilds it under the old version number. CloudLinux, Plesk, GoDaddy and Ubuntu 24.04 (still "8.3.6") all did it for this fix. So the same number can mean two different things:

Server A

Example phpinfo

PHP Version: 8.1.34 same
Build Date: Oct 21 2026 different

Patched

Built on or after 21 Oct 2026: a patched backport.

Server B

Example phpinfo

PHP Version: 8.1.34 same
Build Date: Oct 1 2026 different

Not patched

Built before the fix: not patched.

8.5.12, 8.4.27, 8.3.36, 8.2.35 or higher on that branch: Patched
A lower number with a build date of 21 Oct 2026 or later: Almost certainly a patched backport
A lower number with an older build date: Not patched: update or contact your host
A lower number and no build date available: Can't tell: your host's statement decides it

Scanners that only compare version numbers flag patched backports as vulnerable. If your host says you're patched and a scanner disagrees, the build date settles it.

What php2shell is, in plain terms

CVE-2026-109618

RCE via OOM corruption

When PHP runs out of memory part-way through setting up a request, it can be left holding half-built data, and the cleanup afterwards may treat that data as valid.

CVE-2026-109619

RCE via stale global state

Request data can outlive the memory behind it, and a later request handled by the same PHP worker may use that leftover state.

Highest risk: mod_php

PHP lists every setup that serves web requests as at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers mod_php (PHP inside Apache) the worst, with a demonstrated exploit that can fire "before any application code runs", so well-written plugins don't help.

Patched PHP versions by branch

PHP 8.5
Fixed in 8.5.12
Fixed
PHP 8.4
Fixed in 8.4.27
Fixed
PHP 8.3
Fixed in 8.3.36
Fixed
PHP 8.2
Fixed in 8.2.35
Security support ends 31 Dec 2026
Fixed
PHP 8.1, 8.0, 7.4
No official release
PHP published source-code backports only. Patched builds exist from distributions, hosts and panel vendors, usually with the old version number
Backports only
PHP 7.3 and older
Nothing from PHP
Some vendors patched anyway (CloudLinux and Hostinger cover back to 5.2). Treat as exposed unless your host confirms
Nothing from PHP

The first PHP release that fixes php2shell on each branch
PHP branch	Fixed release	Notes
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	Security support ends 31 Dec 2026
8.1, 8.0, 7.4	No official release	PHP published source-code backports only. Patched builds exist from distributions, hosts and panel vendors, usually with the old version number
7.3 and older	Nothing from PHP	Some vendors patched anyway (CloudLinux and Hostinger cover back to 5.2). Treat as exposed unless your host confirms

PHP: "PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version." Its security team also published source backports for 7.4, 8.0 and 8.1, with no binaries. PHP 8.6.0 RC4 (21 Oct) carries the fix too; 8.6 isn't released yet.

Did your host patch it?

Each card is read from the host's own page, with the date that page shows. A host that isn't listed may still have patched.

Find your host

Hostinger
Patched · 22 Oct
Fix installed on every hosting server except VPS (rollout finished 22 Oct, 06:44 UTC). Patched builds for PHP 5.2 to 8.5. Check: PHP Info → Build Date of 21 Oct or later.
Read statement
GoDaddy
Patched · 21–22 Oct
All PHP versions patched on Managed WordPress (21 Oct, 19:30 UTC), Windows Hosting (22 Oct, 01:20 UTC) and Web Hosting (22 Oct, 13:30 UTC). Patched builds keep the old version number, with a build date of 21 Oct or later. VPS customers update PHP themselves.
Read statement
Kinsta
Protected · 22 Oct
Sites protected, with security updates for PHP 7.4 through 8.5. No action needed.
Read statement
SiteGround
Patched · 22 Oct
"There's nothing you need to do." Fixes applied across all servers.
Read statement
Namecheap
Patched · 22 Oct
All PHP versions on Shared Hosting patched. PHP 5.2 to 8.1 keep their version numbers; 8.2 to 8.5 show the official fixed numbers. VPS and dedicated servers: you update PHP.
Read statement
WP Engine
Patched · 22 Oct
"All customer sites are running fully patched versions of PHP." No customer action needed. No version numbers or build date given.
Read statement
WordPress.com (Automattic)
Protected · 21 Oct
Sites on WordPress.com, WordPress VIP, WP Cloud, Pressable and Tumblr "are safe". Nothing to do.
Read statement
Cloudways
Patched · 22 Oct
Rollout complete 22 Oct (10:20 UTC): "all active servers have been successfully updated". Covers deprecated PHP versions too (5.6 and above).
Read statement
Pantheon
Patched · 21–22 Oct
Live sites on PHP 8.2 to 8.5 patched 21 Oct, then production sites on older LTS PHP versions. Pre-production environments finished 22 Oct; free sandboxes over the following 24 to 48 hours.
Read statement
OVHcloud (web hosting)
Patched · 21–23 Oct
Web hosting clusters: PHP 7.4 to 8.5 patched 21 Oct, PHP 5.3 to 7.3 patched 23 Oct. VPS and Bare Metal: you update PHP.
Read statement
Hosting.com (formerly A2 Hosting)
Patched · 22 Oct
cPanel/Plesk shared hosting and managed servers patched for PHP 5.2 and up. Check phpinfo(): the build date shows Oct 21st. Self-managed VPS: you update.
Read statement

Panel vendors many smaller hosts rely on

CloudLinux
Fixed alt-php 5.2 to 8.5 on CloudLinux 7, 8 and 9 (stable 22 Oct, 00:07 UTC) and ea-php52 to 85 on CloudLinux 7 to 10. Mostly backports with lower version numbers. CloudLinux 6 alt-php "not confirmed yet".
Their notice · updated 23 Oct 2026
Plesk
8.2 to 8.5 updated to 8.2.35, 8.3.36, 8.4.27 and 8.5.12. 7.4, 8.0 and 8.1 are fixed in builds dated 21 Oct 2026 with unchanged version numbers.
Their notice · updated 22 Oct 2026

Host not listed?

Check its status page or blog for "php2shell" or "CVE-2026-109618". If you find nothing, send them this:

Your domain

PHP version

Build date (optional)

Hi, about the PHP security release of 21 October 2026 (php2shell, CVE-2026-109618 and CVE-2026-109619): is the PHP running my site [your domain] patched? It shows PHP [your PHP version]. If it's a backported build that keeps the old version number, can you confirm the fix is included? Thanks.

If your host can't confirm, moving to a host that has confirmed is the other way out.

Running your own VPS? You patch it yourself

On a VPS nobody updates PHP for you, and Hostinger, GoDaddy, Namecheap, OVHcloud and Hosting.com all say so. What changes when you move from shared hosting to a VPS starts with this job. Pick your system:

Ubuntu 24.04 LTS · package php8.3

First fixed version

8.3.6-0ubuntu0.24.04.13

Source: USN-8948-1

Debian 12 (bookworm) · package php8.2

First fixed version

8.2.35-1~deb12u1

Source: DLA-4848-1

RHEL, AlmaLinux, Rocky 8, 9, 10 · package php module streams

Errata from 21 Oct; confirm with the changelog check

Source: RHSB-2026-013

Still on Debian 11, Ubuntu 20.04 without Ubuntu Pro, or CloudLinux 6?

Treat the server as exposed. Debian lists no fix for 11, Ubuntu's fix for 20.04 and older is Ubuntu Pro only, and CloudLinux 6 alt-php was "not confirmed yet" in its last update. Move the site to a supported system, or behind a host that patches for you.

1 Update
- Ubuntu, Debian
  sudo apt update && sudo apt upgrade
- RHEL family
  sudo dnf upgrade 'php*'
2 Restart PHP
- PHP-FPM (use your version)
  sudo systemctl restart php8.3-fpm
- mod_php
  sudo systemctl restart apache2
- cPanel (CloudLinux)
  /scripts/restartsrv_httpd
- cPanel (CloudLinux)
  /scripts/restartsrv_apache_php_fpm
Until PHP restarts, the old code keeps running. On RHEL-family systems with mod_php, restart httpd.
3 Confirm
- Debian-style
  dpkg -l | grep php
- RHEL family
  rpm -q php-cli
- Changelog, RHEL family (use your package)
  rpm -q --changelog php-cli | grep CVE-2026-10961
- Changelog, Debian-style (use your version)
  apt changelog php8.3-fpm | grep CVE-2026-1096
Compare the version with the one above.

Let your host handle the next PHP emergency

Not sure how to check, or your host won't answer? Hostinger moves a WordPress or Joomla site over from another host for free on its web and cloud plans, onto servers that had this fix by 22 October.

Hostinger web hosting

Web hosting where the host installs PHP fixes on the server for you

Free migration from another host, done by Hostinger's team
Fix installed across web, cloud and cPanel hosting by 22 October

$2.49/mo on a 48-month term, renews at $10.99/mo

Premium, Black Friday price until 14 December 2026, excl. VAT, checked 20 October 2026

See web hosting plans

What actually protects you

Three layers, and only one fixes the bug. The other two buy time while you wait for a host or a maintenance window. On shared hosting you usually can't change PHP settings, so the host message above is your move.

Cloudflare firewall

Blocks known attack patterns

On by default since 21 Oct, 03:02 UTC on every plan with the WAF, including Free. Pro, Business and Enterprise: check the Managed Ruleset is set to block.

Cloudflare's own advice is to patch PHP even with the rules on.
Its rule for the 23 Oct advisory only works if your site uses PHP's default upload progress field name.

PHP settings

Narrows some attack paths

PHP: they "reduce exposure to specific attack paths but do not make an installation safe".

session.upload_progress.enabled=0 in php.ini, a PHP-FPM pool or the server config, then restart every worker. ini_set() and .user.ini don't work for this.
memory_limit=-1 where applications can't override it, plus a low post_max_size (8M without uploads, 32M with) and upload_max_filesize below it.
On PHP 8.5 only: fatal_error_backtraces=0, then restart.

The patch

Fixes the bug

PHP's release posts: "There are no complete mitigations, updating is the only safe choice."

PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, or your host's or distro's backport (check the build date).

A firewall isn't a patch

Cloudflare's rules and PHP's settings stop attack patterns they recognise. Both leave the bug in PHP.

The 23 October advisory: CVE-2026-115560

A third, narrower issue in session upload progress. It only affects applications that set session.serialize_handler to php_binary or php_serialize and then switch it back to php at runtime, and PHP is handling it in its regular release cycle. If you or your host already set session.upload_progress.enabled=0 on 21 October, keep it and do nothing more. Hostinger says its non-VPS plans were already covered by its 21 October changes.

php2shell vs http2shell vs wp2shell

Three "2shell" bugs in one year. The names are nicknames; the CVE numbers are what the official notices use.

php2shell

CVE-2026-109618, CVE-2026-109619 · Oct 2026

Affected: PHP itself

Affects a typical PHP site?

Yes

This guide.

php.net advisory

http2shell

CVE-2026-111497 · Oct 2026

Affected: Google's Brotli decompression library (libbrotlidec 1.0.3 to 1.2.0; fixed in 1.0.10, 1.1.1 and 1.2.1), which Node.js uses and PHP's Windows builds bundled

Affects a typical PHP site?

Possibly

Through outbound requests. PHP's Windows builds were rebuilt on 26 Oct as 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1 (same PHP versions). PHP says the bug is reachable through the cURL extension when automatic response decompression is on, which is off by default but apps and HTTP libraries can enable it. On Linux it depends on your system's Brotli library being updated. Node.js users: update to 22.23.4, 24.22.1 or 26.12.1.

php.net entry, 26 Oct · Node.js security releases · Debian tracker

wp2shell

CVE-2026-63030 (with CVE-2026-60137) · Jul 2026

Affected: WordPress core

Affects a typical PHP site?

Only if WordPress isn't updated

Fixed in 6.9.5, 7.0.2 and later (6.8.6 for the first bug only).

WordPress 7.0.2 release

Was my site already attacked?

watchTowr observed exploitation in the wild from 21 October, and Amazon found an attempt in its honeypots dating to 17 October, so investigate from that date. As of 22 October, watchTowr noted that CISA had not added either CVE to its Known Exploited Vulnerabilities catalogue. If your site was unpatched at any point since 17 October, check for:

Signs checked0 / 4 signs completed

PHP files you didn't create

Especially in upload folders (wp-content/uploads on WordPress).

New administrator accounts

Files changed on dates you didn't change anything

Unusual outbound emails or a sudden traffic spike

Ask your host for a malware scan.
Restore from a backup taken before 17 October. Our guide to restoring a clean backup covers the order. No backup that old? That's the bigger problem to fix this week.
Change your hosting, database, FTP and admin passwords.

PHP 8.2 ends on 31 December 2026: plan the upgrade now

8.2.35 fixes php2shell, but the next bug after 31 December won't get an 8.2 fix, and newer PHP versions are also faster. Update WordPress, your theme and plugins, take a backup, then change the branch in your panel. Hostinger says hPanel lets you switch back within the same login session.

Animated cartoon character wiping their forehead in relief

The feeling when the build date says 21 October. via GIPHY

Frequently Asked Questions

What is php2shell?

Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Both let an attacker run code on a server without logging in. PHP rates both 9.2 on CVSS v4.0.

My site shows PHP 8.1 or 7.4. Am I vulnerable?

Not necessarily. PHP itself doesn't release fixes for these branches any more, but many hosts and vendors patched them without changing the version number. Check the build date (21 October 2026 or later means patched) or your host's statement, then plan an upgrade, because the next fix may not come.

My hosting panel shows "8.3". Does that mean I'm patched?

No. Panels usually show only the branch. You need the full version (8.3.36 or later) or the build date. The WordPress Site Health screen or a temporary phpinfo file shows them.

I'm on Hostinger. Do I need to do anything?

Not on web, cloud or cPanel hosting. Hostinger says the fix was installed on every server except VPS by 22 October. To confirm, open PHP Info in hPanel and check the build date is 21 October 2026 or later. On a Hostinger VPS, you update PHP yourself.

Does Cloudflare's free plan protect me from php2shell?

It blocks known attack patterns: Cloudflare's rules have been on by default for Free plans since 21 October. But a firewall isn't a patch, and Cloudflare itself tells customers to update PHP.

Is WordPress vulnerable to php2shell?

The bug is in PHP, not WordPress, so any WordPress site on unpatched PHP is exposed, however well its plugins are written. WordPress says no WordPress update is required for it. A different bug, wp2shell, affected WordPress core in July 2026 and is fixed by updating WordPress.

Will updating PHP break my site?

A patch release inside your branch (8.3.35 to 8.3.36) almost never breaks anything. Moving to a new branch (8.2 to 8.3) can upset old plugins or themes: update them first and take a backup.

Are the PHP mitigations enough if I can't update yet?

No. PHP says they "reduce exposure to specific attack paths but do not make an installation safe". Use them only while you wait for the update.

Has php2shell been exploited?

Security vendors including watchTowr and Amazon report exploitation attempts, and Amazon traced one back to 17 October, before the fix was public. That's why sites that were unpatched should be checked for signs of compromise, not just updated.

Is it safe to leave a phpinfo.php file on my site?

No. It exposes your server's paths, modules and configuration, which helps attackers. Create it, read the version and build date, and delete it straight away.

Final Thoughts

On a plan from one of the hosts above, this has most likely been handled, often without changing the version number. Confirm it with the build date, then use the moment to get off PHP 8.2 or older.

If you run your own server, it's on you: update, restart, confirm. If that's a job you'd rather not have next time, that's what choosing hosting that maintains the server for you is for.

Web Hosting WordPress Security Troubleshooting Self-Hosting