The Overall Picture of PHP and Other Vulnerability Exposure in JP Domains — Interim Report: 1,197,208 Existing .jp Domains Observed with One Method

Also published on Site Scouter and Egosaru.

Summary

Interim report of a survey whose population is a ledger built to cover delegated .jp domains comprehensively (1,197,208 domains as of 2026-10-29, 63.0% of the 1,901,067 registrations published by JPRS), with the same non-intrusive observation (DNS lookups, one TLS handshake, one HTTP GET) applied to every one of them. The targets are not names picked from rankings or search history but “nearly all .jp domains that exist”.
Reachability (DNS resolved and an HTTP response received) was 87.9%. The registered domain itself (example.jp) reached 84.1%; trying www. once, only for names that had not responded, added 44,801. Many local-government (lg.jp) and geographic-type names respond only on www..
Of the 1,052,121 responding domains, HTTPS enforcement is 95.1%, HSTS 14.3%, CSP 7.2%, X-Frame-Options 13.2% and version concealed 83.9%. HTTPS and version concealment have reached almost everywhere, while HSTS and CSP, which are configured on the site side, stay below half the level of the world 5M-site survey (Article G).
10.3% of responding sites announce a PHP version, and 52.9% of those are end-of-life (EOL) versions (8.1 or earlier). Sites announcing a version within the affected range of the critical 2026 PHP vulnerabilities (CVE-2026-109618 / 109619) are 49.1% of version-announcing sites. Sites announcing a version within a published CVE range are 8.1% of responding sites (upper bound).
WordPress was identified on 33.0% of responding sites. Among plugins referenced from the top page, Contact Form 7 stands out at 49.0%, and sites whose matched major-plugin versions fall within a published CVE range are 21.9% of WordPress sites.
For email sender-domain authentication, among names whose DNS resolved, SPF is 82.6% and DMARC 34.9%. Even where DMARC exists, most of it is p=none (monitoring only); quarantine / reject, which ask receivers to quarantine or reject, total only 3.8% + 2.1%.
For comparison, 131,622 .com / .net / .org domains already classified as Japanese-language were observed, taken from the domain evaluation data the author has accumulated as a registrar. Responding Japanese-language gTLD sites more often have a WAF/CDN in front, at 44.8% (.jp: 10.8%), and HSTS was 16.0%.

1. Where this survey sits

The earlier “Security Exposure Survey 2026” (Articles A–D) and the world 5M-site survey (Articles F and G) built their populations from rankings such as Tranco and Majestic and from Site Scouter’s search history. For Japanese sites, that skews toward names used enough to appear in a ranking, or names someone looked up. The low 11.7% reachability of the 130,000 Japanese domains in Article B (from search history) is a symptom of this.

This report changes the population. Against the .jp registration count published by JPRS, names were collected from the Common Crawl web graph, CT logs, our own domain assets and candidates generated from dictionaries and company names, and each was checked one by one against the .jp authoritative DNS for delegation. The result is the domain census ledger (the .jp pseudo-zone), and every delegated name in it was observed. The ledger was frozen on 2026-10-29, and the 1,197,208 names delegated at that point form the population. Coverage against the JPRS published count (1,901,067 as of 2026-10-01) is 63.0%; the rest will be added in the final report once collection on the ledger side has progressed (Figure 1).

Figure 1 Population and coverage (by domain type; delegated names in the ledger against the JPRS published count)

A note on population bias first. 80% of the names in the ledger come from the Common Crawl web graph, which leans toward names linked from somewhere. Names without links (mail-only names, names merely registered, internal-use names and so on) are likely concentrated in the remaining 40% of coverage, so the reachability and adoption rates in this report are most accurately read as the level for “.jp domains that have been linked at some point”. By domain type, coverage is 71.4% for co.jp and 58.8% for general-use .jp, so comparisons between domain types also carry differences in coverage.

2. Method

Each domain received only DNS lookups, one TLS handshake and one HTTP GET: the same access as opening the top page once in a browser. No port scanning, path probing (/wp-login.php and the like), authentication attempts or exploit traffic. As additional DNS lookups, mail-related TXT records (SPF, DMARC), MX and AAAA were queried (no additional HTTP or TLS).

