How we produced those numbers

Where the list came from

We took 1,028 Bulgarian business domains from OpenStreetMap - hotels, guest houses, dental clinics and law firms. It is not a random sample of the Bulgarian web: it is small and medium businesses with a physical address, which is exactly who this service is for. Anything concluded here applies to that group and not necessarily to anyone else.

What we actually did to each site

A passive, read-only check, on 27 August 2026, of what any visitor can already see. Fewer than ten requests per site - comparable to opening a couple of pages in a browser.

• the HTTP response, the redirect chain, and whether HTTPS works
• the TLS certificate, its issuer, its validity period and its expiry date
• response headers, including security headers and any software versions announced there
• cookie flags on the homepage
• whether robots.txt, a sitemap and a favicon exist
• first-response time and page size

What we never did

No login attempts, no password guessing, no injection or fuzzing of any kind, no exploitation of vulnerabilities, no port scanning, no aggressive crawling. Active security testing happens only against systems whose owner has authorised it in writing. That rule is not a courtesy - it is the difference between a health check and an attack.

How versions are detected

From what the site publishes about itself: response headers such as Server and X-Powered-By, and public page source - meta generator tags, asset paths and script fingerprints, using the open Wappalyzer fingerprint set. We never look inside anything that is not publicly served.

This has limits. A site can hide or misreport its version, and fingerprinting can be wrong. A detected version is evidence, not a certainty.

How end of life is decided

From endoflife.date, the public record of when each release line stopped receiving support. "PHP 7.4 stopped receiving security updates on 28 November 2022" is a published date anyone can verify, not our opinion.

One exception we handle deliberately: WordPress, Drupal and Joomla backport security fixes to old release lines, so end of life there means the end of feature support, not the end of security patches. We do not call those unsupported.

How CVEs are matched, and what critical means

Detected product and version are matched against the US National Vulnerability Database. Severity is whatever NVD publishes as the CVSS base severity - we do not assign our own ratings, and we do not reweight them to sound more alarming.

The important caveat: a version match does not prove a site can be attacked. Distributions routinely backport security fixes without changing the version string, and Bulgarian shared hosting very often runs distribution packages. So the correct statement is that vulnerabilities have been reported against this version, and that is the only claim we make. Confirming whether a specific site is affected would require testing it, and testing requires permission from the owner.

The numbers, and what was excluded

Of the 1,028 domains:

• 900 responded and were assessed
• 122 did not resolve at all - OpenStreetMap contains businesses that have since closed
• 6 were registered but the server did not answer
• 24 blocked our automated request and were excluded from the scoring, because a blocked scan is not a measurement
• median health score across the 876 scored sites: 73 out of 100
• 146 sites, 16% of those reachable, had at least one reported vulnerability against a detected version; 133 of those included at least one rated high or critical
• 75 sites ran at least one component past end of life, most commonly PHP 7.4

What would change these figures

This is one point in time, on one list, using detection that can be fooled. Sites that block automated requests are absent, which biases the sample towards sites that behave normally. We re-measure as the list grows, and if a number here moves we change it, rather than keeping the more impressive version.