On October 21, 2026, the PHP project released fixes for a flaw now called PHP2Shell (CVE-2026-109618 and CVE-2026-109619). It sits in PHP itself, the language behind WordPress, Drupal, Joomla, Magento and many custom sites. An unpatched server can let someone run their own code on it through a file upload request, before your site's login checks ever run.
The fix is a PHP update, and for most sites it is a setting at your host, not a rebuild. This guide covers:
- •Whether your site is affected
- •How to find your PHP version on your platform
- •Which version to move to
- •What to do if you cannot update yet
- •How to check whether anyone tried it
Full disclosure: Stackra's website scan now checks for this, so we have a stake in the topic. The steps below work without us, and every one of them points to the official source.
Is your site affected?
If your site runs on PHP and your server has not been updated since October 21, assume it needs the update. Amazon's threat intelligence team saw the flaw being used from October 17, before it was public.
- •Likely affected: self-hosted WordPress, WooCommerce, Drupal, Joomla, Magento, PrestaShop, OpenCart, and custom PHP sites (Laravel, CodeIgniter, CakePHP).
- •Your host handles it: Wix, Squarespace, Shopify, Webflow and other website builders run the servers for you.
- •Managed WordPress hosting providers typically manage PHP security updates. If you use WP Engine, Kinsta, Pantheon, WordPress VIP or a similar provider, check their security announcements or contact support to confirm your installation has received the PHP2Shell fix.
- •Not affected by this flaw: sites that do not run PHP at all.
- •Updating WordPress, your theme or your plugins does not fix it. The flaws are in PHP itself, so the fix is a PHP update on the server.
Step 1: Find your PHP version
Most platforms show the PHP version in the admin area. If yours does not, your hosting control panel or your host's support team can tell you.
- •WordPress: Tools > Site Health > Info, then open Server.
- •Drupal: Reports > Status report.
- •Joomla: System > Information Panel > System Information.
- •Magento, Laravel and other custom builds: ask your developer.
- •cPanel hosting: MultiPHP Manager shows the version for each domain.
- •Plesk hosting: Websites & Domains, then PHP.
Step 2: Move to a fixed version
Each supported PHP line has its own fixed release. Stay on your line and update to at least its fixed version, or move up a line.
| Your PHP line | Update to at least |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1 or older | No new official PHP release is available. Upgrade to a supported PHP version, preferably 8.3 or newer where compatible, or confirm your hosting provider has applied a vendor-maintained security backport. |
Fixed releases published October 21, 2026. PHP 8.2 stops receiving security fixes on December 31, 2026, so 8.3 or newer is the better target.
Before you change PHP, check your platform
A PHP update is usually safe, but your platform has its own limits. Back up the site first.
- •WordPress recommends PHP 8.3 or newer. Update your plugins and theme before you switch, then check the site.
- •Drupal 11 needs PHP 8.3 or newer. Drupal 10 runs on PHP 8.1 to 8.4.
- •Joomla 6 needs PHP 8.3 or newer.
- •Magento 2.4.6 supports only PHP 8.1 and 8.2. If you are on 8.1, the store needs Magento 2.4.7 or newer before PHP can move up.
- •Laravel 12 needs PHP 8.2 or newer.
Step 3: If you cannot update yet
If you cannot update immediately, contact your host or developer. Disabling PHP session upload progress (session.upload_progress.enabled=0) reduces exposure to one confirmed attack path, but it does not mitigate both PHP2Shell vulnerabilities. Additional configuration changes and firewall protections may reduce risk. These are temporary measures, not substitutes for installing a fixed PHP release.
- •Restricting uploads your site does not need, and limiting upload sizes, can also reduce exposure. Like the setting above, this does not replace the PHP fix.
- •Cloudflare deployed PHP2Shell WAF protections on October 21, 2026, including coverage for customers using its Free WAF ruleset. If your site uses Cloudflare, confirm the relevant protections are enabled (on paid plans, check that the Managed Ruleset is in block mode). Firewall protection provides an additional security layer, but updating PHP remains necessary.
Only a fixed PHP release closes both vulnerabilities. Plan the update anyway.
The out-of-memory flaw. Updating is the only complete mitigation.
The request-state flaw, including what the upload progress setting does and does not cover.
Which plans are covered and what paid plans should check.
Step 4: Check whether anyone tried it
Amazon published what to look for: POST requests containing PHP_SESSION_UPLOAD_PROGRESS, from October 17 on. Standard web server logs often do not record request contents, so ask your host or firewall provider to check theirs. If anything turns up, also ask them to look for unexpected files or processes on the server.
- •If your site uses Cloudflare, Security > Security Analytics > Events shows requests its PHP2Shell rules matched and blocked. Filter by the managed rules to see them.
The absence of PHP_SESSION_UPLOAD_PROGRESS in your logs does not prove your site was not targeted. Ask your host to review suspicious multipart requests, unusual PHP errors, unexpected process execution and recently modified files.
Step 5: Stop announcing your version
Many servers announce their exact PHP version in a response header. Once you are updated, ask your host or developer to set expose_php to Off. It does not fix anything on its own, but it stops advertising which version you run.
How the Stackra scan checks this
Our website scan reads the PHP version your server announces in its own responses during the scan. It never sends anything that resembles an attack. Server-reported PHP versions are indicators, not definitive vulnerability tests: hosting providers may backport security patches without changing the reported version, and some servers hide or modify version headers. Stackra flags potential exposure and recommends verification with your hosting provider. If the version is from before the fix, the report says so and lists these steps. If your server hides its version, the report asks you to check with your host, and it never calls a site safe or unsafe on a guess. The check is not part of your score. We show the version only on sites you've verified you own in Google Search Console or Bing Webmaster Tools, so the scan can't be used to look up someone else's server.