Skill

Fail

Audit score 45

insecure-source-code-management

yaklang/hack-skills

Detect and recover exposed version control metadata (.git, .svn, .hg) and backup artifacts during authorized security testing.

Source View on skills.sh

What is insecure-source-code-management?

This skill identifies and extracts exposed source code management systems and configuration files left accessible on web servers. Use it when reconnaissance discovers VCS paths, 403 errors on hidden directories, or backup/config leaks during authorized penetration testing.

Probe high-value VCS paths (.git/HEAD, .git/config, .svn/entries, .hg/requires) to detect exposure
Distinguish between 404 (absent) and 403 (exists but restricted) responses to confirm metadata presence
Recover Git repositories using git-dumper, GitTools, or GitHacker when individual files are accessible
Extract SVN working copy databases (.svn/wc.db) and pristine object stores
Detect and parse macOS .DS_Store files and common backup artifacts (.env, .tar.gz, .sql, .bak)

How to install insecure-source-code-management

npx skills add https://github.com/yaklang/hack-skills --skill insecure-source-code-management

Prerequisites

Authorization to test the target application and scope boundaries defined
Network access to probe HTTP/HEAD requests on target paths
Optional: git-dumper, GitTools, GitHacker, svn-extractor, or mercurial_source_code_dumper installed locally for recovery
SQLite3 command-line tool if manually querying .svn/wc.db databases

Claude Code

Cursor

Windsurf

Cline

How to use insecure-source-code-management

1.Probe high-value paths first (/.git/HEAD, /.svn/entries, /.hg/requires, /.env) using GET or HEAD requests, respecting rate limits
2.Distinguish 404 (not found) from 403 (forbidden) responses; 403 on directory + 200 on specific files indicates exposure
3.For Git: if /.git/HEAD succeeds, run git-dumper or GitTools to reconstruct the repository; review .git/config and .git/logs/HEAD for credentials
4.For SVN: download /.svn/wc.db, query with sqlite3 to enumerate paths, then request /.svn/pristine/ blobs if accessible
5.For macOS: fetch /.DS_Store and parse offline using ds-store or ds_store_exp tools to recover filename listings
6.Probe common backup paths (backup.zip, backup.tar.gz, config.php.bak) and environment files on application root and parent directories
7.Document all recovered credentials, URLs, and file paths as sensitive findings; do not exfiltrate data beyond authorized scope

Use cases

Good for

Authorized penetration test discovers /.git/HEAD returns 200; use git-dumper to reconstruct full repository and review commit history for credentials
Security assessment finds 403 on /.git/ directory but 200 on /.git/config; extract file-by-file to recover remote URLs and embedded secrets
Bug bounty recon identifies .svn/wc.db accessible; download and query SQLite database to enumerate source paths and request pristine blobs
Web server misconfiguration allows /.env file download; recover database credentials and API keys in scope
Backup discovery finds /backup.zip or /wwwroot.rar on application root; download and extract to assess code exposure

Who it's for

Penetration testers conducting authorized source code exposure assessments
Security researchers investigating web server misconfigurations
Bug bounty hunters validating VCS metadata leakage
DevSecOps engineers auditing deployment configurations for accidental artifact exposure

insecure-source-code-management FAQ

What is the difference between 403 and 404 responses when probing /.git/?

404 means the path does not exist or is fully blocked. 403 means the directory exists but directory listing is denied—however, individual files like /.git/HEAD may still be accessible. Always test specific file paths when you receive 403 on a directory.

Which VCS metadata files should I prioritize?

.git/HEAD (confirms Git exposure), .git/config (reveals remotes and credentials), .svn/wc.db (SQLite database for SVN), and .hg/requires (confirms Mercurial). Start with these before attempting full repository recovery.

Can I recover a Git repository if only some objects are accessible?

Yes. Tools like git-dumper and GitTools are designed to reconstruct repositories from partial object stores. Even incomplete access to /.git/objects/ and /.git/refs/ can yield significant code and history recovery.

What should I do if I find credentials in recovered source code?

Treat all recovered credentials and URLs as sensitive findings within scope. Document them, do not exfiltrate real data beyond authorization, and report them as part of the assessment. Coordinate with recon-for-sec and recon-and-methodology skills for structured evidence handling.

Are there risks to probing VCS paths during testing?

Probing with GET/HEAD requests is low-risk and non-destructive. However, respect rate limits and coordinate with recon skills to avoid overwhelming the target. Always confirm authorization before testing.

Full instructions (SKILL.md)

Source of truth, from yaklang/hack-skills.

