PHP2Shell: two PHP flaws on half the sites we scan

In short: what it means for your business

PHP is the engine behind about half of the business websites we scan. Every WordPress site runs on it. Worldwide, PHP runs about seven in ten of the websites whose language is known (W3Techs).

This week two serious flaws in PHP were made public and fixed. On a site that has not been updated, in some setups, a stranger could take it over without a password. Attackers have been trying them since before the fix came out, but no confirmed compromise has been published yet.

The solution is an update. Your hosting provider or your web developer installs it. It takes them little time, but someone has to do it. In the same days there were urgent updates for Node.js and for GitLab, and a week earlier for Nginx, the web server behind about a quarter of the sites we scan. The hosting platform Railway also reported a breach of the secrets its customers store there: if your developer or host uses any of them, ask about these too.

Three things to do today:

1. Ask your host or your developer whether PHP was updated on or after 21 October 2026. If they say yes, you are done. If they do not know, ask them to check.
2. If your site is old, ask about moving it to a current setup. Many sites still run on PHP 7, and PHP 7.4, the last 7.x release, reached end of life on 28 November 2022. PHP 7, 8.0 and 8.1 get no official fixed release: for 7.4, 8.0 and 8.1 there are source backports, and some vendors and Linux distributions apply them, but unless your host does, the hole stays open. Think of an old lock whose maker no longer sells the parts.
3. Run our free SEO audit. It lists the technologies your site shows to the world, but no version numbers, on purpose, to avoid possible abuse. If you want to know which version your own site runs, email us at info@nfw.run and we will see how to act.

Separately, make sure WordPress itself is current (7.1.3, or the latest release of your branch). PHP2Shell is a flaw in PHP itself: updating WordPress, plugins or themes does not fix it. See the section on WordPress below.

Read on for the technical details.

What happened and when

PHP is open source software, and its maintainers publish security advisories on GitHub. Wiz, a security firm, found the first flaw on 19 August 2026 and reported both to the PHP security team on 24 August (Wiz). The details were due out on 22 October, but they leaked before that date. The PHP project published the fixed releases on 21 October.

On exploitation, the reports differ. Amazon recorded an attempt on one of its honeypots, decoy servers set up to catch attackers, on 17 October, before the disclosure, and calls the flaws broadly exploited. watchTowr, another security firm, sees exploitation attempts against both flaws on its own honeypots (watchTowr). But the PHP Foundation found no working exploit at release, and CISA, the US cybersecurity agency, said on 21 October it had seen no exploitation (Tenable). No confirmed compromise has been published: Sophos first reported one on 22 October, then withdrew it the same evening, saying its telemetry shows scanning and a small number of failed attempts. Since then Rapid7 reports several public proofs of concept; each works only against a specific combination of operating system, PHP version and web server, none appears broadly reliable, and Rapid7's own attempts worked only under narrow lab conditions. A public toolkit on GitHub (we do not link exploit code) runs the chain through PHP's session.upload_progress feature on Apache with mod_php. At the time of writing neither flaw is in the US government's list of known exploited vulnerabilities.

Wiz, the firm that found them, published them under the name PHP2Shell. The two flaws are CVE-2026-109618 and CVE-2026-109619. Each scores 9.2 out of 10 on the CVSS v4 scale, the standard severity scale for vulnerabilities.

What the two flaws are

Both let a remote attacker run code on the server. Both work without logging in, over the network, before the site's own code even starts.

• CVE-2026-109618, a memory error that corrupts a request. If PHP runs out of memory while it is still setting up the data of a request, the setup stops halfway. The cleanup that follows treats that incomplete data as valid, and an attacker can steer what happens next.
• CVE-2026-109619, a stale pointer to freed memory. PHP keeps a pointer to a request's memory after that memory is freed. A later request handled by the same process can make PHP use it, and an attacker who controls that later request can turn it into running their own code.

Who is affected

Every PHP release below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 is affected. The reports disagree on how far back: Wiz says 5.4 onward, watchTowr says PHP 5 onward.

On how PHP runs, only mod_php, which runs PHP inside the Apache web server, is confirmed as fully exploitable with default limits. PHP-FPM (a separate PHP process manager), FrankenPHP, LiteSpeed (LSAPI) and php-cgi are likely exposed, but exploits for them are partial or unproven. Treat any of them as at risk until updated.

