Everest Backup <= 2.3.5 — Missing Authorization Leading to Unauthenticated Information Exposure (CVE-2025-11380)

Summary: A Broken Access Control vulnerability (CVE-2025-11380) affecting Everest Backup plugin versions up to and including 2.3.5 lets unauthenticated users access or enumerate backup information. The vendor fixed it in 2.3.6. This post explains technical risk, exploitation scenarios, detection and investigation steps, immediate mitigations (including virtual patching with a WAF), long-term hardening, and recommended developer fixes.

Executive overview (short)

On 10 October 2025 a broken access control vulnerability affecting Everest Backup (≤ 2.3.5) was publicly disclosed and assigned CVE-2025-11380. Certain plugin endpoints return backup metadata or enable downloads without proper authorization checks — meaning unauthenticated visitors may enumerate or retrieve backups in some setups.

Risk level: Medium (CVSS ~5.9). Impact: information exposure (backup file names, URLs, direct downloads), disclosure of site configuration and sensitive data. Exploitation can ease further attacks (credential discovery, data theft, preparation for privilege escalation). The vendor released 2.3.6 to enforce authorization checks. If you run Everest Backup, update immediately. If you cannot update immediately, apply the mitigations below, including temporary WAF/edge protections.

Why this matters to WordPress site owners

Backups are a concentrated repository of sensitive information: database dumps, wp-config.php, uploads, theme/plugin files and more. Any unauthenticated exposure of backup listings or download endpoints provides an attacker with a rich source of data to exploit:

• Enumerate available backups and choose a recent one to download;
• Download database dumps and extract user data or credentials;
• Learn site structure, plugin versions, or admin usernames from backup contents;
• Use extracted secrets for targeted attacks, phishing, or resale.

Because backups must be tightly protected, missing authorization on backup endpoints should be treated as high priority.

Vulnerability summary (technical)

What happened: one or more plugin endpoints exposing backup information or download capabilities did not validate requestor authorization (missing capability checks or nonce validation). As a result, unauthenticated HTTP requests could retrieve backup metadata and, in some setups, download backup files.

Exploitation scenarios

1. Backup enumeration: Attacker queries the plugin listing endpoint and receives names, dates, sizes — then targets a recent backup.
2. Direct download: If direct download URLs are exposed without checks, attackers can fetch a complete backup archive containing database exports and wp-config.php.
3. Automated scanning: Bots scan for the plugin and probe endpoints at scale — opportunistic exploitation is realistic until mitigations are applied.
4. Pivoting from exposed content: Harvested credentials or tokens from backups can enable privilege escalation or lateral movement.

Because exploitation requires no authentication, rapid automated scanning is the main operational threat until sites are patched or protected.

Immediate actions for site owners (first 24 hours)

1. Update the plugin to 2.3.6 immediately. The vendor fix is the primary corrective action.
2. If you cannot update immediately, deactivate Everest Backup. Deactivation removes the plugin endpoints.
3. Apply temporary WAF/edge rules or server-level restrictions. Use your hosting control panel, CDN, or WAF to block access to plugin endpoints until patched.
4. Restrict access by server rules. Add rules at Apache/Nginx level to deny public access to the plugin paths.
5. Check logs and indicators of compromise. Search webserver and WAF logs for accesses to the plugin paths or archive downloads.
6. Rotate credentials and secrets if backups were downloaded. Assume compromise if evidence of download exists: rotate DB passwords, API keys, admin passwords.
7. Preserve evidence. Preserve logs, copies of suspected files and backups for forensic analysis.

How to detect whether your site was probed or exploited

Search access logs (and WAF logs) for the following patterns — adjust for your environment:

• /wp-content/plugins/everest-backup/
• /wp-content/plugins/everest-backup/*
• /wp-json/*everest*/*
• /wp-json/everest-backup/*
• admin-ajax.php?action=… (look for backup-related actions)
• Requests that returned large files or HTTP 200 responses for download endpoints

Example grep commands (run on your server):

# search Apache / access logs for plugin directory requests in the last 30 days
zgrep -i "everest-backup" /var/log/apache2/access.log* | less

# search for wp-json requests
zgrep -i "wp-json" /var/log/nginx/access.log* | grep -i everest

# find admin-ajax.php requests with backup-like actions
zgrep "admin-ajax.php" /var/log/nginx/access.log* | grep -i "backup\|everest"

Look for unusual user agents, rapid repeated requests, requests from suspicious IPs, or large GET responses that indicate file downloads. If you find evidence of downloads, treat the site as compromised and begin full incident response.

Indicators of compromise (IOCs)

• Requests to plugin paths from unknown IPs.
• Access log entries with HTTP 200 returning archives (Content-Type: application/zip or application/octet-stream).
• Increased outbound traffic matching plugin download times.
• New admin accounts or unauthorized modifications following suspected download times.

If any IOC is present, rotate credentials and conduct a full malware and integrity scan.

Immediate mitigations you can apply (with examples)

Safe, reversible mitigations to reduce risk until you update the plugin. Always test on staging first.

1) Deactivate the plugin

From WordPress admin: Plugins → Installed Plugins → Deactivate Everest Backup.

2) Restrict plugin directory by IP (Apache .htaccess)

# Place in /wp-content/plugins/everest-backup/.htaccess
<IfModule mod_authz_core.c>
  Require ip 203.0.113.0 198.51.100.14
  Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
  Order deny,allow
  Deny from all
  Allow from 203.0.113.0
  Allow from 198.51.100.14
</IfModule>

3) Block plugin paths in Nginx

# Add to server block
location ~* /wp-content/plugins/everest-backup/ {
    deny all;
    # or:
    # allow 203.0.113.0;
    # deny all;
}

4) Block REST endpoints or admin-ajax actions via ModSecurity/WAF

If exact action names are unknown, block the plugin folder and REST namespace patterns.

# Block requests that attempt to access the plugin path
SecRule REQUEST_URI "@contains /wp-content/plugins/everest-backup/" \
 "id:100901,phase:1,deny,log,msg:'Blocked access to Everest Backup plugin path - virtual patch'"

# For REST:
SecRule REQUEST_URI "@rx /wp-json/.*everest.*" \
 "id:100902,phase:1,deny,log,msg:'Blocked REST access to Everest Backup namespace - virtual patch' "

5) Require logged-in user for plugin endpoints (temporary mu-plugin)

Add this as a small mu-plugin to block anonymous access to plugin paths — temporary and must be tested.

<?php
// mu-plugin file: wp-content/mu-plugins/everest-backup-block.php
add_action('admin_init', function() {
    if ( ! is_user_logged_in() && isset($_SERVER['REQUEST_URI']) ) {
        $uri = wp_unslash($_SERVER['REQUEST_URI']);
        if ( strpos( $uri, '/wp-content/plugins/everest-backup/' ) !== false 
             || strpos( $uri, '/wp-json/everest-backup' ) !== false ) {
            status_header(403);
            exit('Access to this resource is forbidden.');
        }
    }
});

WAF / virtual patching strategy (vendor-neutral)

If you use a Web Application Firewall (WAF) or CDN rules engine, apply vendor-neutral virtual patches to block unauthenticated access patterns until you deploy the vendor’s update:

• Block requests to /wp-content/plugins/everest-backup/* from unauthenticated or external IPs.
• Block unauthenticated requests to /wp-json/*everest*/* or REST routes in the plugin namespace.
• Block direct access to .zip, .sql, .tar files in plugin directories or when query contains download parameters (e.g., ?download=).
• Rate-limit endpoints that list backups (example: max 10 requests/minute per IP).
• Alert on any 200 responses from plugin download endpoints that return archive content-types.

Virtual patching reduces risk quickly without code changes. Implement rules carefully and monitor for false positives.

How to verify the fix has been applied correctly

1. Attempt anonymous retrieval of a backup listing — should fail (403/401) or return no sensitive info.
2. Try anonymous download of a backup file — it should be blocked.
3. Confirm WAF/CDN logs show blocked requests to plugin paths.
4. Run internal scans to ensure endpoints no longer expose information.

If anonymous retrieval still succeeds, ensure updates/migrations were applied to all instances and check caching/CDN layers for stale responses.

Long-term defenses and hardening