Observation points: work was spread across workers on 9 machines and 15 processes on domestic connections such as Sakura VPS, ConoHa and OCN lines, with one hub server handing out the queue. The distribution order was randomised so that domains on the same DNS provider or the same shared server were not observed back to back. Observations ran at about 3,500–4,400 per minute overall, and fewer than one per minute per shared server.
Host unit: ledger names (example.jp, example.co.jp, city.example.lg.jp) were observed as they are, and www.<name> was tried once only for names that ended in a DNS failure or connection failure (155,694 names). At most two GETs per name; the row from whichever side was reached is used. “Reachability” is the share with an HTTP response on either the apex or www.; apex-only reachability is also given.
De-duplication: where a host was observed more than once, the latest row that is not a DNS failure is used, otherwise the latest row. Hosts already observed in Articles A–G (about 100,000 in .jp) were re-measured in the same observation window.
Metric definitions are the same as in Articles A–G: HTTPS enforced = an HTTP request is redirected to HTTPS; HSTS = the response carries Strict-Transport-Security; version concealed = no version number in Server or X-Powered-By; CVE exposure = the version in the headers falls inside the affected range of a published CVE (upper bound).
CVE matching used a mirror of the NVD (the vulnerability database of the US National Institute of Standards and Technology) updated on 2026-10-29, counting only matches down to the CPE product name (php:php, apache:http_server and so on). PHP support status is fixed at the observation date: 8.1 or earlier is end of life, 8.2 is security fixes only (until 2026-12-31), and 8.3–8.5 are supported.

3. Reachability — just under nine in ten .jp domains respond on the web

Of the 1,197,206 names observed, 1,052,121 (87.9%) returned an HTTP response. The apex alone gave 1,007,320 (84.1%), and 44,801 more were added through www.. Apex failures break down into DNS failures 10.5%, connection failures 2.5% and TLS errors 2.9% (Figure 2).

Figure 2 Reachability by domain type and failure breakdown

Reachability differs widely by domain type. co.jp reaches 91.9% (apex 87.2%), general-use .jp 85.8% (apex 83.0%) and or.jp 94.9%. By contrast, lg.jp (1,040 names) responds on only 5.5% at the apex, rising to 75.2% with www.. Geographic-type names (1,834) likewise go from apex 25.4% → 73.0%, go.jp from 51.6% → 86.9% and ac.jp from 74.5% → 94.7%. Local-government, central-government, university and geographic-type domains have a strong convention of placing no A record on the registered name itself and running only www.. The ranking-based surveys (Articles A–G) observed the apex, which means they counted names of this kind as “unreachable”.

Reached includes 403 Forbidden (the headers were obtained). 403 accounts for 7.4% of responses, mostly the default response a shared server returns for a domain with no content. To tell this apart from WAF rejection, the 403 rate was also monitored per provider, and it did not change from the sample test.

4. Adoption of security measures — HTTPS has spread, headers are untouched

The table shows adoption as a share of the 1,052,121 responding domains. For comparison it also lists the gTLD Japanese-language site sample (section 14) and the .jp of Article G (.jp domains in Tranco and Common Crawl).

Measure	All JP (n=1,052,121)	gTLD Japanese-language sites (n=38,092)	Article G .jp (n=44,169)
HTTPS enforced	95.1%	86.6%	96.1%
HSTS	14.3%	16.0%	18.2%
HSTS (max-age ≥ 1 year)	11.2%	13.3%	—
CSP	7.2%	9.8%	8.3%
X-Frame-Options	13.2%	18.4%	19.2%
X-Content-Type-Options	19.3%	15.9%	23.1%
Referrer-Policy	5.3%	16.1%	—
Permissions-Policy	2.6%	8.7%	—
Version concealed	83.9%	79.4%	80.2%
WAF/CDN in front	10.8%	44.8%	18.0%
TLS 1.3 negotiated	75.8%	82.2%	—

HTTPS enforcement is 95.1%, leaving only a minority of sites on plain HTTP. Version concealment is also high at 83.9%, probably because many domestic shared hosting providers default to a configuration that does not put the version in the Server header. HSTS, on the other hand, is 14.3%, CSP 7.2% and X-Frame-Options 13.2%: headers the site operator has to set up themselves stay at around one in ten.

