Critical PHP Flaw (php2shell): What It Means for Your WordPress Site and How to Fix It

What happened with PHP, and why is it global news?

Two serious flaws were found in the core of PHP, the programming language behind most websites. On October 20, 2026, the PHP security team announced a critical security release for the next day; according to Cloudflare, details leaked ahead of the official date, and on October 21 the project shipped fixed versions with an unusually blunt recommendation: update immediately.

The flaws were reported by researchers at Calif, Wiz, OpenAI and Quarkslab, according to Cloudflare; Calif and Wiz say they used artificial intelligence models to find them. The reaction was global: the Canadian Centre for Cyber Security warned that some websites and online services may be temporarily unavailable while patches are applied.

Authorities moved quickly too. The European Commission, ENISA (the European Union Agency for Cybersecurity), CERT-EU (the computer emergency response team for EU institutions) and Europol issued a joint statement urging organizations to identify their PHP applications, coordinate with hosting providers and apply the updates, starting with internet-facing systems. In the United States, CISA (Cybersecurity and Infrastructure Security Agency) urged immediate patching and recommended disconnecting systems that cannot be updated or still run PHP 8.1 or older, and the NSA (National Security Agency) also advised taking sites offline if they cannot be updated.

The scale, in numbers

• PHP is the server-side language of 69.3% of websites whose server-side language is known, according to W3Techs (October 23, 2026).
• WordPress, which is written in PHP, powers 39.6% of all websites (W3Techs).
• One in three PHP sites still runs version 7 (26.9%) or version 5 (7.7%) (W3Techs), branches that no longer have official support.

Why does the PHP flaw affect WordPress if it is not in WordPress?

It does because WordPress runs on PHP: every time someone opens your page, the server uses PHP to build it. Think of a house. WordPress, your theme and your plugins are the building; PHP is the foundation. The house can be spotless and fully up to date and still be at risk if the foundation is cracked.

That is the big difference from typical incidents, which usually live in a plugin. Here the fix does not show up in your WordPress dashboard. It depends on who manages the server: on shared or managed hosting, your provider does it; on your own VPS (virtual private server) or cloud server, your technical team does.

The two php2shell vulnerabilities, in plain language

Both flaws involve how PHP handles memory when something goes wrong during a web request. This is how the official PHP advisory describes them:

The PHP project says every installation serving web requests is at risk: PHP-FPM (FastCGI Process Manager), Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php and validated one of the attack paths on PHP-FPM as well, so no server type is off the hook. An attacker who exploits the flaws could run code with the privileges of the server's web process, without logging in. Technical details are in GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.

Is my WordPress site at risk? How to check in two minutes

To find out, compare your site's PHP version with the table of fixed releases. Follow these steps:

1. Log in to your WordPress dashboard as an administrator.
2. Go to Tools > Site Health and open the Info tab.
3. Expand the Server section and find "PHP version".
4. Compare the full number with this table:

Keep two details in mind. First, read the full number, not just the branch: a site on PHP 8.3.35 is on a supported branch and is still vulnerable. Second, many hosts and Linux distributions apply the fix to their own build (a backport), so the number may not change. In that case, ask your provider to confirm in writing that its build fixes both flaws.

If you manage several sites, check each one: different domains on the same host can run different PHP versions.

How to fix php2shell on WordPress: a 7-step action plan

The permanent fix is updating PHP on the server; the other steps help you do it without breaking anything and confirm nobody got in first.

1. Inventory your sites and who manages each server

List every company site: the main one, stores, landing pages, staging environments and those old microsites nobody remembers. Next to each, note who manages the server and how to reach them. ENISA also recommends checking third-party products that bundle PHP even when it is not obvious; the Netherlands' National Cyber Security Centre (NCSC-NL) keeps a public list of affected software.

2. Take a full backup before you touch anything

Back up files and the database, store the copy off the server and confirm it restores. A PHP update can expose incompatibilities in old plugins, and the backup is your safety net.

3. Update PHP on the server

On shared or managed hosting: check your control panel (cPanel, Plesk or similar) for the available version, or open a ticket. You can use this message:

"Hi. My site [domain] runs on WordPress. Can you confirm in writing that the PHP version serving it already includes the fixes for CVE-2026-109618 and CVE-2026-109619 released on October 21, 2026 (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, or an equivalent backported build), that all PHP processes have been restarted and that session.upload_progress.enabled has been turned off in php.ini or the PHP-FPM pool, as PHP has recommended since October 21 and reiterated on October 23? Thanks."

On your own server or cloud: install the fixed packages from your distribution or vendor and restart every PHP process (PHP-FPM, Apache or whatever you use), because running processes keep the old code. If you use containers, rebuild the images. According to the SANS Internet Storm Center, most sites do not run PHP binaries from php.net but their distribution's packages, and waiting for your distribution's update will almost certainly be faster.

4. If you run PHP 8.1 or older, move to a supported version

The PHP project no longer updates 8.1 and older. Given the severity, it published minimal source-code fixes for 7.4, 8.0 and 8.1, meant for people who build PHP from source or have no long-term support (LTS) vendor; the PHP project published no fix for 7.3 or older. Some distributions and LTS vendors offer their own patches for old branches: ask for written confirmation, but plan the migration anyway. For a WordPress site, the way out is to migrate: WordPress recommends PHP 8.3 or newer and warns that unsupported versions may expose your site. Avoid stopping at 8.2, because its support ends on December 31, 2026 and you would have to repeat the work in two months.

