Vulnerabilities
What a passive security scan can and cannot prove about your site.
Published 2026-04-09 · Last updated 2026-04-09 · Vantyris editorial
If a security scanner says 'WordPress login reachable without rate-limiting', what does it actually know? A passive external scanner reads what's already publicly visible: DNS records, response headers, certificates, HTML, REST endpoints, exposed paths. It cannot see your server-side rate-limiting rules, your Cloudflare bot-protection settings, or whether 2FA prompts appear after the password step. Those controls are usually present but invisible from outside. This article explains where that boundary sits, so you can read passive-scan findings without either dismissing them or panicking.
What this means for your business
- A passive scan is high-confidence about anything that's visible in the network response: TLS protocol versions, the certificate chain, response headers and their values, DNS records (SPF / DMARC / DKIM / CAA / DNSSEC), CT-log subdomain history, the content of HTTP(S) responses to known paths.
- It's medium-confidence about anything that requires inference: whether server-side rate-limiting exists (only visible after enough failed attempts to trigger it), whether a WAF is in line (some are silent unless a specific rule fires), whether 2FA is enforced post-password (the password step happens before 2FA shows up).
- It's low-confidence about anything that requires authenticated access or active exploitation: actual user data exposed inside an admin panel, whether SQL injection on a particular parameter actually works, whether a CVE flagged from a version banner is exploitable in your environment.
- Vantyris labels every finding with a confidence rating (high / medium / low). Findings touching the medium-confidence boundary carry an explicit 'what this passive scan cannot prove' caveat in the evidence pack, so you know what to verify before acting.
How to fix
Read passive-scan findings as 'flagged for confirmation'. If you already enforce the relevant server-side control, mark the finding 'Accepted as known risk' with a written reason, and the workflow records the decision. If you don't enforce the control, fix it.
- Identify the confidence band of the finding. Open the finding in the report. The evidence pack header shows confidence: high, medium, or low. Medium-confidence findings always carry a 'Caveats' line that explains the boundary, meaning what the scanner saw versus what it cannot see from outside.
- If you already enforce the control, mark as Accepted. Click the finding's status, choose 'Accepted as known risk', and write the reason: 'WAF rules block /wp-login.php after 5 attempts per IP per 60 seconds; Wordfence 2FA enforced on every admin account; Cloudflare bot-protection rule confirmed via test on YYYY-MM-DD.' The workflow records the decision and the reason.
- If you don't enforce the control, fix it. Add the missing layer. For
/wp-login.php, install Wordfence (rate-limit + 2FA), move the URL with WPS Hide Login, or enable a Cloudflare WAF rule against the path. The remediation entry in the finding card names the specific layered hardening. - Re-run the scan. Vantyris can't re-test the server-side control from outside. That's the whole point of this article. What a re-run does verify is that the public surface hasn't changed (the page being reachable, the lack of visible 2FA hints). The 'Accepted as known risk' state with its written reason is the audit trail.
Owner: Site owner reviews the finding. Whoever runs the server-side controls implements them. · Time: Reading the finding: 2 minutes. Acceptance with reason: 5 minutes. Adding a control if missing: anywhere from 15 minutes to an afternoon.
Common gotchas
- Don't dismiss a medium-confidence finding just because you 'think' the control is in place. Test it. Try five wrong-password attempts on
/wp-login.phpand confirm rate-limiting kicks in, or check the Cloudflare logs after a synthetic bot run. - Don't accept findings without writing the reason. A blank acceptance is worse than no acceptance, because it tells a future reader nothing about what was actually checked.
- Don't expect Vantyris to retract the finding once you've enforced the control. Passively, we can't see the control. The Accepted-as-known-risk status with the reason is how the report records 'this is fine, here's why'.
- WAF / rate-limit absences sometimes ARE detectable passively, but only via an active probe (multiple failed login attempts) that we don't run. The Vantyris methodology is explicit about this. No active probing of authentication surfaces. We flag, you verify.
How to verify the fix
Read the finding card and look for the confidence rating and the 'Caveats' line in the evidence pack. If you've enforced the control, the verification happens server-side: check the WAF / plugin logs, run a synthetic test, then mark the finding accepted. If you haven't, add the control and re-scan to confirm the finding's public surface still reads consistently.
Common follow-up questions
Why doesn't Vantyris just try ten wrong passwords to test rate-limiting?
Two reasons. Legal: actively testing authentication boundaries on a third-party service crosses into 'unauthorised access' territory under the UK Computer Misuse Act 1990, even with the site owner's consent for the scan itself. Practical: it would generate alerts in your WAF, IDS, and SIEM, and create exactly the kind of false-positive incident-response work that wastes your operations team's afternoon.
Is there a way to do active testing if I want it?
Yes, but not via Vantyris. Active authentication testing is the territory of a penetration test: a human-driven engagement, scoped against a specific application, with written authorisation and a rollback plan. We refer customers to credentialled pen-testing firms when active testing is the right call. Vantyris is the right tool to keep the hygiene-scan baseline current between pen tests, not to replace them.
Are 'medium confidence' findings less important than 'high confidence' ones?
Not necessarily. Confidence is about how certain we are the finding describes reality. Severity is about how bad the finding is if it's real. A medium-confidence Critical (e.g., a CMS version disclosure suggesting an outdated install) is still urgent. Verify the actual version internally and patch it. Don't dismiss it.
What about findings that are wrong?
Passive scanning has a false-positive rate. We tune for it by preferring medium confidence over a higher rating when scanners disagree. If a finding is wrong, use 'Mark as Ignored with reason' to suppress it while we review the rule. Every suppression with a reason flows back to the rule maintainer.
References
- NCSC: Vulnerability scanning vs penetration testing NCSC
- OWASP: Testing for weak authentication OWASP
- Computer Misuse Act 1990 Vendor
Related explainers
Want Vantyris to check your domain for this and 196 other problems?
The teaser scan is free and needs no card. A verified scan starts at $10€10£10A$15¥1,500AED 40 and comes with the workspace: finding workflow, score trend, three PDF layouts, share links and monitoring.
Written by Vantyris