What is Backup File Exposure (.bak, .old)? Ways to Exploit, Examples and Impact

In the fast-paced world of web development and server administration, it is common for engineers to create quick backups of configuration files or source code before making significant changes. Often, these temporary files are named by simply appending an extension like .bak, .old, or .save to the original filename. While this seems like a harmless habit, it creates a critical security vulnerability known as Backup File Exposure. This occurs when these sensitive files are left in web-accessible directories, allowing attackers to download and read the raw source code or configuration data of an application.

What is Backup File Exposure?

Backup file exposure is a subcategory of Information Disclosure vulnerabilities. It happens when a web server is configured to execute certain file types (like .php, .jsp, or .aspx) but treats modified versions of those filenames as static text files. For example, if a server encounters config.php, it executes the code and sends only the output to the user. However, if an attacker requests config.php.bak, the server typically does not recognize the .bak extension as an executable script. Instead, it serves the file as plain text (text/plain), revealing every line of the original source code, including database credentials, API keys, and internal logic.

This vulnerability is particularly dangerous because it bypasses the security boundary provided by server-side execution. In a normal environment, a user should never see the underlying logic of a web application. Backup files strip away this protection, turning a secure application into an open book for anyone who knows where to look. Jsmon can help identify these exposed assets by mapping your external infrastructure and alerting you to forgotten files.

Common File Extensions and Naming Patterns

Attackers don't just guess filenames randomly; they use common patterns generated by text editors, version control systems, and manual administrative habits. Understanding these patterns is the first step in both exploitation and defense.

Manual Backup Extensions

When developers perform manual backups, they frequently use the following extensions:

• .bak (General backup)
• .old (Old version)
• .save or .saved (Saved state)
• .1, .2, .copy (Sequential copies)
• .orig or .original (The original file before a patch)
• .tmp or .temp (Temporary files)

Editor-Specific Temporary Files

Many text editors create hidden swap or temporary files that persist if the editor crashes or the developer forgets to close the session:

• .swp or .swo: Created by Vim. If a developer edits index.php, a hidden file named .index.php.swp is created in the same directory.
• ~: Many Linux-based editors (like Gedit or Nano) append a tilde to the end of a filename (e.g., config.php~).
• .DS_Store: While not a backup file, this macOS metadata file can reveal the names of other files in a directory, helping an attacker find backups.

Compressed Archives

Sometimes entire directories are backed up into a single archive file and left in the web root:

• backup.zip or site.tar.gz
• www.7z or html.rar
• project.bak.zip

Why Does Backup File Exposure Happen?

This vulnerability is rarely the result of a complex software bug; rather, it is a consequence of human error and workflow inefficiencies.

1. Manual Hot-Fixing: A developer might need to fix a bug directly on the production server. To be safe, they copy auth.php to auth.php.bak before editing. If they forget to delete the .bak file after the fix is confirmed, the vulnerability is born.
2. Editor Crashes: Tools like Vim create swap files to prevent data loss. If a SSH session disconnects or a server reboots while a file is open, the swap file remains on the disk.
3. Automated Scripts: Sometimes backup scripts are configured to dump database exports (db_backup.sql) into the web-accessible /var/www/html/ folder for "easy downloading" by the admin, but they are never protected by authentication.
4. Lack of CI/CD: In environments where code is manually uploaded via FTP or SFTP instead of through a controlled pipeline, there is no automated process to prune unwanted files from the production environment.

How Attackers Discover Backup Files

Finding exposed backups is a core part of the reconnaissance phase in any penetration test. Attackers use several techniques to locate these hidden gems.

Google Dorking

Search engines index everything they can find. Attackers use specific search queries (Dorks) to find backup files across the internet. For example:

intitle:"index of" "backup.sql"
ext:bak inurl:config
ext:old "password"

These queries look for directory listings or specific file extensions that contain sensitive keywords.

Fuzzing and Brute-Forcing

This is the most common method for targeted attacks. Using tools like ffuf, gobuster, or dirsearch, an attacker can test thousands of potential backup names in seconds.

Example command using ffuf:

ffuf -u https://example.com/FUZZ -w common_filenames.txt -e .bak,.old,.php.bak,~,.swp

In this command, the attacker uses a wordlist of common file names (like config, settings, db, index) and instructs the tool to append various backup extensions to each one. If the server returns a 200 OK status code for config.php.bak, the attacker has found a leak.