Run the migration on a staging copy first: abandoned plugins or themes may break on modern PHP. If your site depends on many of them, it may make more sense to rebuild on a modern foundation than to keep patching; our guide on how much a website costs explains what drives that budget.

5. If you cannot update today: isolate the site or, at minimum, apply temporary measures

If you cannot update immediately, ENISA, CISA and the NSA advise isolating the site from the internet until it is patched. Isolating means blocking public access at the server, the firewall or the provider. A "maintenance mode" plugin does not achieve this, because PHP still processes every request.

If you cannot isolate it either, these measures, taken from the official PHP advisory, reduce exposure to specific attack paths while you update, but they do not make an unpatched server safe. They are for your technical team or your host:

• session.upload_progress.enabled=0 in php.ini, the PHP-FPM pool or the server configuration, then restart every process. Setting it with ini_set(), a WordPress plugin or a .user.ini file does not work, because those apply too late: the setting must take effect before PHP parses the request. Keep it off even after you update: PHP already recommended it on October 21, and on October 23 it published an informational advisory (CVE-2026-115560) about a flaw that only appears with an unusual configuration and that, according to Cloudflare, also reaches the already fixed versions. PHP recommends keeping it off until its next regular release.
• Lower post_max_size to 8M if the site takes no uploads, or 32M if it does, keeping upload_max_filesize below it; and cap request sizes at the web server or proxy as well.
• On PHP 8.5, set fatal_error_backtraces=0 and restart the processes.
• Hiding errors does not help: the PHP project states that suppressing their display offers no protection.
• This is a selection: the official advisory and the GitHub advisories list more measures for your technical team (memory limit settings, limits at the web server or proxy, containers). If memory is capped at the operating-system level, use containers or cgroups, never RLIMIT_AS or RLIMIT_DATA, which can trigger the flaw.

A WAF (web application firewall) helps as a brake while you update. Cloudflare switched on php2shell rules at 03:02 UTC (Coordinated Universal Time) on October 21, including on its free plan; on paid plans, confirm the managed ruleset is in block mode. Keep in mind that a WAF only filters the traffic that goes through it, that Cloudflare saw attackers changing techniques to evade the rules, and that its rule for the October 23 advisory does not cover servers that changed session.upload_progress.name. The company itself asks you to patch even with the WAF on.

6. Verify the fix is in place

Go back to Tools > Site Health > Info > Server and confirm the version. If your host or your distribution applied a backport, the number may stay the same: in that case, their written confirmation or the package version is what counts. If there was no backport and the old version still shows, the PHP processes most likely were not restarted, or the site uses a different PHP handler. Then test what your business depends on: logins, forms, the WooCommerce cart and checkout, and scheduled tasks. And remember that session.upload_progress.enabled=0 is still recommended until the next PHP release, even after you update.

7. Check for signs of compromise

Because details leaked before the patch and Cloudflare saw attack traffic against its customers, updating is not enough: you need to look back. Search for .php files inside wp-content/uploads, admin users you do not recognize, recent changes to .htaccess or wp-config.php, odd scheduled tasks and unusual outbound connections. Also review the Security issues report in Google Search Console. If anything looks off, change every password (WordPress, hosting, database and SFTP, Secure File Transfer Protocol), regenerate the security keys in wp-config.php and restore from a clean backup. If you would rather not do it alone, our team follows an incident response protocol for these cases.

What does not fix php2shell: common mistakes

• Updating WordPress, the theme or plugins: always necessary, but it does not touch PHP.
• Installing a security plugin: plugins run on top of PHP; they cannot fix the language.
• Turning on maintenance mode: PHP keeps processing requests even if visitors see a notice.
• Hiding errors: it does not reduce the risk, according to the PHP project itself.
• Relying only on a firewall: it is a temporary brake; attackers adapt.

The lesson for businesses: website maintenance is no longer optional

The lesson is that site security can no longer be handled with occasional check-ups. In July 2026, a chain of flaws in WordPress core (CVE-2026-63030 and CVE-2026-60137), which CISA added to its Known Exploited Vulnerabilities catalog, forced an emergency update; in October, php2shell hit the layer beneath it. And because artificial intelligence is already being used to find vulnerabilities (Calif and Wiz say that is how they found these), it is safer to assume that only hours may pass between an advisory and the first attacks.

That is why every business should be able to answer four questions: Who updates PHP on our server? How fast? Do we have tested backups? Who gets security alerts on a Sunday night? If any answer is "I don't know," you need someone accountable.

At DataLab we offer a website support and maintenance plan with updates tested on a staging environment, off-server backups, a firewall, monitoring, managed hosting on AWS (Amazon Web Services) and response times set in an SLA (service level agreement). And if your site is tied to old versions, our web development team can rebuild it on a modern, fast and secure foundation.

Not sure who updates PHP on your site? Get in touch and we will review your case: PHP version, hosting, backups and signs of intrusion. Let's review your site.

Update log: October 23, 2026, first publication.

Disclaimer: this article is for information only and the situation is evolving. When in doubt, always follow the official advisories from the PHP project and your country's cybersecurity authorities.