CVE-2021-39327

What it actually does

The flaw exposes a publicly reachable db_backup_log.txt file that can disclose the absolute filesystem path of a WordPress site and the locations of database backup files. The issue is unauthenticated and remotely accessible, with low attack complexity, and primarily affects confidentiality. By itself it does not directly provide code execution or data modification, but the disclosed paths and backup locations can materially assist follow-on attacks such as downloading exposed database backups, chaining with local file inclusion/path traversal flaws, or improving exploitation reliability against other vulnerabilities.

Why it matters to the business

An attacker may be able to learn where sensitive site files and database backups are stored and, in some cases, use that information to retrieve backups containing user records, credentials, configuration secrets, or business data. Although this vulnerability is not listed in CISA KEV and is not identified as ransomware-associated, the supplied EPSS score is high and exploit maturity is weaponized, so exposed internet-facing instances should be treated as likely to be probed. The supplied affected product metadata also references nanorand for Cargo with a fixed version of 0.6.1; organizations should verify asset inventory carefully because the product metadata and vulnerability description appear inconsistent.

How an attack unfolds

An attacker scans internet-facing web applications for the exposed db_backup_log.txt file associated with vulnerable BulletProof Security WordPress plugin installations. If the file is accessible over HTTP without authentication, the attacker downloads it and reviews it for absolute filesystem paths and database backup file locations. The attacker then attempts to retrieve any referenced backup files directly from the web server or uses the path disclosure to refine subsequent attacks against the same site, such as targeting known backup directories, chaining with file inclusion or traversal vulnerabilities, or identifying configuration locations that may contain database credentials. Successful exploitation requires only network access to the vulnerable file and does not require credentials or user interaction.

How to fix it

Upgrade affected software to a fixed version. For the supplied package metadata, update nanorand for Cargo to version 0.6.1 or later. For environments matching the vulnerability description, upgrade the BulletProof Security WordPress plugin to a version later than 5.1 or the vendor-provided fixed release. Remove or block public access to db_backup_log.txt and any database backup directories, move backups outside the webroot, and ensure web server rules deny direct access to backup logs and backup artifacts. Review backup retention and permissions, rotate credentials if database backups may have been exposed, and purge publicly accessible backup files from the web server.

How to confirm the fix worked

Confirm the installed package or plugin version is fixed: nanorand should be 0.6.1 or later where applicable, and BulletProof Security should be upgraded beyond the vulnerable release line described. From an unauthenticated external perspective, request known or suspected db_backup_log.txt locations and verify the server returns 403, 404, or an equivalent non-disclosing response rather than file contents. Confirm database backup files are not accessible under the webroot and that directory indexing is disabled. Validate web server access-control rules for backup/log file extensions and review dependency lockfiles or WordPress plugin inventory to ensure vulnerable versions are no longer deployed.

Typical attack path

1. Identify WordPress sites running the vulnerable BulletProof Security plugin or probe common locations for db_backup_log.txt.
2. Send an unauthenticated HTTP GET request for the exposed db_backup_log.txt file.
3. Parse the response for the webroot path, absolute filesystem paths, and database backup file paths.
4. Attempt to access referenced backup files or related backup directories over HTTP.
5. Use disclosed path information to support follow-on attacks, including backup theft, credential discovery, or chaining with other web application vulnerabilities.

How to detect it

Review web server access logs, CDN logs, WAF logs, and reverse proxy logs for unauthenticated requests to db_backup_log.txt and backup-related paths. Focus on HTTP 200 responses, large response sizes, repeated probing across multiple paths, and subsequent requests for database backup archives, SQL dumps, or backup directories from the same source IP or user agent. For WordPress deployments, inspect plugin backup directories for unexpected access timestamps and confirm whether any referenced database backup files were downloaded. Look for attacker workflows where a request to db_backup_log.txt is followed by requests to .sql, .sql.gz, .zip, .tar, .tar.gz, or backup directory paths. If backups may have been accessed, perform secret exposure review against backup contents and rotate credentials found in database dumps or configuration data.

• db_backup_log.txt
• GET /db_backup_log.txt
• GET /wp-content/plugins/bulletproof-security
• GET /wp-content/bps-backup
• /wp-content/bps-backup/
• /bps-backup/
• /db_backup_log.txt HTTP/1.1
• db_backup_log.txt HTTP/1.1" 200
• GET /wp-content/
• GET /wp-content/uploads/
• GET /wp-content/plugins/
• GET /wp-content/bps-backup/logs/db_backup_log.txt
• GET /wp-content/bps-backup/backups_
• backups_
• \.sql
• \.sql.gz
• \.sql.zip
• \.zip HTTP/1.1" 200

What your security team should do

• Prioritize internet-facing WordPress sites and any assets identified by inventory as using the affected component because exploitation is weaponized and EPSS is high.
• Upgrade to the fixed version: nanorand 0.6.1 or later where the supplied package metadata applies, and the fixed BulletProof Security plugin release for WordPress deployments matching the description.
• Search historical web access logs for requests to db_backup_log.txt and backup-related paths, especially successful 200 responses.
• Remove exposed backup logs and database backups from the webroot; store backups in non-public locations with strict permissions.
• If logs show successful access to db_backup_log.txt or backup archives, treat database backup contents as potentially exposed and rotate any credentials, salts, API keys, or secrets present in backups.
• Add web server or WAF rules blocking direct access to backup logs, SQL dumps, archive backups, and plugin backup directories.
• Resolve the product-metadata discrepancy during triage by validating both dependency manifests and WordPress plugin inventories rather than relying on one source alone.