Placed next to the earlier surveys (Figure 3), widening the population from “ranked .jp” to “nearly all existing .jp” lowers HSTS from 18.2% for Article G’s .jp to 14.3%, and X-Frame-Options from 19.2% to 13.2%. Japan in Article B, whether Tranco-derived (HSTS 27.5%) or Majestic-derived (20.2%), has a different population, so do not read these as improvement or deterioration. The sound reading is that the tendency for widely used sites to be better hardened has been confirmed in Japan as well, on a population close to the full set.

Figure 3 Comparison with earlier surveys (same metrics, different populations)

By domain type (Figure 4), go.jp (596 sites) and lg.jp (782) stand out for HSTS (34.6% and 30.1%) and X-Frame-Options (43.6% and 49.7%). lg.jp, however, has low version concealment at 44.9%: many of its sites announce the server product version. co.jp (330,598) shows HSTS 12.2% and CSP 7.5%, not far from general-use .jp (HSTS 15.5%). Rates for domain types with fewer than 1,000 responses (go, ad and lg) are shown with their counts and are not used in headlines.

Figure 4 HSTS, CSP, X-Frame-Options and version concealment by domain type

Among sites that set a cookie (213,345), Secure was present on 65.0%, HttpOnly on 67.8% and an explicit SameSite on 21.6%.

5. By NS provider — adoption levels differ widely by where DNS is hosted

The ledger records each domain’s NS (authoritative DNS servers) and normalises the provider from the NS hostnames. Adoption was compared across the top 10 providers that domains delegate their NS to, plus everything else (Figure 5). The NS provider is the provider hosting the domain’s DNS, and is not necessarily the hosting provider where the website lives. A domain whose NS is Xserver may have its website elsewhere, so the values in this section do not mean “that provider’s servers are vulnerable”; they mean “the state of the sites of users who host their DNS with that provider”. Version disclosure and CVEs change with site-side configuration, so CVE exposure by provider is not given.

Figure 5 HSTS, CSP and version concealment by NS provider

NS provider	Responding sites	HSTS	CSP	Version concealed	WAF/CDN in front	TLS 1.3
Xserver	194,701	4.1%	3.4%	98.8%	4.1%	97.5%
Sakura Internet	152,912	3.9%	3.1%	89.7%	2.5%	95.0%
GMO Pepabo	106,435	8.8%	5.8%	47.4%	6.0%	92.3%
AWS Route 53	71,042	22.0%	8.5%	75.3%	32.9%	64.8%
GMO (DNSv)	64,312	20.8%	15.4%	81.6%	14.5%	75.3%
GMO	55,471	5.8%	4.9%	91.1%	6.5%	82.2%
GMO (VALUE-DOMAIN)	29,276	62.6%	10.8%	88.7%	3.8%	90.1%
Cloudflare	29,306	23.1%	11.9%	90.8%	83.5%	94.6%
customer.ne.jp	30,562	2.7%	1.8%	75.0%	1.7%	5.6%
CPI (KDDI)	12,600	23.7%	2.7%	90.8%	2.3%	44.2%
Other	305,504	21.5%	10.5%	84.7%	10.8%	53.4%
(Ref.) GMO group total	266,490	16.6%	8.3%	71.5%	7.7%	82.1%

Names whose DNS is hosted with domestic shared hosting providers (Xserver, Sakura Internet, customer.ne.jp) show high reachability, but low HSTS (4.1%, 3.9% and 2.7%) and CSP (3.4%, 3.1% and 1.8%). Version concealment is almost universal for Xserver at 98.8% and 75.0% for customer.ne.jp. For names whose DNS is with customer.ne.jp, only 5.6% of sites connected over TLS 1.3, which suggests they sit on infrastructure without TLS 1.3 support. On shared hosting the provider’s default configuration often adds no headers, so they are absent unless the user adds them through .htaccess or similar. Names whose DNS is with AWS Route 53 or Cloudflare show high HSTS and X-Frame-Options and more often have a WAF/CDN in front, probably because many of them run their own servers or put a CDN in front. Names whose DNS is with GMO (VALUE-DOMAIN) have the highest HSTS among the top 10, at 62.6%. For CPI (KDDI), only 44.2% of sites connected over TLS 1.3. The GMO group is shown as five separate entries. The differences between entries are large: names whose DNS is with GMO Pepabo have lower version concealment than the others, at 47.4% (server configurations that announce the PHP version in X-Powered-By remain).