Technical Exploitation Examples

To understand the severity, let's look at a few practical scenarios where backup files lead to a full system compromise.

Example 1: The Database Credential Leak

A common target is the configuration file. In a WordPress environment, this is wp-config.php. If an attacker finds wp-config.php.bak, they can download it and see the following:

<?php
define( 'DB_NAME', 'production_db' );
define( 'DB_USER', 'admin_user' );
define( 'DB_PASSWORD', 'SuperSecretPassword123!' );
define( 'DB_HOST', '10.0.0.5' );
?>

With these credentials, the attacker can now attempt to connect to the database directly or look for a database management tool like phpMyAdmin on the same server to dump all user data.

Example 2: Recovering Vim Swap Files

If an attacker finds .index.php.swp, they cannot read it as a standard text file because it is in a binary format used by Vim. However, they can download it and use Vim's recovery feature on their own machine to reconstruct the original source code:

# Download the swap file
curl -O https://example.com/.index.php.swp

# Recover the content
vim -r .index.php.swp

This reveals the logic of the index.php file, which might contain hardcoded API keys or hidden administrative parameters.

Example 3: Logic Flaw Discovery

Imagine an application that uses a custom authentication check. By reading a backup of the authentication logic, an attacker might find a "backdoor" or a poorly implemented check:

// Found in auth.php.old
function check_login($user, $pass) {
    // Temporary bypass for testing - REMOVE BEFORE PROD
    if ($user == "debug_admin") return true;
    
    return password_verify($pass, $db_hash);
}

Even if the current auth.php has removed this code, the .old file reveals that a debug_admin account might exist or provides clues about how the developers think, which aids in further exploitation.

The Impact of Exposure

The impact of backup file exposure ranges from moderate to catastrophic, depending on what is leaked.

1. Full Source Code Disclosure: Seeing the source code allows attackers to find other vulnerabilities like SQL Injection, Cross-Site Scripting (XSS), or Insecure Direct Object References (IDOR) much faster than "black-box" testing.
2. Credential Theft: Hardcoded passwords, database strings, and secret keys for services like AWS, Stripe, or SendGrid are frequently found in backups.
3. Data Breaches: If a database dump (.sql) is exposed, every user's personal information, hashed passwords, and transaction history are immediately compromised.
4. Intellectual Property Loss: For many companies, their unique source code is their most valuable asset. Exposure means competitors or malicious actors can steal proprietary algorithms.

How to Prevent Backup File Exposure

Preventing this issue requires a combination of strict server configuration and disciplined development workflows. Jsmon can also be used to continuously monitor your attack surface for any new backup files that might appear during deployments.

1. Disable Directory Listing

Ensure that your web server does not show a list of files when a user visits a directory without an index file. In Apache, this is done by removing the Indexes option:

<Directory /var/www/html>
    Options -Indexes
</Directory>

2. Block Access to Backup Extensions

Configure your web server to explicitly deny requests for common backup extensions. For Nginx, you can add this to your server block:

location ~* \.(bak|old|orig|save|swp|sql|zip|tar|gz|~)$ {
    deny all;
    access_log off;
    log_not_found off;
}

This ensures that even if the files exist, the server will return a 403 Forbidden error to any requester.

3. Use .gitignore

Prevent developers from accidentally uploading temporary files to your repository. A robust .gitignore file should include patterns for swap files and common backup extensions:

*.bak
*.old
*.swp
*~
.DS_Store

4. Implement CI/CD Pipelines

Move away from manual FTP/SSH uploads. Use a deployment pipeline (like GitHub Actions or GitLab CI) that performs a "clean" build. The pipeline should only move the necessary production files to the server, leaving behind any local backups or editor artifacts.

5. Regular Auditing

Use automated scanners to check for these files regularly. Since your attack surface changes every time a developer touches the code, continuous monitoring is essential. Tools that perform infrastructure reconnaissance are vital for catching these leaks before they are indexed by search engines.

Conclusion

Backup file exposure is a low-effort, high-reward vulnerability for attackers. It turns simple administrative habits into open gateways for data breaches. By understanding the common naming conventions and how tools like ffuf are used to discover these files, security teams can better defend their infrastructure. The key to defense lies in strict server configurations, automated deployment processes, and constant vigilance.

To proactively monitor your organization's external attack surface and catch backup file exposures before attackers do, try Jsmon.