A backport is a fix copied by hand into older code. Some vendors and Linux distributions apply them to the branches above, so a site on an old branch may still be patched by its host.

What our scans show

Here is what our own data shows. Among the websites we scanned between 23 September and 22 October 2026, counting the latest successful scan of each site that answers with a working page, we have 61,024 working sites. Of these, 30,393 run PHP (49.8%), and 25,002 of them are WordPress (82.3%). By city, 12,353 of the 27,415 sites in the Milan report run PHP (45.1%), and 2,137 of the 4,765 in the Verona report (44.8%).

The PHP version is visible on only 8,915 of those sites (29.3%). The other 70.7% hide it. For comparison, W3Techs (page dated 22 October 2026) reports PHP on 69.3% of all websites whose language on the server is known, down from 73.4% on 1 October 2025. The share in our sample is higher: among the 34,196 working sites where we could tell the language on the server (counting ASP.NET), 30,393 run PHP, about 89%. The two figures are not the same measure: our sample is mostly small business sites in Italian cities, and passive detection finds PHP more easily than some other languages.

Of the sites where the version is visible:

• 4,747 (53.2%) run a branch with no official fixed release: 7.x on 2,788 sites (31.3%, of which 7.4 alone is 1,948), 8.0 and 8.1 on 1,312 (14.7%), 5.x on 643 (7.2%) and 4.x on 4.
• 4,168 (46.8%) run a supported branch, from 8.2 to 8.5, and all of them need the update.

On the web server of the PHP sites, Apache runs 7,725 (25.4%), Nginx 7,392 (24.3%), LiteSpeed 2,722 (9.0%) and IIS 244 (0.8%). On about 12,300 (40.5%) we could not detect the server. mod_php, which runs inside Apache, is the confirmed case, but Apache can also run PHP-FPM, and we cannot tell the two apart from outside.

Read these figures with care:

• Detection is passive and covers the home page only. We tested no site for the flaw.
• A CDN (a network of servers that sits in front of a site) can hide PHP, so the real share may be higher.
• A PHP packaged by a Linux distribution keeps its old version number even when the fix has been backported into it. A version string is not proof either way.
• The 61,024 is lower than the more than 79,000 sites quoted in our city reports: that figure counts every site we fetched, this one counts each working site once, at its latest scan.

How to fix it

If you own a site. Ask your hosting provider or developer to update PHP to a fixed release (on WordPress this means updating PHP on the server, not WordPress itself), or check the PHP version in your hosting panel, where your WordPress PHP version is shown. On a managed host, the provider usually does it for you: confirm that it did. If your site is stuck on PHP 7, 8.0 or 8.1, a move to a supported version is the real fix, and an old site is a good moment to rethink it (see our website redesign services).

If you manage servers. Update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12. If you use distribution or extended support packages, install the update from your distribution: they backport the fix without changing the version string, so check the package changelog and not the version. On branches without an official release, move to a supported one, or use a vendor that backports the fix.

Until you can update, these steps reduce the risk but are partial and do not replace the update. Every one of them needs a restart of every PHP worker to take effect.

• set memory_limit=-1 administratively: the PHP advisory calls it the primary configuration mitigation, but it removes the memory cap, so pair it with the limits below and, if you can, a memory limit on the container;
• do not use RLIMIT_AS or RLIMIT_DATA limits: they make memory requests fail, which makes the problem worse;
• keep post_max_size conservative, lower max_input_nesting_level and bound the number of input variables;
• block multipart requests (the kind used to upload files) where the site does not need them;
• set session.upload_progress.enabled=0 (the public exploit goes through that feature);
• use pm.max_requests=1 on PHP-FPM if you can afford the cost;
• on 8.5, set fatal_error_backtraces=0;
• if you use Cloudflare, check its WAF rules (a WAF is a filter in front of the site that blocks bad requests). They are on by default on every plan with the WAF, including Free. On paid plans, check that the Managed Ruleset is set to block and not only to log (Cloudflare). It is a stopgap.

Setting expose_php=Off hides the version header. That is hygiene, not a fix. If you can neither update nor apply the temporary mitigations, the UK's NCSC says to consider taking the system offline until it can be fully mitigated.

WordPress vulnerabilities: which version to be on