Conflict-of-interest disclosure: the author runs a domain business (a JPRS-accredited registrar) through SkyClear Co., Ltd., and is a former officer of a GMO Group subsidiary. The subjects of this section include GMO group providers. All values were computed for every provider with the same method and the same criteria.

6. TLS and certificates

TLS 1.3 was negotiated on 75.8% of connections and TLS 1.2 on 15.1% (gTLD Japanese-language sites: 82.2% / 2.4%). A site that connected over TLS 1.2 is a site that “did not choose TLS 1.3”; a site that only speaks TLS 1.0/1.1 fails to connect and cannot be told apart from other failures (version-pinned handshakes would go beyond the “one TLS handshake” rule and were not performed). Certificates were DV on 86.4% and OV on 4.6% (Figure 6).

Figure 6 TLS version and certificate validation level

7. Server products and version disclosure

The Server header named nginx on 47.7%, Apache on 34.9%, Cloudflare on 5.8% and LiteSpeed on 2.9% (Figure 7). Cloudflare, common in the world 5M-site survey (Article G), is rare here; nginx and Apache, common on shared hosting, account for 80%. A version number was included by 7.9% of Apache and 2.4% of nginx sites.

Figure 7 Product named in the Server header and version disclosure rate

8. PHP versions and support status

10.3% of responding sites (108,894; Japan in Article B: 8.6%) announce a PHP version in X-Powered-By or similar. Of the announced versions, end-of-life (EOL) versions (8.1 or earlier) are 52.9% (57,554 sites). 13,399 sites remain on PHP 5 and 40,838 on PHP 7. 5,378 announce 8.2 (security fixes only) and 45,962 announce a supported 8.3 or later (Figure 8).

Figure 8 Support status of PHP-disclosing hosts and the distribution of disclosed versions

For the critical PHP vulnerabilities CVE-2026-109618 / 109619 published in 2026 (fixed in 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12), 53,506 sites announce a version that the NVD lists as affected, 49.1% of version-announcing sites. End-of-life versions cannot receive this fix. Security fixes for the 8.2 branch also end on 31 December 2026.

By domain type, the EOL share among version-announcing sites is 52.2% for co.jp, 53.4% for general-use .jp and 48.2% for or.jp. Announcing a PHP version is not a vulnerability in itself, but announcing an end-of-life version tells attackers where to look.

9. CVE exposure (upper bound)

8.1% of responding sites (85,434) announce a version in their headers that falls within the affected range of a published CVE. 5.5% include an RCE (remote code execution) class CVE; excluding CVE-2024-3566, which is limited to PHP-CGI on Windows, the figure is 1.6%. 7.3% include a CRITICAL one (Figure 9). By product, 53.7% of sites announcing a PHP version, 89.2% of those announcing an Apache version and 67.7% of those announcing an nginx version were within a published CVE range.

Figure 9 CVE exposure rate (upper bound) and breakdown by product

This survey did not attempt any attack. CVE exposure based on announced versions cannot reflect distributions’ back-ported fixes, so it is an upper bound, and the actual state of hosts that hide their version is unknown. CVE-2024-4577 (PHP-CGI) presupposes Windows, CGI and specific locales, conditions that non-intrusive observation cannot confirm, so it was treated as undeterminable even where the version matched.

10. Basic hygiene score

The number of items met out of seven — HTTPS enforced, HSTS, CSP, X-Frame-Options, X-Content-Type-Options, version concealed and a valid certificate — gives a 0–7 score. The mean for all JP is 3.24 (gTLD Japanese-language sites: 3.11; world pooled in Article G: 3.67). 3 points is the most common at 54.6%, and a full 7 is reached by only 2.3% (Figure 10). “HTTPS, certificate and version concealment done; headers untouched” is the typical shape of Japanese sites.

Figure 10 Distribution of the basic hygiene score (0–7)

11. Organisation type and region

