Check your exposure
Am I Affected by PHP2Shell? Find Your PHP Version and Read the Result
Quick question: which version of PHP runs your website? Most owners have never seen the number, and this week it decides almost everything. Here is where it hides, which numbers are safe, and what to do when yours is not.
October 23, 2026 · 9 min read
The short answer
You are affected if your site runs PHP below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on those branches, or PHP 8.1 or older without a vendor backport. Find the version in your hosting control panel, in WordPress under Tools > Site Health > Info > Server, or with php -v over SSH. Sites without PHP are not affected.
On this page
The two facts that settle it
Start with the plain version. PHP2Shell is a flaw in PHP, the language under most WordPress, Drupal, Joomla, WooCommerce and Magento sites. The PHP project fixed it on October 21, 2026. So the question is not whether your site is well built or your plugins are current. It is whether the PHP answering your visitors is a build from before that fix or after it, and whether PHP answers web requests on your site at all.
The two facts you need are the version (for example 8.3.36) and the SAPI, the way PHP is wired to the web server: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. The PHP project lists all of them as at risk and rates mod_php highest, because there an unauthenticated request can trigger the attack before any of your code runs. The version decides whether you are exposed. The SAPI decides how much of your evening this takes.
Five places the version number hides
You do not need a developer for the first three. Pick whichever you can reach fastest. If two methods disagree, believe the one closest to the live website, because a server can hold more than one PHP and only one of them is serving your pages.
- 1
Look in the hosting control panel
In cPanel, open MultiPHP Manager. In Plesk, check the PHP version shown on each domain's card. Both tell you the branch each site uses. A branch is not a build, so take this as the first clue rather than the verdict.
- 2
Ask WordPress Site Health
In the WordPress dashboard, go to Tools > Site Health > Info and open the Server section. It lists the PHP version and the PHP SAPI for the exact site you are logged into, which makes it the easiest honest answer an owner can get.
- 3
Upload a phpinfo file, read it, delete it
A one-line file containing `<?php phpinfo();` shows the full PHP version, the Server API and every setting. Open it once in a browser, write down the numbers, then delete the file. Left behind, it is a free map of your server for anyone who stumbles on it.
- 4
Run php -v and php-fpm -v over SSH
`php -v` reports the command-line PHP, which may not be the one serving the site. On Debian and Ubuntu the FPM binary carries its branch in its name, so `php-fpm8.3 -v` (or whichever branch you run) shows the build behind the website.
- 5
Read the package changelog for backports
If PHP came from your Linux distribution, the version string can look old while the fix sits inside. Look up CVE-2026-109618 and CVE-2026-109619 in the distribution's security tracker and compare its fixed package version with the one installed.
Why the response header makes a poor witness
Some guides send you to the `X-Powered-By` header in the browser's developer tools, which may announce something like PHP/8.3.12. Do not close the case there. Many servers turn that header off with the `expose_php` setting, some proxies and CDNs remove it, and a distribution's backported build reports the version it shipped with rather than the fix it carries. Even a correct header only describes the PHP behind the one page you loaded, not every site on the account.
Outside scanners share the same blind spot. Our free website health check is a quick outside look at security, speed, search visibility and on-page basics, with a plain-English fix for each failed check. It is useful, and it is not a PHP2Shell scanner: it cannot read a version that a server hides. Only a look from the inside, through the panel, WordPress or a shell, settles the question.
From the number you found to the thing you do
Find your row. The fixed releases came out on October 21, 2026, one per supported branch, so the comparison is always against your own branch. A site on 8.4 needs 8.4.27, not a leap to 8.5.
| Version you found | Status | What to do |
|---|---|---|
| 8.5.12 or later | Fixed | Stay current; if the site ran an older 8.5 after October 21, run the compromise check |
| 8.5.0 to 8.5.11 | Vulnerable | Update to 8.5.12 today |
| 8.4.27 or later | Fixed | No PHP2Shell work left on this branch |
| 8.4.0 to 8.4.26 | Vulnerable | Update to 8.4.27 today |
| 8.3.36 or later | Fixed | Nothing urgent; keep taking the regular releases |
| 8.3.0 to 8.3.35 | Vulnerable | Update to 8.3.36 today |
| 8.2.35 | Fixed, until December 31, 2026 | Plan the move to 8.3 or 8.4 before PHP 8.2 reaches end of life |
| 8.2.0 to 8.2.34 | Vulnerable | Update to 8.2.35, then plan the next branch |
| 8.1, 8.0 or 7.4 from your Linux distribution | Possibly fixed | Check the distribution's tracker for both CVE IDs; trust the tracker, not the number |
| 8.1, 8.0 or 7.4 from anywhere else | Vulnerable unless someone applied the source patch | Upgrade, or get a vendor backport confirmed in writing; see PHP past end of life |
| 7.3 or older | Vulnerable | Upgrade; Wiz traced the flaws back to 5.4 and there is no patch to apply |
| No PHP at all | Not affected | Nothing to patch; see the section below |
Who runs your server?
The answer decides who installs the fix and how long it takes.
Shared hosting
Your host builds PHP. Ask for 8.2.35, 8.3.36, 8.4.27 or 8.5.12, in writing, then pick it in the control panel.
Managed WordPress host
The host patches the platform. Get written confirmation of the PHP build your site runs on.
Your own server (VPS)
Update the PHP packages, then restart PHP-FPM or Apache so no worker keeps the old code.
Docker or containers
Rebuild the image on a patched PHP base and redeploy. The old image keeps the old PHP.
Then check for compromise
A patch closes the door. It does not tell you whether someone came in before you closed it.
Distribution packages that look old and are not
This is the row that confuses careful people. Debian, Ubuntu, Red Hat, AlmaLinux and Rocky backport security fixes into their own package versions instead of jumping to the PHP project's new release. A server can report a version below 8.3.36 and be patched, because the distribution moved the fix into its own build. The reverse is just as possible: a familiar number from a package nobody has updated since September.
So check by CVE ID. As of October 23, 2026, Debian's tracker entry for CVE-2026-109618 listed fixed php8.2 and php8.4 packages for its bookworm and trixie releases, and Ubuntu's CVE page listed fixes across its releases, including php8.1 on 22.04 LTS, a branch the PHP project no longer releases. Red Hat, AlmaLinux and Rocky publish their own advisories. Compare the fixed package version there with the installed one (`dpkg -l` or `rpm -q`), then repeat for CVE-2026-109619.
If you run the server yourself and the tracker says you are behind, the update, the PHP-FPM restart and the container rebuild are covered in patching a VPS or Docker setup. An old container image keeps its old PHP no matter how current the host underneath it is, which surprises more people than it should.
Sites with no PHP for the bug to reach
Some readers can close this tab. PHP2Shell needs PHP answering web requests. A static site made of plain HTML files has none. A Next.js site on Vercel serves pre-rendered pages and runs any server code in JavaScript, not PHP. Shopify, Squarespace and Wix are hosted platforms that do not run customer PHP code, so there is no PHP of yours on them to patch; whatever their own infrastructure runs is theirs to maintain.
Before you relax, walk the edges of the business's web presence. The main site is rarely the only thing with your name on it, and the forgotten pieces are usually the ones running PHP:
- A blog on a subdomain, or in a /blog folder, that still runs WordPress
- An old landing page, client portal or form script someone put on separate hosting years ago
- A staging or development copy of the site that is still reachable from the internet
- A second domain on the same hosting account, quietly sharing the same PHP build
None of this makes a site invulnerable. It means this particular bug has nothing to talk to. The wider comparison of attack surface sits in WordPress vs Next.js security.
Found an old number? The next hour
If your row said vulnerable, the order of work is the same for everyone: update, mitigate only if the update has to wait, then look for signs of a visit. Where the paths split is who runs the server.
Shared hosting
The host installs the fixed build; you choose it per site and get confirmation in writing. The cPanel and Plesk walkthrough.
Your own server or containers
Update the packages, restart PHP-FPM or Apache, rebuild and redeploy images. VPS and Docker steps.
Stuck for a day or two
Turn off session upload progress and cap request sizes where applications cannot override them. The interim settings.
Rather hand it off
DataCram updates PHP, tests the site and checks for compromise. The PHP2Shell emergency fix, with fixed prices for WordPress sites.
On WordPress, the update is where old themes and page builders tend to fail. If yours does, a site that broke after a PHP update is a $249 fixed-price repair, paid on the page: back online first, then the cause. And if you are wondering why updating WordPress itself did not help, the WordPress, Drupal and Joomla page explains the floor beneath the CMS.
Questions owners ask about PHP2Shell
Use the hosting control panel (MultiPHP Manager in cPanel, the domain card in Plesk) or, on WordPress, Tools > Site Health > Info > Server. For the exact build, upload a file containing a phpinfo() call, open it once, note the version and Server API, and delete it straight away. A forgotten phpinfo file is a gift to anyone mapping your server.
Yes. Wiz says the flaws reach back to PHP 5.4, and PHP 7.4, 8.0 and 8.1 get no new release from the PHP project. The project did publish source patches for those three branches, and some distributions and LTS vendors ship backported packages. Unless one of those covers your server, plan the upgrade. PHP past end of life lays out the options.
Not for the store or site itself. These platforms do not run customer PHP code, so there is nothing of yours to patch. Check the side doors, though: a WordPress blog on a subdomain, an old landing page on separate hosting, or a form script added years ago. Each of those runs PHP and needs the same version check as any other PHP site.
No. Many servers hide it, some proxies strip it, and a distribution's patched package can report an older-looking number. Treat it as a hint at most. The control panel, WordPress Site Health, a phpinfo file or `php -v` on the server tell you far more, and the distribution's security tracker settles the backport question by CVE ID.
Not reliably. From outside, a scanner sees only what the server chooses to show, and many servers show nothing about PHP. Our website health check is a quick outside look at security, speed and search basics, not a PHP2Shell test. The version check from inside the account is the one that counts. If the site will not load at all, check whether it is down first.
Not necessarily. As of October 22, attack attempts were under way but confirmed compromises had not been publicly reported, and exploitation depends on chaining bugs and on how a server reuses its workers. That can change any day. Patch first, then look for memory-limit errors, repeated 500 responses and unexplained worker restarts. If anything looks off, our malware removal and security service takes it from there.
Keep reading
- Emergency servicePHP2Shell Emergency Fix: We Patch Your PHP, Test the Site and Check for IntrudersWe update PHP to a fixed release, test every page, check for signs of a break-in and clean up if needed. WordPress fixes from $249, paid on the page.
- The long-term fixNobody Can Exploit PHP on a Site That Does Not Run It: The Next.js Way Out of PHP2ShellKeep WordPress private behind a Next.js front end, or drop PHP for Athena CMS. What each removes, what carries over, the honest limits and the prices.
- CMS owners' briefingPHP2Shell on WordPress, Drupal and Joomla: Your CMS Is Current. Is Your PHP?Why a fully updated WordPress, Drupal or Joomla site can still fall to PHP2Shell, why security plugins cannot fix it, and what to update first.
- Incident checkPHP2Shell Signs of Compromise: How to Tell Whether Anyone Got InThe published warning signs of a PHP2Shell attack, where to find them in logs and files, and what to do if you find one: evidence, new keys, a clean rebuild.
- Unsupported versionsEnd-of-Life PHP and PHP2Shell: What to Do When No Fix Is ComingPHP 8.1 and older get no PHP2Shell release. What the PHP project offers instead, how distribution backports work, and the three ways off old PHP.
- Shared hostingPatching PHP2Shell on Shared Hosting: cPanel, Plesk and Managed WordPressOn shared hosting your host patches PHP for PHP2Shell. How to confirm it in cPanel or Plesk, what to ask for in writing, and what breaks on newer PHP.
- Everything in PHP2ShellSee the section
Not sure what you found? Send us the number
Tell us the PHP version and the host, or just the site address. We tell you whether it is patched, what to do next and what it costs, before any work starts.
Which of these sounds like you? (pick any)
Rather talk now? Call (210) 346-0848.