PHP2Shell is a flaw in PHP itself, so in our reading updating WordPress, plugins or themes does not fix it: the PHP update does. But every WordPress site runs on PHP, and WordPress itself should be current too, because the core had its own flaws this year.

wp2shell, July 2026. CVE-2026-63030, a confusion in the REST API batch route, chained with CVE-2026-60137, an SQL injection in the author__not_in parameter of WP_Query, lets an unauthenticated attacker run code. Wordfence called it the first critical unauthenticated remote code execution in WordPress core in nearly a decade (Wordfence). It is exposed even with no plugin installed.

• The full chain affects 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1. Versions 6.8.0 to 6.8.5 have the SQL injection only, and versions before 6.8 are not affected by wp2shell.
• The fix came on 17 July 2026 in 7.0.2, 6.9.5 and 6.8.6, and WordPress.org forced automatic updates on affected sites.
• Attacks began within hours of the patch, according to Wordfence: it saw the first probing of the batch endpoint at 23:29 UTC on 17 July and the first SQL injection attempt at 23:42 UTC, and proof of concept code circulated on 18 and 19 July. Wiz saw attackers install webshells, small programs that give an attacker a back door into the site. CISA added both CVEs to its Known Exploited Vulnerabilities catalog.
• Until patched, the mitigation was to block anonymous access to /wp-json/batch/v1 and ?rest_route=/batch/v1.

WordPress 7.1.3, 6 October 2026. The release is the latest of this year's WordPress security updates and carries seven security fixes: stored XSS on the Comments admin page through pending comments, a denial of service in WP_Http::make_absolute_url(), an SQL injection in the WXR export that fires on a second step, Authors able to make posts sticky, unauthenticated disclosure of comments on private and unpublished posts, XSS in Imgur embeds, and an action name collision in the {status}_{type} hook. No CVEs are listed and no exploitation has been reported. The same day brought 7.0.7, and backports (fixes copied into older branches) go to every branch still eligible, currently back to 4.7.

Only the latest WordPress version is officially supported. Security fixes are backported as a courtesy to 4.7 and newer. Versions 4.1 to 4.6 stopped getting fixes in July 2025, and 3.7 to 4.0 on 1 December 2022. Anything older than 4.7 gets no fix at all. The latest WordPress version is 7.1.3; for each branch, this is the version to be on:

What to do. Update WordPress to 7.1.3, and check plugins and themes too. If the site ran a version from 6.8.0 to 7.0.1 in July, look for administrator accounts you do not know and for files you did not upload: they are signs your website was hacked. If your WordPress site was hacked, take it offline and ask a developer for help before restoring a backup. Our free SEO audit shows WordPress among the technologies it detects on your home page, but not its version number, on purpose. Ask your host or developer, look in the WordPress dashboard, or email us at info@nfw.run.

In the same days: Node.js, Nginx, GitLab and Railway

Node.js

On 21 October 2026, Node.js also published security releases. The fixed versions are 22.23.4, 24.22.1 and 26.12.1. They fix ten vulnerabilities, four rated High:

• CVE-2026-111497, a write outside the memory it should use, in the Brotli decoder (Brotli is a compression format), that permits remote code execution. Node.js runs the bundled Brotli code whenever it decompresses Brotli data, directly through node:zlib or automatically when code calls fetch() on a Brotli compressed response, so an application is exposed where it decompresses Brotli data an attacker controls, such as a request body or a response fetched from another server. It is rated high, not critical. According to The Hacker News, the public proof of concept of 22 October reached code execution only against a deliberately weakened test build; on a standard build its author reported a crash and a limited read of process memory.
• CVE-2026-106069 and CVE-2026-105483, where TLS certificate hostname checks can be bypassed.
• CVE-2026-105482, where dns.resolve truncates names at a NUL character.

Node.js did not publish CVSS scores. In our scans, Node.js shows on 235 sites and Next.js, which usually runs on Node.js, on 1,144. Detection from outside undercounts Node.js, and a statically exported Next.js site runs no Node.js server. If you run Node.js, update to one of the three fixed versions. On a managed platform such as Vercel or Netlify, check the provider's notice.

Nginx

A week earlier, on 14 October 2026, F5, which develops Nginx, published a security notification outside its usual schedule (see nginx.org and F5). F5's notice lists 11 CVEs across its NGINX products (Plus, Open Source, Gateway Fabric, Ingress Controller and the njs module); the five below affect NGINX Open Source, and nginx.org lists the same five. The fixes are in Nginx 1.30.6 and 1.31.7:

