Five steps, all of them passive

Everything the scanner learns about a site, the site already shows to every visitor. Nothing is tested, guessed or forced.
  1. 1DiscoverPublic rankings and links
  2. 2FingerprintPassive reads only
  3. 3MatchNVD, KEV, EPSS
  4. 4NotifyOne automatic email
  5. 5PatchThe owner updates

1. Discover

In short

The scanner starts from public lists of popular websites and follows the links it finds on them.

The scanner works through public domain rankings (the Majestic Million, Tranco and Cisco Umbrella top lists), plus domains found in outbound links on pages it has already read and host names a site lists in its own TLS certificate and Content-Security-Policy. Once a domain has been visited it goes into a ledger and is never picked up again, whichever list or link it turns up in next.

2. Fingerprint, passively

In short

It opens a few public pages of the site, just like a browser would, and notes which software versions they mention.

The scanner only makes ordinary browser-equivalent GET requests (homepage, public metadata like readme.html, security.txt, response headers). No exploit attempts, no vulnerability verification, no aggressive scanning, no authentication bypass — ever. Each domain is visited once, a handful of requests, then never revisited.

A visit can include these requests, each a plain GET:

  • The homepage: response headers such as Server and X-Powered-By, cookie names, the generator meta tag, version strings on asset URLs, and the TLS certificate.
  • The version file the CMS ships publicly: readme.html on WordPress, CHANGELOG.txt on Drupal, the joomla.xml manifest on Joomla.
  • On WordPress, the public readme.txt of common plugins already referenced in the page.
  • One request for a page that doesn't exist, to read the error response, and a check for leftover PHP diagnostic pages at common names such as /info.php.
  • /.well-known/security.txt and the site's contact page, to find where to send a notice.

No forms are submitted and no login pages are touched.

3. Match against public databases

In short

It checks each version against public lists of known security holes, and how dangerous each one is.

  • NVD: CVEs whose affected version range includes the observed version, with CVSS scores.
  • CISA KEV: whether a CVE is in the Known Exploited Vulnerabilities catalog, meaning it has been used in real attacks.
  • EPSS: FIRST's estimate of how likely a CVE is to be exploited in the next 30 days.
  • endoflife.date: whether the release still gets security fixes at all.

Each match is labeled likely, conditional (it needs a module, setting or build the scan can't see) or unlikely. Only sites where the matches add up to a serious risk go further; the rest are recorded and left alone.

Where this can be wrong

Version-based matching can be wrong. Linux distributions such as Debian, Ubuntu and Red Hat backport security fixes without changing the version number, so a server can report a vulnerable version and still be patched. A notice may occasionally reach an operator who has already fixed the problem. When the version string points to a distribution build, the notice says so and marks those CVEs as conditional.

4. Notify

In short

It emails an address the website publishes itself, explaining what it saw and what to update.

The notice goes to the Contact line in the site's security.txt, or, if it has none, the address on its contact page. A site that publishes neither gets no email. No bought lists and no guessed addresses. Notices are generated from the scan evidence and sent automatically from notice@patchnotice.org.

Safeguards

  • Only sites whose matches add up to a serious risk get a notice.
  • One notice per domain. No reminders and no follow-ups.
  • The opt-out list is checked before every visit and every email, subdomains included.
  • A reply saying “stop”, the unsubscribe link in the notice and the opt-out form all update that list automatically, and take effect immediately.
  • Replies are forwarded to me.

Each notice cites what was observed and where, the CVEs with CVSS and EPSS context, whether each is in CISA's KEV catalog, and the release to upgrade to. A shortened example, for a made-up site with real CVEs:

Subject: Security notice for example.org: outdated software with known CVEs

What was observed (from public pages and headers your server
sends to any visitor; no exploitation was attempted):
  - example.org: /CHANGELOG.txt reports Drupal 7.57
  - example.org: Server header reports Apache/2.4.52 (Ubuntu)

Based on those versions, example.org may be exposed to:
  - CVE-2018-7600; CVSS 9.8; known to be actively exploited
    (CISA KEV); in Drupal 7.57; Drupal 7 is end-of-life
  - CVE-2024-38475; CVSS 9.1; known to be actively exploited
    (CISA KEV); in Apache 2.4.52; note: Ubuntu backports fixes,
    verify the build

Reply "stop", or use the unsubscribe link, and example.org
won't be checked or emailed again.

5. The owner patches

In short

The site owner installs the update. That's the whole point.

Usually the fix is an update: a newer CMS release, a current PHP branch, or the distribution's security updates for the web server. There's nothing to reply to: the scanner doesn't come back on its own, so there's no follow-up either. If the notice was wrong, a reply tells me, and helps fix the matching. To stop hearing about a domain, opt out.