Exposed .git and .env Files: How MSPs Find Them on Customer Websites

A .env file holds environment variables — database credentials, API keys, signing secrets — that the application reads at startup. A .git directory holds the full version-control history of the project. Neither is meant to be served to a browser; both are meant to sit alongside the application code, readable only by the deployment process itself.

They become public the same way, over and over: the web server's document root is pointed at the whole project directory instead of a dedicated public folder, or a deploy script copies the entire repository — including its .git history — straight onto a production server. Neither mistake produces any visible symptom. The site works normally. The only difference is that a request to the right path now returns something it should not.

Environment files typically hold exactly the credentials an attacker wants most: database username and password, API keys for payment processors and third-party integrations, SMTP credentials capable of sending mail as the customer's domain, and application secrets used to sign sessions or tokens. A single request that returns this file is equivalent to handing over a working set of production credentials.

There is no partial exposure here — either the file is reachable and its full contents are readable, or it is not reachable at all. That makes it one of the highest-severity findings in an external review relative to how simple it is to check for.

A reachable .git directory is not just a copy of the current source code — it is the entire commit history, which can be pulled down and reconstructed with standard tools. That matters because secrets get committed by mistake far more often than they get left in current code: an API key hardcoded during testing, a credential pasted into a config file and fixed two commits later. Removing a secret from the current version of a file does not remove it from history.

A full history download also hands over application logic, internal comments, and structure that make every other vulnerability easier to find. Treat a confirmed exposed .git directory as a full source and history disclosure, not a minor configuration issue.

The check is a small set of direct requests, nothing more: request the site root plus /.env and read the response. Recognizable environment-variable syntax — an uppercase key followed by an equals sign — confirms exposure. A 404 or a generic error page confirms it is not reachable.

For .git, request /.git/HEAD and /.git/config. A live repository returns Git's internal file formats — a ref pointer for HEAD, a recognizable config structure — rather than a 404. Neither check requires credentials, exploitation, or anything beyond a standard read request, which is exactly why it belongs in a routine, non-invasive scan rather than something that needs special authorization to run.

Exposed source control and environment files are one category inside a broader web-application exposure review, alongside publicly listed directories, reachable backup archives, and staging environments left accessible. None of these require the customer to have declared them as assets first — they are found by requesting known paths across every site already registered for monitoring, not by scanning blindly.

A leaked credential also feeds directly into the next question: what could an attacker reach with it, and does any technology it exposes have a known vulnerability. See security findings for how this severity gets ranked against everything else found for a customer, and CVE alerts for MSPs for how detected technology gets correlated against current vulnerability intelligence.