CWE-527 covers a CVS, git or other repository stored in a directory, archive or other resource that is stored, transferred or made accessible to unauthorized actors.
How it happens
Version control tools keep metadata in subdirectories, such as a .git or CVS folder. If those folders land on a web server, or get packed into an archive that you hand out, the metadata goes with them. A typical cause is deploying by copying a working directory, or building a release zip from a checkout.
MITRE says the exposed data can include usernames, filenames, the path root, IP addresses and detailed diff data about how files changed. Diffs can show source snippets that were never meant to be public.
What an attacker gains
MITRE lists reading application data and reading files or directories. Old commits can contain secrets that were deleted later but remain in history. Paths and names give a map for further attacks.
How to find it
The record lists no detection methods. Simple checks from outside:
- Request
/.git/HEADand/.git/configon your sites and see whether they return content. - Open each release archive and look for hidden version control folders.
- Add a check to your build that fails if one appears in the output directory.
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/.git/HEAD
A 200 response means the repository metadata is reachable.
How to fix it
MITRE's recommendations are to remove CVS directories and repositories from the production server, disable use of remote CVS repositories, and make sure the latest patches and updates are applied. The same logic applies to git.
- Deploy built artifacts, not working copies.
- Exclude
.gitand similar folders in packaging rules. - Block those paths in the web server configuration as a second line.
- If a repository was exposed, treat any secret ever committed as compromised and rotate it.
Quick check
Why rotate secrets after an exposed repository?
History can hold secrets that were removed from current files but remain readable in old commits.
