CheckRoostCheckRoost
Getting started

Known vulnerabilities

Published security flaws, matched against the exact versions each of your sites runs — and what it takes to get each kind of site covered.

A known vulnerability is a fact somebody has already published: this version of this software has this flaw, and that release fixes it. CheckRoost reads those records, compares them with the versions your sites report, and lists every match on the Vulnerabilities page and on the monitor it belongs to, with the update that fixes it.

Where the records come from

  • PHP The PHP project’s own security advisories, which name the fixed release on every supported line — 8.3.36 fixes a flaw on 8.3 that 8.4.27 fixes on 8.4.
  • WordPress, plugins and themes Wordfence Intelligence, where it is switched on; the Vulnerabilities page says whether it is.
  • Packages your apps ship OSV.dev, the open database that gathers GitHub’s security advisories, npm’s, Packagist’s and others — for apps that use npm or Composer.
  • Lines past their end of life endoflife.date’s support schedules for PHP, Node.js, Next.js and Ubuntu. A line that has stopped receiving security fixes is listed, and so is one that stops within ninety days — unsupported is a finding before any flaw is published. A Linux distribution’s own PHP is left to that distribution’s schedule.
  • Abandoned plugins WordPress.org’s plugin directory, for every plugin a site reports: one WordPress.org has closed (a security issue is rated high; any other reason is unrated) or one nobody has updated in two years. A plugin the directory never listed, such as a premium one, is not judged.
  • Ubuntu packages Ubuntu’s own security notices, through OSV.dev, for every source package the server agent reports once a day — so a server’s PHP, OpenSSL or nginx is judged by the distribution that patches it. Only a flaw with a released fix is listed: it is an update waiting to be installed.
  • Node.js itself Node.js’s own list of flaws in the runtime, with the release that fixes each on every line, and its release schedule — for the Node version a running app reports through the Next.js package.
  • Being exploited CISA’s catalogue of vulnerabilities known to be used in real attacks. A match on it is marked, and sorted first.

The records are read every six hours, and every site is matched against them every hour.

Where each site’s versions come from

A site is only checked if something reports what it runs. Which source that is depends on the kind of site:

  • WordPress The CheckRoost plugin reports the exact PHP and WordPress versions and every plugin and theme. It is the most complete source and is always preferred.
  • WordPress on Kinsta or SpinupWP, without the plugin Connect Kinsta or SpinupWP and the host reports the PHP and WordPress versions, and Kinsta its plugins and themes. Hosts report PHP as a line — 8.3 — rather than the exact release, so it is listed but cannot be judged; install the plugin to close that gap.
  • Any site whose server names its PHP Many servers say which PHP answered in a response header — X-Powered-By: PHP/8.3.30 — and the uptime check already reads it, so a site with nothing else reporting is still judged: an Azure App Service, a server somebody built by hand. Where neither the plugin nor a host reports WordPress, the page’s own generator tag is used. Each finding says which of these it came from, and the plugin always wins where it reports.
  • A Next.js app you deploy The Next.js package reports exactly what is deployed: the Node, Next.js and React versions and every package the app ships. The Node version is checked too, so an app left on an old release is caught even when none of its packages are.
  • Any app with its code on GitHub Connect GitHub and the lockfile in each repository is read — npm, pnpm or Composer. It shows what is in the code, which can be ahead of what is deployed, so a running app’s own report wins where both exist.
  • The server underneath The server agent reports which Ubuntu packages — PHP, Node, nginx, OpenSSL among them — have security updates waiting. That is shown on the server’s page as updates to install, rather than matched against these records.

Unknown is never clean

A site that reports no versions has no matches because nothing was checked, not because nothing is wrong; the Vulnerabilities page says how many of your sites are covered. A version that cannot be compared is named rather than passed: a Linux distribution’s own PHP build (8.1.2-1ubuntu2.27) carries fixes its version number does not show, and a host’s 8.3 leaves out the patch level that decides it.

When something is found

Each monitor shows one line per piece of software, with the update that fixes all of its known flaws — “Update PHP to 8.5.12 or later” — and the full advisories are a click away. A match is closed the next time the site reports a version outside it, and a site that stops reporting is never treated as fixed. Fixes from the last thirty days stay listed on the Vulnerabilities page.

A PHP or Node.js version past its end of life is treated with care: if an advisory reaches back as far as the oldest line still supported when it was published, an older line is marked Likely rather than certain — no release will ever fix it there, and the remedy is a supported version.