Home / Core Health / Block access to .svn and .hg version control directories
Exposed Files · Scan Check Guide

Block access to .svn and .hg version control directories

15 min Impact: medium Effort: low ✓ Scan-verified — no manual checkbox

Beyond Git, other version control systems (Subversion's .svn, Mercurial's .hg, Bazaar's .bzr) leave similar metadata folders that can expose your source history if they're accidentally left in a public web root — less common than exposed Git repos, but just as revealing when present.

Same risk as an exposed .git directory, for Subversion and Mercurial — anyone who finds it can potentially reconstruct your source code and history.

The full picture

Exposed .svn and .hg directories represent the same category of vulnerability as exposed .git directories discussed elsewhere in this security work, applied to Subversion and Mercurial version control systems specifically — these directories can reveal your complete version control history, including potentially sensitive information from past commits even if later removed from current code.

The genuine risk profile here mirrors the .git exposure discussed elsewhere closely — an attacker gaining access to these directories can potentially reconstruct your complete development history, including any credentials, sensitive comments, or other information ever committed to the repository, even content that's since been removed from the currently deployed codebase.

While Git has become the more dominant version control system in current development practice, sites still using or historically having used Subversion or Mercurial remain genuinely vulnerable to this same exposure pattern if these legacy version control directories weren't properly excluded from the publicly accessible web root during deployment.

Remediation follows the same approach discussed for .git exposure — confirming these directories are genuinely inaccessible from public web access, and reviewing what sensitive information might have been exposed throughout the repository's history if this vulnerability existed for any meaningful period, treating any exposed credentials or sensitive data as compromised regardless of their presence in the current codebase.

How to fix it

  1. 1
    Check for other VCS metadata folders
    Visit yoursite.com/.svn/entries or yoursite.com/.hg/ — if either resolves with real content, that VCS metadata is exposed.
  2. 2
    Block access at the server level
    Add a rule denying access to any dotfile/folder pattern (.svn, .hg, .bzr) alongside your .git block.
  3. 3
    Confirm your deployment process excludes them
    Ideally none of these folders ship to production in the first place.

Common mistakes

How you'll know it's done

No version control metadata folders (.svn, .hg, .bzr, or similar) are accessible via direct URL.

H.I.V.E. checks this automatically

Fix it, then re-scan — the check confirms itself. No manual checkbox, the scan is the truth.

Run this check in H.I.V.E. →