What automated scanners actually probe for on a new VPS

Point a fresh VPS at a public IP and, within hours, it starts receiving requests from tools like curl running through automated scripts — not a targeted attack, just internet-wide scanning that hits every reachable IP eventually. Looking at what these requests actually ask for is a fast way to know which easy wins are worth closing first.

The usual targets

• .env files. Scanners request this by default on nearly every framework, hoping a misconfigured deploy left database passwords or API keys sitting in a web-accessible directory.
• .git/config. If a repository was cloned directly into a web root instead of deployed properly, the full commit history — sometimes including old secrets — becomes downloadable file by file.
• .aws/credentials. A generic guess that costs the scanner nothing, aimed at catching cloud credentials left in a predictable path.
• Backup and swap files — config.yaml.save, .swp, ~ suffixes. These target files an editor leaves behind, on the chance a real config file got backed up in a public directory by accident.
• Framework-specific exploit paths, regardless of what the server actually runs. A common one: vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, a known remote-code-execution path (CVE-2017-9841) from an old PHPUnit version — sent as a POST request even against servers that have never run PHP.
• URL-encoded path traversal (%2e for ., %2f for /) — an attempt to slip past simple string-matching filters that only check for the literal characters.

Why the requests don't care what you're actually running

These scans are templated: the same list of a few hundred paths gets thrown at every IP found, regardless of the actual stack behind it. A Node.js app getting probed for WordPress plugin endpoints or Laravel debug routes isn't a sign of anything specific — it's the scanner not bothering to fingerprint the target first, because throwing the whole list is cheaper than being selective.

What actually matters when this shows up in your logs

• Response code, not request volume. A wave of requests hitting these paths and getting 404 means nothing is exposed. The response is the signal, not the fact that someone asked.
• Never serve a 200 for unmatched paths. Some app setups return the homepage (200) for any unrecognized route as a fallback. It's not a leak by itself, but it also means logs can't distinguish "nothing there" from "found something" without checking the actual response body.
• Keep secrets out of the web root, period. .env, credentials files, and .git directories should never be reachable by HTTP in the first place — that's a deployment practice, not something a firewall rule fixes after the fact.

Recommended next step

If these requests show up in your own access logs, the useful question isn't "am I under attack" — it's "did any of these return something other than a 404." That single check tells you whether it's background noise or an actual exposure to fix.

View Host-C VPS plans or return to the Host-C homepage.