Most break-ins don't use clever new tricks — they use old, published flaws in software nobody got round to updating. The moment a flaw is published, every attacker knows about it and you don't — scanning the whole internet for it takes hours, and nobody sends you a letter when you turn out to be running it. VulnControl closes that gap. It's a website vulnerability scan run from the outside — the way an attacker sees you — that identifies what you're actually running and tells you in plain language what to update, starting with the flaws being exploited right now.
No agent, no server access · Scans only websites you've verified you own · Part of the TrustCtrl platform
There's no agent to deploy, no server access to grant and nothing to configure. VulnControl maps your external attack surface — everything about your site that is reachable from the public internet — and then does the work of comparing it against everything the world has published about it.
The web server, the platform behind it, the services answering on open ports, and the JavaScript libraries your pages load — with versions wherever they can be established. This is worth something on its own: most owners simply cannot list it, and you can't protect what you can't name.
Every identified component and version is matched against our own copy of the national vulnerability database (the CVE list), refreshed nightly. Where a flaw appears in the official catalogue of vulnerabilities confirmed to be exploited in the wild, it's marked as such — the difference between theory and someone actually being attacked.
A curated port scan finds exposed database ports, remote access and admin panels answering the open internet, plus sensitive files left where anyone can download them — configuration files, backups, environment files with passwords in them. These are among the easiest ways in, and closing them is usually a quick fix.
A database port opened during a migration and never closed. A backup file dropped in the web root "just for a moment" two years ago. An admin panel reachable from anywhere because that was easier during the build. An environment file with live credentials, sitting one URL away from the public. None of this is negligence — it's what happens when a site is built quickly by a developer, an agency or an AI assistant, and nobody goes back to check the outside of the finished house. VulnControl is that check, repeated automatically.
An exposed database doesn't break your website — it works perfectly while it's exposed. There's no symptom to notice, which is exactly why these last for years.
Software that hasn't caused a problem gets left alone. But a version that was safe when it was installed becomes a published target the day someone finds a flaw in it — and nobody sends you a letter about it.
The WordPress vulnerability scan enumerates the plugins and themes your site loads, with versions where they're visible — the layer that's most often out of date and least often reviewed. Core software is matched more deeply than plugins; the technical page says exactly how far that goes.
Background reading: where WordPress risk actually lives, what a CVE identifier actually tells you, why scanners report flaws you do not have, and which ports should never face the public internet.
There are thousands of vulnerabilities. Only a fraction are actually being used in attacks right now. VulnControl cross-references your findings with CISA's Known Exploited Vulnerabilities catalogue — the authoritative list of flaws under active attack — and pushes those to the top, so you fix what matters first instead of drowning in noise. That's the finding an owner acts on the same day. Everything else can wait for whoever normally handles updates.
This sounds like hair-splitting. It's the whole difference between a usable report and an unusable one, and it's where keyword-based scanners fail in both directions. We learned both the hard way, and fixed both.
Vulnerability databases are usually searched by text — and searching for a product name returns flaws in that product, in its plugins, and in unrelated tools that merely mention it. Attributing all of those to you produces a page of critical findings that aren't yours. We match on the formal product identifier inside each vulnerability record instead. Found the hard way: an early version produced 110 false criticals against a single healthy web server.
The opposite failure is worse. Because the database was searched by text, real flaws were missed too — one major HTTP/2 vulnerability affects nginx, but its official write-up never uses the word, so a text search never found it. One customer site showed clean while an identical server showed real flaws. Both directions are fixed, and there's a regression test named after the incident.
Web servers are commonly configured to hide their version. When we can't establish one, we say so — we don't assume the worst, and we don't assume the best. A component we can't pin down is reported as unverified rather than quietly passing as clean.
Because you stop looking. That's the failure worth explaining to whoever evaluates this on your behalf, and it's the reason a "not checked" result here always says so rather than showing you a comforting green.
Because VulnControl already knows what software you run, comparing it against what the world has newly published is cheap. Every night the feeds are refreshed from the official sources, so when the next scan runs it's comparing you against today's knowledge — not against whatever was known the day the tool was built. Scans run on a fortnightly schedule, and you can trigger one by hand whenever you want a fresh answer.
Most of TrustCtrl is built so a business owner can act alone. VulnControl is one of the two that isn't, and we'd rather say so before you buy. The findings are written in plain language and tell you exactly which software to update — but updating a web server, closing a database port or moving a backup file out of the web root is work done by whoever runs your hosting. If that's your developer, your agency or your hosting provider, this gives them a precise, prioritised list. If nobody has that access, you'll get an accurate picture you can't act on.
You run your own server or VPS, a self-hosted WordPress site, or you have a developer, agency or hosting provider who can apply an update. You don't need security expertise — that's the part we supply.
Your shop is on a fully hosted platform like Shopify or Squarespace. The vendor patches the platform, so most findings won't be yours to fix — though exposed files and third-party scripts still can be.
VulnControl checks the running system from the outside. CodeControl checks the code and its packages from the inside. Together they cover both halves of the same question.
Plenty of tools will scan a website and produce a list of CVEs. Two things separate a list you can act on from one you'll ignore: whether the findings are actually yours, and whether the report is honest when it couldn't check something. Both are engineering decisions, both are documented on the technical page, and both are why our findings tend to be shorter than a cheap scanner's — and right.
It arrives as a supplier questionnaire, an insurance renewal, or a condition in an enterprise contract — because NIS2 requires the companies in scope to handle vulnerabilities, and they pass that requirement down to their suppliers. Most businesses answer from memory. VulnControl answers with a dated scan that names each piece of software, its version, and what was found against it.
A CVE is a public reference number for one specific security flaw in one specific piece of software — CVE-2023-44487, for example, is the HTTP/2 vulnerability that affected most web servers. Once a flaw has a number it sits in a public database anyone can read, including the people looking for servers to break into. VulnControl matches the software your website runs against exactly those numbers and tells you which of them apply to your version.
To know whether your website software is out of date, you first have to know what it is. VulnControl identifies what your site actually runs — web server, CMS, WordPress plugins and themes, runtime, JavaScript libraries — with versions where they can be established, and matches each one against a nightly-refreshed copy of the national vulnerability database. You get a finding per component that names the software, the version and what to do about it, with anything on the actively-exploited list pushed to the top.
No. There is no agent, no server access to grant and nothing to configure. VulnControl looks at your site from the outside, exactly as an attacker would. The only requirement is that you've verified you own the website — which the platform already asks for, and which we insist on before any scanning: probing a host you don't own isn't a service, it's a liability.
No — a vulnerability scan is not a penetration test. VulnControl does not attempt to exploit anything, log in anywhere, or send malicious input. It makes ordinary connections, reads what the services volunteer about themselves, identifies them and compares them against published vulnerabilities. It's the reconnaissance step an attacker takes first — run on your behalf, so you see what they'd see.
To understand it, no — every finding says what the software is, how serious it is and what to do. To act on it, someone needs access to the server or hosting: your developer, your agency or your hosting provider. We say so plainly before purchase, because a report you can't act on isn't worth paying for.
“Actively exploited” means the flaw appears in CISA's Known Exploited Vulnerabilities catalogue — the official list of vulnerabilities confirmed to be used in real attacks, rather than merely published. There are thousands of vulnerabilities and only a fraction are being used against anyone. Those are the ones worth interrupting your day for, so they're sorted to the top and marked.
It sees the outside, not the inside: software that announces nothing about itself, and anything not exposed to the internet, is invisible to it. Coverage is a curated list of widely-used products rather than every piece of software in existence, and low-severity flaws are deliberately not collected, to keep the report worth reading. It also reports that a version is unconfirmed rather than guessing. For the inside view of your own code and its packages, that's CodeControl.
Add your website, verify you own it, and VulnControl does the rest. No agent, no server access, no configuration. Part of the TrustCtrl platform.
Scans only websites you've verified you own · Full technical description