What our scanner does,
and the rules it runs under.
VulnVerify scans a domain only after its owner has proved control of it and recorded an authorization. This page describes that scanner: what it looks at, how hard it pushes, where its traffic comes from, and how to stop it.
Seeing this User-Agent in your logs?
VulnVerify-Scanner/1.0 (+https://vulnverify.com/scanning)That is VulnVerify's scanner. A User-Agent can be copied by anyone, so compare the source address with the egress addresses below. If you did not expect the traffic, email security@vulnverify.com.
Four steps, in this order
One run covers the verified registrable domain and the hosts under it. Nothing else.
- 01Discovery
Passive subdomain discovery
Hostnames under the verified domain are collected from passive sources only: public records that already list them. The scanner does not guess names against your DNS servers, so there is no DNS brute force and no zone walking.
- 02Liveness
A light probe of each host
Each hostname gets a lightweight HTTP and HTTPS request to see whether anything answers: every host discovery found, plus any host where an earlier scan of the domain found something — up to 2,000 hosts in one scan, those with earlier findings first. Any beyond that are not probed or checked in that scan, and its report lists them as not tested. Hosts that answer are checked at the address that answered. Hosts that do not are still checked by name, because a dangling DNS record or a service that only speaks TLS does not answer a web request. An open finding on a host that no longer answers is marked as host gone, never as fixed.
- 03Checks
Critical, high and medium severity only
Hosts are checked with vulnerability templates rated critical, high and medium. Low-severity and informational templates are not run, and a template in any excluded category below is skipped whatever else it is tagged with.
- 04Cadence
Weekly, with each fix tested again
A domain is queued for scanning only after it has been both verified and authorized; neither step on its own adds it to the schedule. The first scan is free. After that, the domain is scanned once a week for as long as scanning is enabled for it and the account's plan includes weekly scanning. Every open scan finding is tested again on the next run, so a fix you ship shows up as verified in the next report instead of as a box someone ticked.
A bounded rate, and no intrusive tests
The platform hands the scanner these limits with every run. They are the same numbers the consent text below refers to as the safe profile.
| Limit | Value |
|---|---|
| Severities tested | critical, high and mediumLow and informational templates are not run. |
| Request rate | at most 50 requests per secondAcross the whole run, not per host. |
| Concurrency | at most 10 templates in parallel |
| Per-request timeout | 10 seconds |
| Failing hosts | dropped after 30 errorsA host that keeps failing is left alone for the rest of the run. |
| Subdomain discovery | passive sources only |
| Cadence | weekly |
| Profile version | safe-1 |
Excluded categories
A template carrying any of these tags is never run, whatever else it is tagged with.
- Denial-of-service
dos - Fuzzing
fuzz - Brute-force
bruteforce - Intrusive checks that may change data or state
intrusive - Denial-of-service attacks
dos-attack - Default-credential login attempts
default-login
Fixed in the scanner
These are not settings. They are built into the command lines the scanner runs, and nothing the platform sends with a run can turn them on.
Redirects are not followed
Every request goes to a host that passed the scope filter. A redirect can point anywhere, including outside the verified domain, so the scanner does not follow one.
No out-of-band callbacks
Checks that work by making the target contact an outside callback server (interactsh) are switched off, so no third party learns which of your hosts responded to what.
No headless-browser, code-execution, DAST (fuzzing) or local-file templates
These template types are never loaded: the scanner does not pass the options that enable them, and they are removed from the template set it carries.
Passive subdomain discovery only
No DNS brute force, no zone walking and no guessing of names: only hostnames public sources already list, plus hosts where an earlier scan of the same domain found something.
Default credentials are never tried
Templates that submit a vendor's default username and password to a login form are excluded by tag (default-login), even when they are also tagged as a known-CVE check.
A hard filter on every host
A domain is claimed at the registrable level, so scope is that domain and the hosts under it. Anything else is dropped before a packet is sent, and every result is checked again by the platform: a batch that names any host outside the claimed domain is rejected whole.
| Host | Verdict | Why |
|---|---|---|
| example.com | In scope | The verified registrable domain itself. |
| www.example.com | In scope | A host under it. |
| api.eu.example.com | In scope | A host any number of levels under it. |
| example.org | Dropped | A different registrable domain. |
| myexample.com | Dropped | A lookalike that only ends in the same letters. |
| example.com.attacker.net | Dropped | A different domain that starts with the same name. |
| 203.0.113.10 | Dropped | A bare IP address. |
A bare public suffix or a shared platform's own domain cannot be claimed at all. Appearing in VulnVerify's findings database does not make a domain a scan target either: only a domain its owner has claimed, verified and authorized is ever scanned.
Where the traffic comes from
Every request carries the User-Agent shown at the top of this page and leaves from the addresses below.
Scanner source addresses
169.58.207.231
This list is read from the scanner's configuration each time this page is served.
Proof of control, three ways
Before anything is scanned, the customer proves they control the domain. Any one of these methods is enough.
DNS TXT record
Publish a TXT record at
_vulnverify-verify.<domain>with the value
vulnverify-verify=<token>The same record at the domain apex is accepted too. It is looked up through public resolvers.
HTTPS file
Serve a file whose only content is the token at
https://<domain>/.well-known/vulnverify-verify.txtor
https://www.<domain>/.well-known/vulnverify-verify.txtRedirects are not followed, so the file has to be served by the domain itself.
Role mailbox email
A single-use link, valid for 24 hours, sent to one of these addresses at the domain:
admin@administrator@hostmaster@postmaster@webmaster@security@
Opening the link verifies nothing. A person has to confirm on the page it opens, so a mail gateway that pre-fetches links cannot verify a domain on its own.
Two ways to stop a scan
Scanning stops at the request of the domain's owner, and we want to hear from anyone who received traffic they did not expect.
If it is your domain
Press Pause scanning on the domain in Domains to take it out of the schedule, or remove the domain to end its authorization. You can also email security@vulnverify.com.
If you did not expect the traffic
Email security@vulnverify.com with the time, the source address and the host that received it. We will stop scanning the domain concerned while we look into it.