Know your site's stack, get the fix in a day

Ask the owner of a small business website what it runs on and you will usually get one of two answers: "WordPress, I think" or "the agency built it." Neither is a version number, and the version number is what decides whether last week's advisory applies to you. This post covers two things CyberSpec now does about that: naming the frameworks and CMSs on your verified sites, and emailing you once a day, only when something is new, with how to fix it.

Why "what does it run on" is the first security question

Most compromises of small sites do not start with anything clever. They start with known software at a known-vulnerable version: a CMS core a few releases behind, a plugin abandoned by its author, a JavaScript framework release with a published advisory. The WordPress REST API RCE we wrote up is a typical shape: the fix existed, and the sites that were hit were the ones whose owners did not know they were on the affected branch.

You cannot patch what you do not know you are running. Agencies hand over sites and move on, staging copies outlive the project that needed them, and a marketing landing page built on a different stack from the main site gets forgotten. The stack is part of your external attack surface whether or not anyone wrote it down.

How the detection works

On a full scan of an asset you have verified, CyberSpec runs Nuclei's community-maintained technology templates against every web service the network scan found. They are detection-only: they read what the server returns (response headers, the HTML of the page, well-known asset paths such as /wp-content/ or /_next/) and match it against known fingerprints. No exploit, no login attempt, nothing that changes the site.

Each technology recognised becomes its own entry in your findings, for example:

Detected WordPress 6.1.1 on example.co.uk:443/tcp
Detected next.js on app.example.co.uk:443/tcp

The version is included when the site gives it away, and many sites do. When it is not exposed, you still get the name, which is enough to know whose security advisories to watch. Detections are recorded at info severity, because running WordPress is not a vulnerability. Running a WordPress release with a published CVE is, and that shows up separately as a finding with its own severity.

Two limits are worth stating plainly:

• Only on assets you have verified. Ownership is proved by a DNS record or a file on the site before anything is scanned. We do not fingerprint sites that are not yours.
• Detection is not yet an "outdated" verdict. CyberSpec already flags end-of-life versions of network services such as web servers and databases (why that matters). Comparing a detected CMS or framework version against its vendor's support calendar is the next step, and we will say so when it ships.

The daily email: what's new, and how to fix it

Findings in a dashboard only help if someone opens the dashboard. Most small teams will not log in to a security tool every morning, and they should not need to. So CyberSpec now sends a daily digest to the owners of each organisation, on by default:

• Only when something is new. If nothing changed since the last digest, nothing is sent.
• At most one a day. A new issue reaches you within about a day of the scan that first saw it.
• Worst first. Critical down to low, each with where it is (host and port) and how to fix it.
• Newly detected software gets its own section, so a site you had forgotten about shows up as news, not as a line in a report three months later.

The fix text is the scanner's own remediation guidance. If someone in your team has already used Explain this in plain English on that finding, the email uses that explanation instead: a short AI-written summary of what the finding means, why it matters and the steps to fix it, based only on what the scanner reported. That explanation is labelled as AI-written in the portal and should be checked against the vendor's advisory before you act. It never includes your hostnames or company name when it calls the model.

An owner can turn the digest off for the whole organisation in Settings → Notifications. Instant alerts by email, Slack or webhook are still there for teams that want a message the moment a critical finding appears.

Why a day is the right window

Faster sounds better, but an email for every finding as it lands is how alerts end up filtered into a folder nobody reads. A single daily summary is short enough to read and fast enough to matter. The time that hurts small organisations is not the hours between a scan and an email. It is the months between an advisory and someone noticing it applies to them, the same gap annual pentests miss.

For anyone working toward Cyber Essentials, that window is also the one the scheme judges: updates the vendor rates critical or high, or that fix a vulnerability scoring 7.0 or more, must be applied within 14 days of release. A daily digest gives you most of those 14 days to act, instead of finding out at renewal.

What CyberSpec does, and what it does not

CyberSpec is continuous external scanning for teams without a security department: verified assets, scheduled scans, findings scored and explained, and a Cyber Essentials readiness view. The framework detection (on full scans) and the daily digest described here are live today. CyberSpec reports readiness; it does not certify, and it is not a substitute for a penetration test.

The decision for you is simple: either you find out what your sites are running from your own tooling, on a day that suits you, or you find out from someone else's scan. Only one of those comes with time to fix it.