The ledger stores registrant organisation names from WHOIS (JPRS), keeping only names that look like legal entities, and matching them against the National Tax Agency’s published corporate number data reveals the entity type and location. At the time of this report, however, WHOIS has been retrieved for only 37.0% of delegated names, and only 3.2% of all names could be matched to a corporate number. The comparison by entity type is therefore limited to a reference table (Figure 11); comparison in figures will be made in the final report, once WHOIS retrieval for all names is complete.

Figure 11 Entity type (reference; only names matched to a corporate number)

Prefectures were tallied over the three domain types whose names alone determine the prefecture (prefecture-type (e.g. example.tokyo.jp), geographic-type and lg.jp; 3,857 + 1,834 + 1,040 names in total) (Figure 12). Many prefectures have few names, so prefectures with fewer than 30 responses are shown in grey and no ranking is made.

Figure 12 Basic hygiene score by prefecture (the three determinate domain types)

12. Email sender-domain authentication (SPF, DMARC) and IPv6

DNS configuration can be observed even for names whose website does not respond. For each name, TXT (SPF), the TXT at _dmarc.<name> (DMARC), MX and AAAA were queried (names whose lookups failed are excluded from the denominator; DNS resolved for 1,120,831 names).

	All JP	co.jp	General-use .jp	Web responding	Web not responding	gTLD Japanese-language sites
MX present	88.5%	96.8%	84.1%	90.9%	65.2%	34.3%
SPF present	82.6%	91.6%	77.7%	85.6%	53.2%	36.8%
Multiple SPF records (RFC violation)	0.5%	0.6%	0.4%	0.5%	0.4%	0.1%
DMARC present	34.9%	41.8%	31.3%	35.7%	27.2%	12.1%
of which p=none	29.0%	35.5%	25.6%	29.8%	21.6%	7.5%
p=quarantine	3.8%	4.6%	3.3%	4.1%	1.4%	2.8%
p=reject	2.1%	1.6%	2.4%	1.9%	4.1%	1.7%
AAAA (IPv6) present	4.3%	3.0%	5.0%	4.6%	1.2%	39.2%

SPF is widespread at 82.6%, but DMARC is 34.9%, and most of it is p=none (a monitoring-only setting that does not have receivers reject spoofed mail). Among names with MX, only 6.0% have both SPF and a quarantine / reject DMARC. Since 2024 major mailbox providers have required DMARC of bulk senders, yet most .jp domains are in the state of either “DMARC record present but rejecting nothing” or “no DMARC”. 4.3% of names have an AAAA record on the registered name (reachable over IPv6) (Figure 13).

Figure 13 Adoption of email sender-domain authentication (SPF, DMARC, MX) and AAAA

13. WordPress and plugins

WordPress was identified on 33.0% of responding sites (gTLD Japanese-language sites: 16.9%). Picking up references of the form /wp-content/plugins/<name>/…?ver=x.y from the top-page HTML (first 256 KB), plugins were visible on 83.2% of the WordPress sites whose body was recorded, with an average of 2.87 per site. The most common was Contact Form 7 (49.0%), followed by WP-PageNavi (8.3%), the Japanese-made VK All in One Expansion Unit (7.9%), Smash Balloon Instagram Feed (7.1%) and Elementor (5.0%) (Figure 17).

Figure 17 WordPress plugins referenced from the top page (top 20)

For the 14 of the top 20 that have a product name (CPE) in the NVD, the ver= versions were matched against published CVEs. Sites referencing a version within range are 21.9% (70,728) of the WordPress sites whose body was recorded. ver= is the version of a script or stylesheet, which is usually the same as the plugin version but not always, so this too is an upper bound. No additional access, such as fetching readme.txt, was made.

Combining WordPress and PHP: 20.3% of WordPress sites announce a PHP version, and 47.8% of those are end of life (non-WordPress: 62.2%). HSTS is 7.4% on WordPress and 17.7% elsewhere (Figure 18).

Figure 18 PHP support status and headers, WordPress sites vs others

14. Comparison with Japanese-language sites on gTLDs

