PHP2Shell: What the Critical PHP Vulnerability Means for Your Online Store, and How to Fix It

Quick answer: On 21 October 2026, the PHP project released emergency fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. They let an attacker with no account and no password run their own code on a web server that uses PHP. The bugs are in PHP itself, so the vulnerable part runs before WooCommerce, Magento or any other store code. No plugin update, theme fix or Magento patch closes them. To fix it, update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to a distribution package that includes the fix. Then restart every PHP process and check that your web server is running the new version. If you cannot do that today, the US NSA and the UK's National Cyber Security Centre both advise taking the system offline until you can.

This guide is for people who run, build or look after online stores. It covers what happened, why stores are particularly exposed, how to check your own setup, how to fix it (or protect yourself until you can), and how to tell whether someone got in before you patched.

Part 1: What Happened

Two flaws in PHP itself

Most security warnings store owners see are about a specific plugin, theme or extension. This one is different. Both flaws are memory-safety bugs in how the PHP engine handles errors partway through a web request. If a request ends abnormally, for example because it ran out of memory, PHP can leave parts of its internal memory in a bad state. Researchers showed that an attacker can exploit this to read data from the server's memory and to run their own code.

Three things make this unusually serious:

1. It sits below your application. Wiz Research, one of the teams that found the flaws, says exploitation doesn't depend on the application: even a basic "Hello World" page on an affected PHP version can be vulnerable. Sansec, which specialises in e-commerce security, put it bluntly: "You cannot fix PHP2Shell from within your store code."
2. It is old. The vulnerable code goes back to PHP 5.4, released in 2012, according to Wiz and Sansec. The official CVE records list affected versions only for the currently supported 8.2 to 8.5 branches. Older branches no longer get official fixes, so they are not listed.
3. It is everywhere. PHP runs roughly 70% of websites (Wiz's estimate). Sansec reports that researchers confirmed unauthenticated code execution on Magento 2.4.9, WordPress 7.1.2, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS.

How it came to light

The day the websites went dark

The BBC's live coverage described something rarely seen for a software bug: well-resourced organisations switching their own websites off rather than risk staying online unpatched.

• Finland's state IT provider, Valtori, took central government public web services offline as a precaution.
• In the Netherlands, the National Cyber Security Centre took down its own site. The government portal Overheid.nl, the Port of Rotterdam, the House of Representatives (Tweede Kamer), the national public health institute (RIVM) and the five largest political parties followed.
• The Wikimedia Foundation took several systems down, so some people could not reach parts of Wikipedia.
• Edinburgh council's website went dark.
• The BBC switched off some of its own programme pages, including Doctor Who and The Traitors.

The official advice was blunt. The NSA told organisations that could not update immediately to take systems offline, warning that "these vulnerabilities often provide a direct path to the server's file system or database." The UK NCSC told organisations that could not fix the issue immediately to "consider taking the system offline."

These organisations have security teams, and they still chose downtime over the risk. A store owner should take that as a signal.

Is it being exploited?

Reports conflict, and it is worth being precise about who saw what:

• Amazon recorded an exploitation attempt on 17 October, before public disclosure.
• Cloudflare reported attack traffic against its customers, including attackers modifying their requests to try to slip past the new rules. Sansec cites Cloudflare as seeing early attacks at 07:43 UTC on 21 October, hours before the patch.
• watchTowr reported exploitation attempts against both CVEs in its honeypot network.
• Huntress said it had not seen exploitation on its partners' systems as of 4:30 pm ET on 21 October, and CISA said it had not observed exploitation when it issued its alert. Neither CVE was in CISA's Known Exploited Vulnerabilities catalogue as of 22 October.

Plan as if your store is a target. The details leaked before the patch, the patch itself is now public for anyone to study, and working attacks have been demonstrated against Magento and WordPress. Sansec predicted mass exploitation within minutes of the patch release. Whether automated attacks reach your store is not the question; the timing is.

Part 2: Why Online Stores Are Especially Exposed

Most self-hosted e-commerce runs on PHP

WooCommerce (on WordPress), Magento and Adobe Commerce, Shopware, PrestaShop and OpenCart all run on PHP. If you host your own store on any of them, PHP2Shell applies to you, however up to date your plugins and extensions are.

Stores hold exactly what attackers want

Sansec notes that the memory-disclosure side of these flaws can expose passwords, session tokens, API keys and TLS private keys from other people's requests. On a store, that translates to:

• Admin and customer sessions, which let an attacker log in as you or your customers without a password
• Payment gateway secrets such as Stripe, PayPal, Braintree or Adyen API keys and webhook secrets
• Database credentials and integration tokens for shipping, ERP, marketplace and email services

Full code execution is worse. A long-running pattern in e-commerce attacks is to add hidden card-skimming code to the checkout page, which copies card details as customers type them. An attacker who can run code on your server can also create hidden admin accounts, change payment settings, add spam pages that get you blocklisted by Google, or encrypt the server for ransom.

You can't reduce the risk by switching features off in your store

The vulnerable code runs while PHP is setting up a request, before your store decides what to do with it. Disabling upload fields or closing the review form in your store doesn't help, because by the time your code runs, the vulnerable part has already run.

Timing

Black Friday is 27 November 2026, five weeks away. Many stores are already in a pre-peak code freeze. A known critical flaw left unpatched through the busiest trading weeks of the year is the worst combination of risk and impact. Patch now, while traffic is ordinary.

Who has to act depends on your hosting

• Hosted SaaS (Shopify, BigCommerce, Wix, Squarespace): the platform runs and patches its own servers. Your exposure is anything PHP you run around the store: a WordPress blog, landing pages, a custom app, an integration server, a forgotten old site.
• Shared and managed hosting (cPanel, Plesk, managed WooCommerce or Magento hosts): the host patches the PHP versions it supports. If your account is set to PHP 8.1 or older, you may never get a fix. Ask your host to confirm in writing which version you are on and when it was patched.
• Your own server (VPS, cloud, dedicated): you are responsible for the update.
• Containers (Docker, Kubernetes): running containers don't update themselves. You need to rebuild from updated base images and redeploy. Wiz confirmed that the standard wordpress:latest, drupal:latest and joomla:latest images were vulnerable before the fix.

On server setup, the PHP project rates Apache with mod_php as the highest risk, with confirmed attacks using default settings. PHP-FPM, FrankenPHP and LiteSpeed are also treated as affected; Wiz and Sansec say default configurations are vulnerable under both mod_php and PHP-FPM. Your server setup affects how urgent this is, but none of these setups is safe.

Part 3: How to Check Whether Your Store Is Affected

Short version: if your store runs on PHP and nobody has updated PHP since 21 October 2026, assume it is affected. The steps below confirm it either way.

Step 1: List everything you run on PHP

Most surprises come from systems that aren't the main store. Write down every one:

• The live store, and every server behind a load balancer
• Staging, development and "old" copies (staging., dev., old., shop2.)
• A WordPress blog or marketing site on a subdomain
• Admin tools: phpMyAdmin, Adminer, WHMCS, internal dashboards
• Integration, cron or queue servers running PHP scripts
• Any third-party service that hosts PHP for you

Step 2: Find the PHP version your web server actually uses

The version your command line reports can differ from the version serving your pages. Many servers have several PHP versions installed side by side. Check what the web server uses.

From your admin panel:

• WooCommerce: WooCommerce → Status → System Status → Server environment → PHP version
• WordPress (any site): Tools → Site Health → Info → Server
• cPanel: MultiPHP Manager. Plesk: Websites & Domains → PHP settings for each domain.
• Magento / Adobe Commerce: check through your hosting panel or the server (below)

With a temporary check file (the most reliable method, because it reports what the web server is actually running):

<?php
// Save as e.g. php-check-<random>.php in your web root, open it once in a
// browser, then DELETE it straight away. Never leave it on a live server.
header('Content-Type: text/plain');
echo 'PHP version: ', PHP_VERSION, "\n";
echo 'Server API: ', PHP_SAPI, "\n";
echo 'session.upload_progress.enabled: ', var_export(ini_get('session.upload_progress.enabled'), true), "\n";
echo 'memory_limit: ', ini_get('memory_limit'), "\n";
echo 'post_max_size: ', ini_get('post_max_size'), "\n";

From the server shell:

php -v                                  # command-line PHP (may differ from the web server)
ls /etc/php/                            # Debian/Ubuntu: which branches are installed
php-fpm8.3 -v                           # the FPM binary for a given branch
apt list --installed 2>/dev/null | grep -E '^(php[0-9.]+-(fpm|cli|common)|libapache2-mod-php)'
rpm -qa | grep -i '^php'                # RHEL, AlmaLinux, Rocky
docker exec <container> php -v          # inside a container

Don't rely on the X-Powered-By response header. It is often hidden, and it only describes the server that answered that one request.

Step 3: Compare against the fixed versions

If you install PHP from your Linux distribution, read this before deciding you're unpatched. Debian, Ubuntu, Red Hat and others add security fixes to their own package versions without changing the main PHP version number. A fully patched Ubuntu 24.04 server can still report PHP 8.3.6, for example. For distribution packages, compare the installed package version against your distribution's security notice. So far these include Debian DSA-6574-1 (php8.4) and DLA-4848-1 (php8.2), and Ubuntu USN-8948-1 and USN-8948-2. If you use a third-party repository such as Remi's or Ondřej Surý's, check that it has published the fixed build. Sansec reported that Remi's repository had no update on release day.

Step 4: Look for signs of an attack before you patched

If your store was unpatched and reachable at any point from 17 October 2026 (the earliest publicly reported attempt), check for signs of attack and compromise. Wiz, the PHP advisories and Sansec point to these warning signs:

• PHP running out of memory (Allowed memory size of ... bytes exhausted or Out of memory fatal errors), especially in bursts
• Bursts of HTTP 500 errors on POST requests, often with file-upload-style (multipart/form-data) requests
• Maximum execution time ... exceeded errors on pages anyone can reach
• Unusually large or malformed PHPSESSID cookies in responses
• Unexplained PHP worker churn: workers restarting or crashing more than usual

# Memory-exhaustion fatal errors (log paths vary by host and distro)
grep -hE "Allowed memory size of [0-9]+ bytes exhausted|Out of memory" \
  /var/log/php*-fpm.log /var/log/apache2/error.log* /var/log/nginx/error.log* 2>/dev/null | tail -50

# Crashing or restarting PHP-FPM workers
grep -hE "exited on signal|SIGSEGV" /var/log/php*-fpm.log* 2>/dev/null | tail -50

# POST requests that returned HTTP 500 (combined log format: date, IP, path)
zgrep -h '"POST ' /var/log/nginx/access.log* 2>/dev/null | awk '$9 == 500 {print $4, $1, $7}' | tail -50

The PHP advisory is explicit that clean logs do not prove you are safe: some failures happen before PHP writes anything, and older logs may not have recorded the right severity. So check for the results of a compromise as well:

• Admin accounts you don't recognise:
  • WordPress/WooCommerce: wp user list --role=administrator
  • Magento: SELECT username, email, created FROM admin_user ORDER BY created DESC;
• Recently changed code files: find /var/www -name '*.php' -newermt '2026-10-17' -type f. Legitimate updates will show up too, so look for files you can't explain.
• PHP files in upload folders, where they should never be: find wp-content/uploads pub/media -name '*.php'
• Core and plugin integrity: wp core verify-checksums and wp plugin verify-checksums --all for WordPress, and git status or a clean Composer comparison for Magento. Sansec's eComscan scans Magento, Shopware, WooCommerce and others for malware and skimmers left behind. It looks for signs of compromise, not for the PHP flaw itself.
• The checkout page: view the source of your live checkout and look for scripts you didn't add. On Magento, also review the HTML Head and Footer fields in the design configuration and any CMS blocks, which are common hiding places for skimmers.
• Scheduled jobs and access: crontab -l -u www-data (or your web user), plus ~/.ssh/authorized_keys for keys you didn't add
• Payment and shipping settings changed without your knowledge

Part 4: How to Fix It

The fix: update PHP, restart everything, verify

Debian / Ubuntu:

sudo apt update && sudo apt upgrade        # or upgrade just the php* packages
sudo systemctl restart php8.3-fpm          # repeat for every PHP-FPM version/pool you run
sudo systemctl restart apache2             # if you use mod_php, or to be thorough

RHEL / AlmaLinux / Rocky:

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd

Docker:

docker compose build --pull && docker compose up -d   # rebuild on the updated base image

Shared or managed hosting: update through the panel if it lets you choose a patched version, or open a ticket. Ask for written confirmation of the PHP version and the time it was applied, for every site on your account.

On PHP 8.1 or older: this is the moment to move to a supported branch. That may also mean upgrading WooCommerce, Magento or your extensions to versions that support newer PHP, so test it on staging. If you can't upgrade in time, get a patched build from your distribution or a commercial extended-support vendor, and use the temporary measures below until then.

Then verify:

1. Restart every PHP worker. A config change or package update doesn't reach workers that are already running. For mod_php, restart Apache. For PHP-FPM, restart each pool's service. For containers, redeploy.
2. Load your temporary check file through the browser and confirm the new version. For distribution packages, confirm the package version instead.
3. Delete the check file.

If you cannot patch today

The PHP project is clear that "updating is the only safe choice", and that its workarounds "do not make an installation safe." They reduce exposure to specific attack routes. Use them only to buy hours, not weeks.

1. Put a web application firewall (WAF) in front of the store.
Cloudflare has protected customers on its free and paid WAF plans since 03:02 UTC on 21 October. Pro, Business and Enterprise customers should check that the relevant Managed Ruleset rules are set to block. Fastly, Vercel and others also published protections. Two caveats: Cloudflare reported attackers modifying their requests to get past the rules, and a WAF only helps if attackers can't reach your server directly. Lock your server down so it accepts traffic only from your CDN or WAF.

2. Harden PHP's configuration. Set these in php.ini, the PHP-FPM pool, or the Apache config. Don't use ini_set() or .user.ini, which apply too late. Then restart every worker:

; Reduces exposure to CVE-2026-109619
session.upload_progress.enabled = 0
fatal_error_backtraces = 0          ; PHP 8.5 only

; Reduces exposure to CVE-2026-109618; set so applications can't override it
memory_limit = -1
post_max_size = 8M                  ; up to 32M if you genuinely need uploads
upload_max_filesize = 4M            ; must stay below post_max_size

In a PHP-FPM pool file, the equivalent lines are:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
pm.max_requests = 1                 ; recycle workers after each request (reduces CVE-2026-109619 exposure; costs performance)

Read the caveats before applying these:

• memory_limit = -1 lets a single request use all the server's memory. Pair it with a container or cgroup memory limit (for example MemoryMax= in the systemd unit). Do not use RLIMIT_AS/RLIMIT_DATA (ulimit -v). The PHP advisory warns these can trigger the vulnerable code.
• pm.max_requests = 1 noticeably increases CPU load and slows pages down.
• Also lower max_input_nesting_level and limit the number of input variables, upload parts and files.

3. Block file-upload-style requests where you don't need them. Both Sansec and the PHP advisory suggest blocking multipart/form-data requests at the web server if your site doesn't need them:

# nginx, inside the server block. Temporary measure.
if ($content_type ~* "multipart/form-data") { return 403; }

# Apache 2.4. Temporary measure.
<If "%{CONTENT_TYPE} =~ /multipart\/form-data/i">
    Require all denied
</If>

This breaks file uploads (product images in the admin, review photos, returns forms, CSV imports), and some checkout and account forms may use it. Test checkout, login and account pages immediately after applying it.

4. Or take the store offline properly. This is what governments did. If you choose it, serve the maintenance page from the web server or CDN, not from PHP. A WordPress maintenance plugin or Magento's own maintenance mode still sends every request through PHP, so the vulnerable code still runs. Use a static HTML page served directly by nginx or Apache, or a maintenance rule at your CDN.

After patching: clean up and rotate secrets

The memory leak can expose secrets from other people's requests. If your store was unpatched and reachable after 17 October, rotate secrets according to your risk:

• Payment gateway API keys and webhook signing secrets
• Database passwords, plus SMTP, shipping, ERP, marketplace and cloud credentials stored in wp-config.php, app/etc/env.php or environment files
• All sessions: for WordPress, change the salts (wp config shuffle-salts), which logs everyone out. For Magento, clear session storage (Redis, database or files).
• Admin passwords, and turn on two-factor authentication if it isn't already on
• TLS certificate: if you find evidence of exploitation, reissue it with a new private key

Then remove the temporary workarounds you no longer need: the multipart block, memory_limit = -1 and pm.max_requests = 1. The PHP project suggests keeping session.upload_progress.enabled = 0 permanently if you don't use upload progress bars.

If you find signs of compromise, don't just delete the suspicious files. Preserve the logs and a copy of the server first. Contact your payment provider or acquirer if card data or the checkout may be affected, since PCI DSS obligations apply. Check your breach-notification duties: in the EU and UK, GDPR requires notifying the regulator within 72 hours of becoming aware of a reportable breach, and in Australia the Notifiable Data Breaches scheme applies.

Part 5: How to Avoid Being Caught Out Next Time

PHP2Shell won't be the last flaw of its kind. These bugs went unnoticed for more than a decade and were found in weeks with AI-assisted tools. The same tools are available to attackers, so the time between a fix being published and attacks starting is shrinking. These habits make the difference:

1. Stay on a supported PHP branch. PHP 8.2's security support ends on 31 December 2026. Plan a move to 8.4 or 8.5 now. Do it before your peak-season code freeze, or schedule it for January, but schedule it.
2. Subscribe to the right alerts: PHP release announcements, your Linux distribution's security list (Debian's debian-security-announce or Ubuntu Security Notices), your platform's security advisories and your host's status page.
3. Have a patch plan with a deadline. Aim to apply critical runtime updates within 24 hours. That requires a staging environment close enough to production that you can test in an hour, not a week.
4. Put a CDN/WAF in front of the store, and only let it reach your server. It bought time for everyone using it on 21 October.
5. Keep an inventory of everything you run. The forgotten staging site on PHP 7.4 is the one that gets breached.
6. Limit what a compromise can reach. The web server user should not be able to write to code directories. Use separate database users per application. Keep secrets outside the web root.
7. Watch the checkout page. PCI DSS v4.0 requirements 6.4.3 and 11.6.1 require you to authorise the scripts on payment pages and detect unauthorised changes to them. This is your best early warning of a skimmer, whatever let it in.
8. Keep backups off the server and test that they restore.