• Keep WordPress core, themes and plugins updated.
• Maintain an inventory of installed plugins for quick triage.
• Uninstall unused plugins (minimal plugin principle).
• Enforce least privilege for plugin operations (restrict download capability to appropriate roles).
• Harden backup strategy: store off-site (encrypted S3 or equivalent), avoid storing backups in web-accessible directories, and encrypt backups at rest.
• Use nonces and server-side capability checks for actions invoked via admin-ajax or REST.
• Implement server-level protections for directories containing backups.
• Retain and monitor logs; set alerts for archive downloads or unusual endpoints.
• Conduct periodic security reviews and code audits for plugins handling backups or sensitive operations.

Recommendations for developers (plugin authors)

• Enforce capability checks on every endpoint (e.g., current_user_can(‘manage_options’)).
• Validate authentication server-side; do not rely on obscurity.
• Use WordPress nonces for AJAX/REST actions and verify them on the server.
• Never place backups in publicly accessible folders; if necessary, enforce server-level authentication or signed expiring links.
• Sanitize and validate all inputs; restrict outputs to authorized actors.
• Require HTTPS for data transfers and use signed, time-limited download links.
• Add tests that simulate unauthenticated access attempts to ensure access control enforcement.
• Publish a Vulnerability Disclosure Policy and maintain an update cadence for security fixes.

Incident response checklist (if you confirm backup exposure)

1. Identify timeframe and IP addresses that accessed backup endpoints.
2. Preserve and export logs (webserver, WP, WAF) for analysis.
3. Rotate database credentials, API keys and exposed secrets.
4. Generate new salts and rekey tokens where possible.
5. Force password resets for admin and privileged users.
6. Remove compromised artifacts and rebuild from trusted sources.
7. Scan for web shells, malicious modifications, or suspicious admin users.
8. Notify stakeholders and follow local data breach reporting obligations.
9. Conduct a post-incident review to eliminate root cause and improve procedures.

Example detection queries and log snippets to search

• Apache combined log pattern: “GET /wp-content/plugins/everest-backup/” 200
• Look for large Content-Length values on GET requests to plugin paths (e.g., > 100000).
• WAF entries showing virtual patch rules triggered for plugin paths.

Use your hosting panel or server CLI to run grep/zgrep across rotated log files.

Why virtual patching matters now

When a public vulnerability enables unauthenticated access to backups, attackers scan broadly and quickly. Virtual patching — applied at the edge, CDN or WAF — provides a rapid protective layer that blocks malicious requests to vulnerable endpoints until you can install the official update.

Benefits:

• Immediate reduction in attack surface without modifying plugin code.
• Centralized application of rules across sites and instances.
• Granular logging and alerting of exploitation attempts for faster investigation.

Practical examples: WAF rule suggestions (human-readable)

• Deny all GET requests for files under /wp-content/plugins/everest-backup/* from unauthenticated users.
• Deny REST requests matching /wp-json/*everest*/* unless a valid session cookie or signed token is present.
• Block requests with query parameters like download= or file= that target plugin folders.
• Rate-limit endpoints that list backups to 10/minute per IP.

Implement carefully and test in monitoring/non-blocking mode before full enforcement.

Frequently asked questions

Q: If I update to 2.3.6, do I still need to do anything?
A: Update first. After updating, verify endpoints no longer expose backups. If exposure occurred before the update, rotate secrets.

Q: Can I rely on deleting old backups?
A: Deleting old backups helps but doesn’t replace fixing the vulnerability. Ensure backups are removed from public paths and linked resources are invalidated.

Q: Does deactivating the plugin delete backups?
A: Usually not — deactivation often leaves files on disk. Inspect plugin documentation and remove any files in public directories if you no longer trust them.

Developer-safe guidance for responsible disclosure

1. Contact the plugin author privately via official channels or their VDP.
2. Provide reproduction steps, affected versions, and suggested remediation.
3. Allow reasonable time for vendor response before public disclosure.
4. If actively exploited and vendor contact fails, coordinate disclosure with hosting providers and security communities.

Closing thoughts

From a Hong Kong security perspective: treat any reachable backup endpoint as an urgent incident. The path forward is clear — detect, block, patch, verify and harden. Rapid application of a vendor patch is critical; if you cannot patch immediately, temporary server-level restrictions and WAF rules will buy you time.

If you need assistance with investigations, containment, or virtual patching, work with your hosting provider or a trusted security consultant. Protect backups and the secrets they contain — it is a core part of operational security.

— Hong Kong Security Expert