• CVE-2026-15176, a buffer overflow when alias is used with rewrite.
• CVE-2026-93479, a buffer overflow in script evaluation (F5 titles it the NGINX map directive and regex matching vulnerability), which depends on a map with regex captures.
• CVE-2026-97205, a use after free (memory used after it was released) with asynchronous file I/O.
• CVE-2026-97629, session forgery when TLS session tickets are used (F5: an ngx_http_ssl_module vulnerability).
• CVE-2026-95101, request body injection in HTTP/3 (F5: an ngx_http_v3_module vulnerability).

The first three are memory bugs that can crash Nginx and, in some setups, may let an attacker run code. The fourth can weaken client certificate checks. The fifth lets extra bytes reach a backend over HTTP/3.

Severity is reported differently. nginx.org rates all five medium, while F5 rates three of them (CVE-2026-15176, CVE-2026-97205 and CVE-2026-93479) critical, 9.2 on CVSS v4. Most of them depend on a specific configuration: alias with rewrite, asynchronous file I/O, map with regex captures, or HTTP/3. Some have been there for a long time: CVE-2026-15176 affects versions from 0.1.29 and CVE-2026-97205 from 0.8.11.

In our scans, Nginx shows on 15,089 of the 61,024 working sites (24.7%), the same population as the PHP figures. The version is visible on 1,476 of them. Only 4 of those show a fixed version, and 1,353 run a branch older than 1.30, for which nginx.org publishes no fix. Linux distributions backport fixes without changing the version number, so the same caveat applies. Many of these scans predate 14 October. To fix it, update to 1.30.6 or 1.31.7, or install your distribution's updated package, and check the configurations listed above.

GitLab

On 21 October 2026, GitLab published a critical security patch release: 19.5.1, 19.4.3 and 19.3.6, with backports to 19.2.9, 19.1.9, 19.0.10 and 18.11.13.

The main flaw, CVE-2026-110264 (critical, CVSS 10.0), is an integer overflow when compiling a crafted regular expression. Under certain conditions it can let an unauthenticated user run code on the GitLab server. It affects every version from 7.0, roughly twelve years of releases. The same release fixes eleven more issues, two of them High: CVE-2026-15723 (8.2, an authentication flaw in OmniAuth to LDAP auto linking) and CVE-2026-112212 (7.5, cache poisoning in the OAuth and OIDC discovery endpoints).

GitLab.com and GitLab Dedicated are already patched. Only installations that you run yourself need to act.

GitLab is where developers keep code, not a business website, so it does not show in our scans (0 sites). It matters if your developer or agency runs their own GitLab server with your site's code: ask them.

Railway

This one is not a software flaw but a breach of a platform. Railway is a platform where developers run their apps. On 21 October 2026 it detected unusual activity on the systems that store its customers' environment variables. In its security notice, as quoted by GitGuardian, Railway says an unauthorized third party "may have accessed encrypted environment variables" and, "for some of them, obtained the decrypted values". Environment variables are where developers keep API keys, database credentials and private registry credentials. The same notice says the impact is limited to a subset of users, who will be contacted by email, and links the incident to a series of attacks on platform companies aimed at reaching AI inference providers.

Railway's response, from its status page: OAuth sessions were invalidated so users must log in again, all bucket credentials were rotated, and on 22 October all Railway API tokens were invalidated, so new ones must be created. Its latest update, at 23:22 UTC on 22 October, says builds and deployments are back to about normal speed on all tiers, new signups are paused, and a preliminary incident report is coming.

Railway asks all customers to rotate their environment variables. GitGuardian lists the guides Railway published for AWS, GCP and GitHub credentials.

In our scans, 9 of the 61,024 working sites are served from Railway, detected from response headers. Railway mostly hosts apps and backends, not the business sites we scan, so the exposure is in what runs behind a site. If your developer deployed anything of yours on Railway, ask whether every secret has been rotated.

Check your own site

Our free SEO audit lists the technologies detected on your home page, but no version numbers. To know which PHP version your site runs, email us at info@nfw.run and we will see how to act. If the site is on PHP 7 and you would rather start fresh than patch around it, our website redesign services rebuild it on a current stack. For a new site, see our web design services. PHP releases are listed on php.net.