A CVSS 9.8 PHP Vulnerability Was Published. Did the World Patch It? I Looked at 268,000 Websites

日本語版: PHP に CVSS 9.8 の脆弱性が出た。で、世の中のサイトは直したのか

In 2026, PHP received a vulnerability scored CVSS 9.8 out of 10 (CVE-2026-109618 and CVE-2026-109619). It sits in how PHP handles running out of memory: when that happens, the contents of one request’s memory can end up in another request. Another visitor’s data or session can leak, and flaws like this get used for takeovers. Fixed releases came out quickly: 8.2.35, 8.3.36, 8.4.27 and 8.5.12.

A fixed release does not fix your site. Somebody has to press the update button.

Cyberattacks that take a company’s systems down and leave shops taking cash only have been in the news again and again in recent years. I don’t think those companies were targeted because they were big. They were hit because there was a hole. Holes don’t care how big you are.

I wanted to know how many sites out there are still carrying the hole. I am based in Japan, so I started with Japanese sites, then added the G7 countries plus Vietnam and Malaysia to see whether Japan is special or just typical.

1. Japan key figures

What I did: I just visited 268,000 sites like a browser would

I requested 268,485 sites in ten regions with one ordinary page load each: a DNS lookup, a TLS handshake, one GET. No port scans, no probing for vulnerabilities, no login attempts, nothing aimed at breaking in. 121,903 sites answered (35,998 of them Japanese).

What I read is what each server announces about itself in its response headers: “I’m Apache 2.4.x”, “I’m running PHP 7.4.33”. I matched those self-declared versions against the US NIST vulnerability database. Results are stored append-only and I only read them for the numbers. I did not tidy up anything inconvenient. The method, the tables and every region are in the data article.

Here are the numbers that scared me most.

Number 1: about six in ten PHP sites still show an unpatched version

Among sites that disclose a PHP version, the share still showing a version older than the fixed releases:

Vietnam 80.1%, global top sites 70.7%, Italy 69.5%, Malaysia 66.2%
UK 61.9%, Canada 60.2%, US & generic TLDs 59.7%, Japan 59.5%, France 55.8%
Germany 34.3%

Japan is not special here; most regions look alike. I did expect well-known sites to be in better shape. They are not: among Japan’s top-ranked sites the figure is 64.1%. Germany’s 34% shows what a culture of applying patches quickly looks like.

One caveat: this counts sites that display an old version. Linux distributions often back-port a fix without changing the version string, so some of these sites are really patched. The number is an upper bound. But an upper bound of six in ten is scary enough.

2. Unpatched version shown for the 2026 critical PHP CVEs

Number 2: end-of-life PHP, where no fix will ever come

Among PHP-disclosing sites, the share on an end-of-life version: Germany 29.8%, UK 35.9%, Canada 41.8%, France 42.8%, US & generic TLDs 45.5%, Malaysia 46.8%, Italy 49.5%, Japan 52.3%, global top sites 59.7%, Vietnam 64.2%.

End of life means that when a new hole is found, no fix will be written. There is no update button to press.

Japan’s long tail is what stood out. 24.0% of Japan’s PHP-disclosing sites (743 sites) still show PHP 5.x; no other region is above 20%. The last PHP 5.6 release came out in January 2019, so every flaw found since is still open on those sites. Among Japan’s 1,622 sites on end-of-life PHP, all of them fall within the affected range of at least one public CVE, and 97% of them include an RCE-class flaw, the kind that lets someone run their own commands on the server (the route to web-shell installation).

3. PHP end-of-life rate by region

Number 3: how many sites are in the range of takeover-class flaws

Across PHP, Apache, nginx, WordPress, OpenSSL and more, I counted sites that display a version inside the affected range of a CVE that could lead to takeover or code execution.

RCE-class (excluding one Windows-only CVE): Japan 3.5%, UK 1.5%, US 1.7%, Germany 1.8%, France 3.4%, Canada 3.5%, Italy 2.6%, Vietnam 4.5%. Japan is about twice the UK, US and Germany.
Memory-corruption class: Japan 8.1%, UK 3.1%, US 5.1%, Germany 7.6%, France 8.2%, Italy 10.1%, Vietnam 16.2%.

So Japan is not the worst, but it is clearly worse than the UK and the US. I did not attempt to break into anything, so I cannot say a given site is actually exploitable. I only saw the versions they announce. But when a server announces “I am an eight-year-old unpatched version”, it is easy to guess what an attacker will try next.

4. CVE exposure by region

The basics: Japan is last on all eight controls

Before PHP, there is a more basic layer. I counted eight standard defences: HTTPS enforcement, HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and having a WAF/CDN in front. Japan is last among the ten regions on all eight.

CSP: Japan 7.8%, UK 19.8%, US & generic TLDs 32.7%
HSTS: Japan 18.1%, US & generic TLDs 46.4%, Germany 47.7%
Sites that don’t enforce HTTPS: Japan 11.3%, against 1.5–4.1% elsewhere

Even among Japan’s top-ranked sites, HSTS is 27.5% and CSP is 10.9%, still below the other regions on CSP. A caution: the UK’s high header numbers largely reflect Cloudflare, which sits in front of 78.2% of UK sites and adds several of these headers by default.

On a simple seven-point hygiene score, Japan averages 3.17, the UK 4.81, Germany 4.42. 10.9% of Japanese sites score 1 or below, against 1.3% in the UK. Japan’s weakness is less the low average than the thick layer of sites that have done almost nothing.

5. Security control adoption by region

6. Hygiene score by region

Three things to do tomorrow

This looks like a technical problem, but it is a management one. “Nobody told us”, “there was no budget” and “we left it to the agency” are all management decisions.

1. Ask your developer or host three questions. “What PHP and server software versions are we running?”, “Until when are they supported?”, “Have the 2026 PHP fixes (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12) been applied?” If the answer is “I don’t know”, that is the answer.

2. Look at your own site from the outside. SiteScouter’s server information check shows what your server announces about itself in about ten seconds, using the same method as the survey. If it says X-Powered-By: PHP/7.4.33, that is your answer. No registration is needed.

3. Budget for maintenance every year. PHP gets a new series every year and an old series loses support after a few years. Put an annual version upgrade in the budget, like advertising. For the mechanics, follow your host’s “PHP version switch” instructions. Before switching, take a backup and check that your CMS, theme and plugins support the new version.

Closing

Servers announce their own versions without being asked. If a server announces “I am an unsupported version from eight years ago”, that is like taping a note on a door that says “unlocked”.

Hiding the version is not the answer. Peel off the note and the door is still open. First lock the door: update. Then take the note down. The order matters.

The full tables, CVE counts and the method are in the data article. No individual site is named. Even without names, these numbers are heavy enough.

Numbers come from the “Security Exposure Survey 2026” that I ran on 22–24 October 2026 (data collection: SiteScouter). Each site received one ordinary request; no attack or intrusion was attempted. “Exposure” is an upper bound based on the version string a server displays; distribution back-ports may mean a site is already fixed.

References: PHP Supported Versions (php.net) / NVD (NIST)