Works Cited

1. BBC News: live coverage of the PHP vulnerability and website outages (21–22 October 2026). https://www.bbc.com/news/live/ckgel5xp2xv9t
2. Wiz Research: PHP2Shell: PHP RCE (21 October 2026). Discovery timeline, affected components, detection indicators, ~70% PHP share. https://www.wiz.io/blog/php2shell-php-rce
3. OpenCVE / NVD: CVE-2026-109618, RCE via OOM corruption. CVSS v4.0 9.2, CVSS v3.1 9.8, affected and fixed versions, credits. https://app.opencve.io/cve/CVE-2026-109618
4. OpenCVE / NVD: CVE-2026-109619, RCE via stale global state. CVSS, CWE, Debian and Ubuntu advisories. https://app.opencve.io/cve/CVE-2026-109619
5. PHP.net: release announcements for PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the security advisory Critical remote code execution vulnerabilities, update now (21 October 2026). https://www.php.net/archive/2026.php
6. PHP security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618). Server-mode susceptibility and interim workarounds. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
7. PHP security advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619). Mitigations, detection and audit guidance. https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
8. Sansec: PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619). Affected applications including Magento 2.4.9; store-owner guidance. https://sansec.io/research/php2shell
9. Cloudflare: Cloudflare deploys protections against php2shell vulnerability (21 October 2026). https://blog.cloudflare.com/php-vulnerabilities-waf-protection/
10. Help Net Security: PHP2Shell: Critical PHP vulnerabilities patched, update now! (21 October 2026). Amazon honeypot detection, NCSC guidance. https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
11. SecurityWeek: PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws (21 October 2026). https://www.securityweek.com/php2shell-mass-exploitation-looms-for-leaked-critical-php-flaws/
12. watchTowr: PHP RCE FAQ: PHP2Shell CVE-2026-109618 & CVE-2026-109619 (updated 22 October 2026). https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
13. Paubox: PHP flaws found by AI force governments and major sites offline (22 October 2026). NSA and NCSC statements, affected organisations. https://www.paubox.com/blog/php-flaws-found-by-ai-force-governments-and-major-sites-offline
14. CNBC: Government websites in Europe and elsewhere go dark as software flaw sparks security scramble (21 October 2026).
15. PCI Security Standards Council: PCI DSS v4.0, requirements 6.4.3 and 11.6.1.

This article reflects what was publicly known as of 22 October 2026. The situation is still developing: exploitation reports, vendor advisories and distribution patches are being updated daily. Check the PHP project's advisory and your distribution's security notices for the latest.

Written by WebloomLabs. If you'd like a second pair of eyes on your store, from confirming every server is on a fixed PHP build to checking for signs that someone got in before you patched, that is work we do.