name: insecure-source-code-management description: >- Source control and artifact exposure (.git, .svn, .hg, backups, .env). Use when recon finds VCS paths, 403 on hidden dirs, or backup/config leaks during authorized testing.

SKILL: Insecure Source Code Management

AI LOAD INSTRUCTION: This skill covers detection and recovery of exposed version-control metadata, common backup artifacts, and related misconfigurations. Use only in authorized assessments. Treat recovered credentials and URLs as sensitive; do not exfiltrate real data beyond scope. For broad discovery workflow, cross-load recon-for-sec and recon-and-methodology when those skills exist in the workspace.

0. QUICK START

High-value paths to probe first (GET or HEAD, respect rate limits):

/.git/HEAD
/.git/config
/.svn/entries
/.svn/wc.db
/.hg/requires
/.bzr/README
/.DS_Store
/.env

Routing note: quickly probe these paths first; for full recon workflow, load methodology from recon-for-sec and recon-and-methodology before deeper testing.

1. GIT EXPOSURE

Detection

/.git/HEAD — valid repo often returns plain text like:

ref: refs/heads/main

/.git/config — may expose remote.origin.url, user identity, or embedded credentials.
/.git/index, /.git/objects/ — partial object store access enables reconstruction with the right tools.

403 vs 404

404 — path likely absent or fully blocked at the edge.
403 on /.git/ — directory may exist but listing is denied; still try direct file URLs:

/.git/HEAD
/.git/config
/.git/logs/HEAD
/.git/refs/heads/main

A 403 on the directory plus 200 on HEAD strongly indicates exposure.

Recovery tools (open source)

arthaud/git-dumper — dumps reachable .git tree when individual files are fetchable.
internetwache/GitTools — Dumper, Extractor, Finder modules for partial/corrupt dumps.
WangYihang/GitHacker — alternative recovery when standard dumpers miss edge cases.

Key files to prioritize

Path	Why it matters
`.git/config`	Remotes, credentials, hooks paths
`.git/logs/HEAD`	Commit history, reflog-style leakage
`.git/refs/heads/*`	Branch tips, commit SHAs
`.git/packed-refs`	Packed branch/tag refs
`.git/objects/**`	Object blobs for reconstruction

2. SVN EXPOSURE

Detection

SVN before 1.7: /.svn/entries — XML or text metadata listing paths and revisions.
SVN ≥ 1.7: /.svn/wc.db — SQLite working copy database (PRAGMA table_info after download).

Example probe:

GET /.svn/entries HTTP/1.1
GET /.svn/wc.db HTTP/1.1

Recovery

anantshri/svn-extractor — automated extraction from exposed .svn.
Manual: download wc.db, query with sqlite3 for file paths and checksums, then request /.svn/pristine/ blobs if exposed.

3. MERCURIAL EXPOSURE

Detection

/.hg/requires — small text file listing repository features; confirms Mercurial metadata.

GET /.hg/requires HTTP/1.1
GET /.hg/store/ HTTP/1.1

Recovery

sahildhar/mercurial_source_code_dumper — dumps repository when store paths are reachable.

4. OTHER LEAKS

Bazaar (Bzr)

Probe /.bzr/README and /.bzr/branch-format for Bazaar metadata.

macOS `.DS_Store`

/.DS_Store can encode directory and filename listings.
Tools: gehaxelt/ds-store, lijiejie/ds_store_exp — parse .DS_Store offline.

Backup and config artifacts

Probe (adjust for app root and naming conventions):

/.env
/backup.zip
/backup.tar.gz
/wwwroot.rar
/backup.sql
/config.php.bak
/.config.php.swp

Web server misconfiguration signal (example: NGINX)

location /.git { deny all; } — may return 403 for /.git/ while still allowing or denying specific subpaths depending on rules.
403 on a protected location can confirm the route exists; always distinguish from 404 on non-existent paths.

5. DECISION TREE

Probe /.git/HEAD → ref: refs/heads/ pattern? → run git-dumper / GitTools / GitHacker; review config and logs/HEAD for secrets.
Else probe /.svn/wc.db or entries → success? → svn-extractor or manual wc.db + pristine recovery.
Else probe /.hg/requires → success? → mercurial dumper.
Else probe /.bzr/README → Bazaar tooling or manual path walk.
Parallel: fetch /.DS_Store, /.env, common backup extensions on app root and parent paths.
Interpret status codes: 403 on directory + 200 on specific files → treat as high priority for file-by-file extraction.

6. RELATED ROUTING

From recon-for-sec — scope-safe discovery, crawling, and fingerprinting before deep VCS tests.
From recon-and-methodology — structured methodology and evidence handling.

Note: coordinate with recon skills—set scope and request rate first, then run targeted VCS/backup validation.