.jp alone does not cover the Japanese-language web. As a comparison sample, 131,622 .com / .net / .org domains whose site language had already been classified as Japanese were taken from the domain evaluation data the author has accumulated over many years as a registrar (SkyClear Co., Ltd., a JPRS-accredited registrar), and observed with the same method. It is a list of names that had backlinks in the past and includes classifications made long ago, so many names do not resolve in DNS (reachability 28.9%). Adoption is compared over the sites that resolved and responded (38,092). This is a comparison sample, not “the whole Japanese-language web” (Figure 15).

Figure 15 .jp vs Japanese-language gTLD sites (.com / .net / .org)

Responding Japanese-language gTLD sites have a WAF/CDN in front on 44.8%, about four times .jp (10.8%); HSTS was 16.0% (.jp 14.3%), and the EOL share among PHP-version-announcing sites was 38.0% (.jp 52.9%). Many Japanese-language gTLD sites sit on overseas CDNs or hosting, a different placement from .jp, which sits on domestic shared hosting.

By the registration country of the resolved IP address (the country registered with the RIR, which may differ from where the server is located), with CDN front-ends counted separately, 77.0% of responding .jp sites were on Japanese IPs and 10.8% on US IPs (gTLD Japanese-language sites: Japan 8.0%, US 25.9%, CDN front-end 44.8%) (Figure 16). A detailed breakdown by hosting provider will be covered in a separate piece (the hosting company report).

Figure 16 Where Japanese-language sites are located (by IP registration country; CDN front-ends counted separately)

15. Progress and next steps

Ledger coverage is 63.0% (1,197,208 / 1,901,067). This report is a full observation as of this point: 1,197,206 names observed, of which 1,052,121 responded (Figure 14). The ledger grows daily through CT log subscription and candidate generation; a second observation will be made at 80% coverage or in January 2027, whichever comes first, and will form the final report. The final report will add tallies of organisation type and region from full WHOIS retrieval, and will show the differences from the interim report (what moved as the population widened).

Figure 14 Progress (JPRS published count, ledger, observed, responding)

16. Limits and caveats

The population is the delegated names in the ledger, 63.0% of the JPRS published count. 80% of the ledger’s names come from the web graph and lean toward linked names. The roughly 40% not yet covered likely includes many names without a website.
Reachability is from the observation points (domestic connections); sites that did not respond because of geo-restrictions or bot protection count as failures. Unreachable hosts were not retried (only the single www. fallback).
Sites returning 403 are also counted as “reached”. Most 403s are the default response for a domain with no content, and the headers are those of the shared server.
CVE exposure is an upper bound based on version strings and cannot reflect back-ported fixes. Exploitation was not tested.
Values by NS provider are “the state of the sites of users who host their DNS with that provider”, not an assessment of the provider.
Entity type is at the stage where WHOIS has been retrieved for 37.0%, and only 3.2% of names could be matched.
The gTLD Japanese-language sites are a comparison sample, not a full count. The language classification is old and includes names that no longer exist.
The email metrics are the presence or absence of DNS settings; whether sender-domain authentication actually works was not verified.
No individual site or domain name is named in this report.

17. Method notes, disclaimer and FAQ

Is this an attack? No. Each domain received only the same access as opening the site once in a browser, plus lookups of public DNS information. No port scanning, vulnerability probing or path guessing was performed. The observation User-Agent identifies itself as Site Scouter (sitescouter.net).

How was “nearly all of .jp” collected? JPRS does not publish its zone file, so names were collected from the Common Crawl web graph, Certificate Transparency logs (CT logs), our own domain assets and candidates generated from dictionaries, place names and company names, and each was checked one by one against the .jp authoritative DNS for delegation. Lookups were kept to a rate that does not burden JPRS.

Why do the numbers differ from ranking-based surveys? Because the populations differ. Ranked names lean toward widely used sites, which are also better hardened. This report covers nearly all existing names, so adoption comes out lower. It is not improvement or deterioration.

Are the values by provider an assessment of the providers? No. The NS provider is where DNS is hosted, not necessarily where the website lives. Headers and version disclosure in most cases change with the site user’s configuration.

Can I check my own site the same way? Yes. Enter a URL in Site Scouter’s server information check to see TLS, HSTS, headers and version disclosure with the same non-intrusive method as this survey.

Can my site be excluded from the observation? Please contact us through Site Scouter’s contact form. It will be excluded from subsequent observations.