What percent of the web uses PHP? Why PHP2Shell is so bad

About 70% of websites with a known server-side language run PHP: W3Techs measured 69.2% on 28 October 2026. That is why PHP2Shell, two remote code execution bugs in PHP itself (CVE-2026-109618 and CVE-2026-109619), reaches so many sites. The one fix is a patched PHP (8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor backport) and a worker restart.

What percent of the web actually uses PHP?

The number you see most often is "70%". Wiz writes that PHP powers 70% of all websites in the world without citing a source, and Cloudflare says "almost 70%" and cites W3Techs.

The source is the W3Techs page, and its wording is narrower. On 28 October 2026 it said PHP is used by 69.2% of all the websites whose server-side programming language it knows. Sites where it cannot tell the language are left out. So the honest sentence is "about 7 in 10 of the sites W3Techs can classify". It is a measure of what runs PHP, not of how many sites are vulnerable. A site on a patched build counts in the 69.2% and is not at risk from these bugs.

Why is PHP2Shell so bad?

Three facts from the primary sources explain it.

1. It is in the engine, not the application. The PHP project describes two flaws in PHP core: out-of-memory handling that can leave request data half initialised, and request state that survives after its memory is freed and is reused by a later request on the same worker (each bug in plain English). Cloudflare states that updating website code or a plugin alone does not fix them.
2. No login is needed. The Dutch NCSC says both can be reached remotely through web requests without authentication and can lead to remote code execution. It rates the advisory priority "Hoog" (High).
3. It reaches far back. Wiz says every PHP version released in the last decade is affected by at least one of the bugs, going back to 5.4. That is the researcher's statement. The PHP project publishes fixes only for 8.2 to 8.5, plus the source backports for older branches.

Wiz reports finding the first bug on 19 August and reporting to the PHP security team on 24 August, so the fix took about two months to reach users (same Wiz writeup). For the last bug of comparable scale, see how it compares with Log4Shell.

Did it knock governments offline?

We found no primary source that says a government system went offline because of PHP2Shell. What the primary sources do say is advice. The UK NCSC, in an alert published 21 October and updated 23 October, tells organisations to identify systems running PHP, update, and consider taking a system offline until it is fully mitigated if temporary mitigations cannot be applied in time. The Dutch NCSC advisory does not mention any government system being taken offline.

Posts naming a government service that went down are leads. Until the operator or a national agency says so, we do not repeat them. Our October 2026 incident tracker keeps the dated list of what is confirmed.

Who is affected, and what is the trap?

Any site whose PHP serves web requests and does not have the fix. That covers WordPress, WooCommerce, Drupal, Magento, Laravel and every other PHP application, since the bug is underneath them. Why updating WordPress alone does not help has the detail. Sites that do not run PHP are outside this bug. If you run a small site or a store, the October 2026 pages for small businesses and ecommerce stores put this next to the other incidents.

The trap is the version number. Some distributions and LTS vendors backport fixes for 8.1 and older, and a patched package does nothing until the workers restart. The PHP project says to contact your vendor for those backports. If you are on 8.1 or older, what owners of end-of-life PHP do now is its own page, and the other PHP2Shell guides cover the rest. The full walkthrough is in PHP2Shell: affected versions, fixes, and what to do now.

How do I fix it?

If a host manages PHP for you

Send support this question and keep the reply:

For [your domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed package, build or backport identifier, confirm that all PHP workers serving it have been restarted or replaced, and say whether I need to redeploy.

• Get the answer in writing, naming your domain.
• Ask for the package or build identifier, not only a version.
• Ask for the worker restart time.

If you run the server yourself

• Update PHP from your distribution or vendor so the package changelog names both CVEs, or move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
• Restart every PHP worker, and rebuild container images that bundle PHP.
• Check each virtual host and each PHP version on the machine.
• If you cannot patch today, apply the project's temporary measures and restrict access. The project says they reduce exposure to specific paths and do not make an installation safe.

A WAF is extra cover only. Cloudflare says its rules reached free and paid customers from 21 October 03:02 UTC and still tells customers to patch.

Am I affected?

Was it exploited?

AWS reports that its MadPot honeypots recorded attempts from 17 October, before disclosure. That is vendor telemetry (attempts versus real compromise is a separate question), and AWS says it is unclear whether such attempts would work on real systems. CISA then added both CVEs to its Known Exploited Vulnerabilities catalog on 26 October 2026, with a federal due date of 29 October and a forensic triage flag on each entry. The catalog lists known ransomware use as unknown. CISA names no victims, and neither do we.

The PHP project also published a 23 October informational notice for a related issue, CVE-2026-115560, and suggests setting session.upload_progress.enabled=0 until the next regular release. It is a separate item with its own conditions.

If your PHP was unpatched and reachable since 17 October, look for unexpected PHP files in upload folders, new scheduled tasks, new admin accounts and odd outbound connections. Patching does not remove anything planted before it.

The free scan reads the stack your site serves and matches each version to known vulnerabilities. It is a lookup: it can say a version is affected, not whether your setup is exposed.