Version Control & Source
Exposed source-control and dependency files that can reconstruct code and reveal internals.
21 probed paths in this category.
.dockerignore
Docker Ignore File
Risk: Exposes which files are deliberately excluded from the build context, hinting at the presence of credential files, .env, or .git directories an attacker can then target directly.
Fix: Do not serve dotfiles from the web root; configure the server to deny requests for files beginning with a dot and return 404.
.git/config
Git repository
Risk: An exposed .git directory lets an attacker reconstruct your entire source code and commit history - including hard-coded credentials and internal logic - straight from a public URL.
Fix: Don't deploy the .git directory to production. Block /.git/ at the web server and deploy from build artifacts rather than a live working tree.
.git/HEAD
Git repository
Risk: A readable .git directory lets an attacker reconstruct the full source repository and its history, exposing application logic, hardcoded credentials, and secrets committed in past versions.
Fix: Deny access to .git directories at the web server, deploy from a build artifact rather than a working git clone, and purge any secrets found in history while rotating them.
.git/index
Git staging-area index file, part of an exposed .git directory that can reconstruct source
Risk: A readable .git/index lets an attacker enumerate every tracked file and, combined with downloadable object/pack files, reconstruct the full application source code, exposing secrets, logic flaws, and hardcoded credentials.
Fix: Never deploy the .git directory to a webroot; block all access to .git via server config (deny location ~ /\.git), use export-ignore or a clean build artifact, and remove any committed secrets and rotate them.
.git/logs/HEAD
Git reflog of HEAD movements, leaks commit history from an exposed .git directory
Risk: The reflog leaks commit hashes, author identities, timestamps, and branch history, allowing an attacker to fetch individual objects and recover source code or secrets that existed in prior commits.
Fix: Deny web access to the entire .git directory at the server level, deploy from build artifacts rather than working trees, and purge sensitive history while rotating any exposed credentials.
.git/packed-refs
Git packed references file listing branch and tag tips
Risk: This file lists branch and tag commit tips, giving an attacker the object hashes needed to download and reassemble repository contents from an exposed .git directory.
Fix: Block HTTP access to .git, ensure deployments exclude version-control metadata, and serve a 404 for any .git path while auditing for already-leaked source or secrets.
.git/refs/heads/main
Git reference pointing to the tip commit of the main branch
Risk: Reading this ref reveals the tip commit hash of the main branch, the entry point for walking the object graph and reconstructing the entire codebase when the .git directory is web-accessible.
Fix: Deny all requests to .git via web server rules, deploy without the .git directory, and verify no source or credentials were exposed, rotating secrets if they were.
.gitlab-ci.yml
GitLab CI/CD pipeline configuration file
Risk: Reveals the full CI/CD pipeline including build/deploy commands, runner tags, container images, and references to CI/CD variables, helping an attacker map the deployment chain and target the GitLab runner environment.
Fix: Serve application code from a directory that excludes repository metadata, deny access to dotfiles via web-server rules, and keep credentials in masked/protected GitLab CI/CD variables.
.idea/workspace.xml
JetBrains IDE workspace file that can leak project paths and configuration
Risk: Leaks JetBrains project internals such as local file paths, run configurations, and tool settings, exposing developer environment details and the application's directory structure.
Fix: Block the .idea directory at the web server, exclude IDE metadata from deployment artifacts, and add it to .gitignore so it never ships to production.
.vscode/settings.json
Visual Studio Code workspace settings file
Risk: Exposes editor and project configuration that can reveal local paths, build tasks, linters, and occasionally embedded tokens or environment hints useful for further reconnaissance.
Fix: Deny web access to the .vscode directory, keep IDE config out of the deployment package, and never store secrets in editor settings files.
.vscode/sftp.json
VSCode SFTP config file
Risk: This VSCode SFTP extension config typically contains the deployment host, username, and sometimes plaintext password or private key path, granting an attacker direct SFTP/SSH access to the server.
Fix: Never deploy editor config directories, add .vscode/ to ignore lists, deny dotfolder access at the server, and rotate any SFTP credentials that were committed.
composer.json
PHP Composer Configuration
Risk: Discloses PHP package dependencies and versions enabling targeted exploitation of vulnerable libraries, and may expose private VCS repository URLs or framework details.
Fix: Exclude composer.json and composer.lock from the web root, keep dependencies updated, and store any auth credentials in auth.json outside served paths.
Gemfile
Ruby Gem Dependencies
Risk: Reveals exact Ruby gem dependencies and version constraints, letting an attacker cross-reference known CVEs (e.g. vulnerable Rails, Nokogiri, or Devise releases) to craft targeted exploits.
Fix: Keep Gemfile and Gemfile.lock outside the web-served document root, and block requests for them at the web server or CDN so they return 404.
main.js.map
JavaScript source map that can reconstruct original front-end source code
Risk: A served source map lets an attacker reconstruct the original, unminified front-end source, exposing internal logic, API endpoints, and any inadvertently embedded keys or comments.
Fix: Disable source-map generation for production builds or restrict .map files to internal/authenticated access, and never bundle secrets into client-side code.
package.json
Node.js Package Configuration
Risk: Reveals exact Node.js dependency names and versions for targeting known CVEs, plus internal script commands, private registry URLs, and occasionally embedded tokens.
Fix: Do not deploy package.json to the public web root, pin and patch dependencies, and keep registry credentials in .npmrc or environment variables outside served directories.
pom.xml
Maven Project Configuration
Risk: Discloses Maven coordinates and versions of Java libraries (e.g. Log4j, Jackson, Spring), enabling identification of dependencies with known CVEs such as Log4Shell or deserialization flaws.
Fix: Never deploy pom.xml into the public web root; package only compiled artifacts and deny direct access to .xml build descriptors at the server level.
protected/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
PHPUnit
Risk: The same PHPUnit eval-stdin RCE (CVE-2017-9841) exposed under a Yii-style protected/ directory lets an attacker execute arbitrary PHP from the request body and take over the application.
Fix: Keep vendor/ outside the document root, exclude dev dependencies from production deploys, and deny web access to any vendor or protected directory path.
requirements.txt
Python Requirements File
Risk: Lists exact Python package versions, letting an attacker match the stack against known CVEs and craft precise exploits, and may reveal internal package index URLs.
Fix: Keep requirements files out of the publicly served directory, regularly patch pinned dependencies, and store private index credentials in environment variables rather than the file.
vendor/composer/installed.json
Composer installed-packages manifest revealing exact dependency versions
Risk: Lists exact installed PHP package names and versions, letting an attacker match your dependencies to known CVEs and craft targeted exploits.
Fix: Serve only the public/ directory so vendor/ is unreachable, and keep dependencies patched with composer update to minimize the value of version disclosure.
vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
PHPUnit
Risk: This shipped PHPUnit helper (CVE-2017-9841) evaluates PHP code sent in the request body, giving an unauthenticated attacker direct remote code execution on the web server.
Fix: Move Composer dev dependencies out of the webroot and never deploy vendor/ to production; block web access to vendor paths and remove PHPUnit from production installs.
wp-content/plugins/mm-plugin/inc/vendors/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
PHPUnit
Risk: A WordPress plugin bundling PHPUnit reintroduces the eval-stdin RCE (CVE-2017-9841), letting an unauthenticated attacker run arbitrary PHP and compromise the entire WordPress site.
Fix: Remove or update the offending plugin, delete bundled vendor/PHPUnit files from the webroot, and block web access to plugin vendor directories via web server rules.