Server vulnerability scanner
Finds what the web server gives away: leaked configuration and backups, open directories, software versions in the headers, outdated TLS, risky endpoints and DNS mistakes.
Most break-ins do not start with a clever zero-day. They start with something the server hands out to anyone who asks: a forgotten .env file, a backup archive in the web root, a software version in a header that points straight at a known vulnerability. The server vulnerability scanner looks for exactly these weak spots — the ones that automated attack bots also look for, every day, on every public address.
What the scanner checks
Leaked files and secrets. The scanner requests the addresses where deploys most often leave things behind: .env and other configuration files, the .git folder, database dumps, .zip and .tar.gz archives of the site, a wp-config.php backup, .DS_Store, phpinfo and server-status pages. A finding is reported only when the response content confirms it — a real .git/HEAD, a real list of variables — so a site that answers "200 OK" to every address does not produce false alarms.
Open directories and source code. Directory listing turns a folder into a public catalogue of everything ever uploaded to it. Public JavaScript source maps hand over the unminified code, comments and internal paths included. Both are easy to switch off and both are reported with the exact address.
Software versions in the headers. Headers like Server: Apache/2.4.29 or X-Powered-By: PHP/7.2.5 tell an attacker which known vulnerabilities to try first. The scanner lists every header and page fragment that publishes an exact version and shows how to hide it in the server configuration.
Protocols and encryption. We check which TLS versions and which kinds of certificates the server accepts, whether the certificate chain is complete, whether plain HTTP redirects to HTTPS and whether the server supports HTTP/2 and HTTP/3. Old protocols are a vulnerability in themselves and a frequent reason for failing PCI DSS and similar audits.
Dangerous methods and cross-origin access. A server that answers TRACE or reflects any origin in Access-Control-Allow-Origin together with credentials can be used against your own visitors. The scanner sends harmless test requests and reports what came back.
CMS endpoints. For WordPress sites we check the routes that answer to anyone: the REST route that lists every author's login name and xmlrpc.php, the endpoint password-guessing tools use because it allows hundreds of attempts in one request. For other platforms we look for exposed admin and installation pages.
DNS and the perimeter. Wildcard DNS records, dangling CNAME records pointing at services that no longer exist (a classic subdomain-takeover scenario), missing CAA records, the state of DNSSEC and IPv6 — everything that describes how the domain itself is set up.
A safe scan
The scanner does not exploit anything. It does not guess passwords, does not send attack payloads, does not try to bypass authentication and does not overload the server: requests are few, spread out and identical to those a normal browser makes. It is therefore safe to run against a production site in working hours. At the same time it means the scanner finds configuration weaknesses and leaks, not bugs deep in the application logic — those require a penetration test with your permission and access.
What the report looks like
Each finding has a severity — critical, high, medium or low — and comes with an explanation in plain language: what exactly was found, at which address, what an attacker could do with it and how to close it. Where possible the fix is given as ready-made configuration for nginx, Apache or the platform. Critical findings, like a downloadable .env or .git, are shown at the very top, because they need to be closed today rather than in the next sprint.
Regular checks
A server is not configured once and for all: a new release, a plugin update or a hosting migration can bring an old problem back. Add the site to monitoring and the scan is repeated automatically; a new critical finding arrives as an email or a Telegram message. Through the API the same scan can be run from CI after every deploy, so a leaked file is caught before a bot finds it.
Order this audit
Tell us the site address and what worries you. A specialist runs the audit, checks every finding by hand and sends you the report with a prioritised list of fixes.