Pluginnaam	Everest Backup
Type of Vulnerability	Authorization bypass
CVE Number	CVE-2025-11380
Urgentie	Medium
CVE Publish Date	2025-10-10
Source URL	CVE-2025-11380

Everest Backup <= 2.3.5 — Missing Authorization Leading to Unauthenticated Information Exposure (CVE-2025-11380) — What Site Owners Must Do Now

Auteur: WP-Firewall Security Team
Datum: 2025-10-11
Trefwoorden: WordPress, WAF, Vulnerability, Everest Backup, CVE-2025-11380, Incident Response

Samenvatting: 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 the technical risk, exploitation scenarios, detection and investigation steps, immediate mitigations you can apply (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. The issue exists because certain plugin endpoints return sensitive information without verifying authorization — meaning unauthenticated visitors can access backup metadata or files in some configurations.

Risk level: Medium (CVSS 5.9). Invloed: information exposure (backup file names, URLs or direct download access), disclosure of site configuration and potentially sensitive data. Exploitation can make other attacks easier (credential discovery, data theft, research for later privilege escalation). The vendor released a security update (2.3.6) that properly enforces authorization checks. If you run Everest Backup, update immediately. If you cannot update right away, apply the mitigations below, including virtual patching with WP-Firewall.

---

Why this matters to WordPress site owners

Backups are attractive targets. Backup archives often contain the whole site: database dumps, wp-config.php, uploads, theme/plugin files, and more. An unauthenticated exposure of backup metadata (listings and links) or direct download endpoints allows an attacker to:

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

Because backups are supposed to be tightly protected, any missing authorization check on a backup-related endpoint is high priority for defenders.

---

Vulnerability summary (technical)

• Affected software: Everest Backup plugin for WordPress
• Vulnerable versions: <= 2.3.5
• Fixed in: 2.3.6
• CVE: CVE-2025-11380
• Vulnerability class: Broken Access Control (OWASP A5)
• Required privilege to exploit: Unauthenticated (public)

What happened: one or more plugin endpoints that expose backup information or provide download access did not validate that the requestor was an authenticated, authorized user (or did not check a nonce/permission). As a result, unauthenticated HTTP requests could retrieve backup metadata and, in some setups, download backup files.

---

Exploitation scenarios

1. Backup enumeration: An attacker requests the plugin’s listing endpoint and receives a list of backup names, dates, sizes. With that information attackers can select a likely recent backup.
2. Direct download: If the plugin exposes direct download URLs without authentication checks, attackers can fetch a full backup archive that may include database exports and wp-config.php.
3. Automated scanning: Attackers or bots scan WordPress sites for the plugin and call the endpoint at scale to find easy targets. This is chronically dangerous because attacks are automated and opportunistic.
4. Pivoting from exposed content: After retrieving backup contents, attackers can harvest credentials, API tokens, or secrets and escalate into admin access or pivot to other platforms.

Because the vulnerability can be triggered without authentication, automated exploitation at scale is a realistic threat until the site is patched or protected.

---

Immediate actions for site owners (first 24 hours)

1. Update the plugin to 2.3.6 immediately
   The vendor released a fix. Updating is the single most effective corrective action.
2. If you cannot update immediately, temporarily deactivate Everest Backup
   Deactivating the plugin removes the vulnerable endpoints entirely.
3. Enable virtual patching / WAF rules
   If you use WP-Firewall, make sure the protection rule set for Everest Backup or generic backup-endpoint protection is enabled. Virtual patching can block unauthenticated access patterns without touching plugin code.
4. Restrict access by server rules
   Add an access control rule to block requests to plugin files or REST routes used by the plugin (examples below).
5. Check logs and indicators of compromise
   Search webserver logs and WAF logs for requests to the plugin paths, unusual downloads, or signs of data exfiltration (example search queries below).
6. Rotate credentials / secrets if a backup was downloaded
   If investigation shows a backup was downloaded while the vulnerability was present, rotate database passwords, API keys, and administrator passwords. Treat the backup as compromised.
7. Preserve evidence
   Keep copies of logs, backups, and any suspicious files for forensic analysis.

---

How to detect whether your site was probed or exploited

Search your access logs (or WAF logs) for requests matching patterns below. Adjust patterns for your environment.

• Requests to plugin directory:
  • /wp-content/plugins/everest-backup/
  • /wp-content/plugins/everest-backup/*
• REST endpoints (example patterns — plugin may register REST routes under own namespace):
  • /wp-json/*everest*/*
  • /wp-json/everest-backup/*
• Common AJAX endpoints:
  • admin-ajax.php?action=…
  • Look for action names related to backup listing or downloads
• Suspicious file access:
  • Requests that return large files or with response codes 200 for file 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 or rapid repeated requests (scanning).
• Requests from suspicious IP addresses or IP ranges.
• Large GET requests that returned files.

If you find evidence of downloads, treat the site as compromised and begin full incident response (rotating secrets, rebuilding from clean sources, contacting host).

---

Indicators of compromise (IOCs)

• Requests to any of the paths above coming from unknown IPs.
• Entries in access logs with HTTP 200 responses returning archives (Content-Type: application/zip or application/octet-stream).
• Increased outbound traffic at times matching plugin download endpoints.
• New admin user creation or unauthorized modifications after suspected download (may indicate follow-on attack).

If any IOC is detected, rotate credentials and perform a full malware scan.

---

Immediate mitigations you can apply (with examples)

Below are safe, reversible mitigations you can use until you apply the vendor patch.

Note: Always test changes on a staging environment before applying to production.

1) Deactivate the plugin

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

If you need the plugin’s backup capability and cannot afford downtime, use virtual patching (below) or server-level restrictions.

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

If only you and your team need access from known IPs:

# 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 (deny all, or allow only internal IPs)

# 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 WAF/ModSecurity

If you can’t identify exact action names, block the plugin’s folder and REST namespace patterns.

Sample ModSecurity rule (illustrative):

# 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'"

Or 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 (WordPress filter)

If the plugin exposes AJAX endpoints via admin-ajax, add a quick filter to force a capability check (temporary and not a replacement for vendor patch):

Add to a site-specific plugin or mu-plugin (do not edit plugin files directly):

<?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.');
        }
    }
});

This snippet denies public access to plugin paths; it is a stop-gap and must be tested.

---

Recommended WAF / virtual patching strategy (for WP-Firewall users)

If you protect your site with WP-Firewall, we recommend immediate activation of the following virtual patching rules and policies:

• Generic rule: Block requests to /wp-content/plugins/everest-backup/* from unauthenticated, non-local IPs.
• REST rule: Block any unauthenticated requests to /wp-json/*everest*/* or to any REST route in the plugin namespace.
• File-access rule: Block direct access to .zip, .sql, .tar files under wp-content/plugins/everest-backup or block access when query contains download parameters (e.g., ?download=).
• Rate limiting: Apply rate limits to endpoints that list backups. Example: max 10 requests per minute per IP to endpoints that match backup-listing patterns.
• Alerting: Create a high-priority alert when any request to the plugin directory results in a 200 response and the response Content-Type indicates an archive or a large payload.
• Geo/IP block: If your site is not global, consider temporary geo-fencing for high-volume probing countries.
• Session enforcement: Ensure that requests to sensitive endpoints require an active authenticated session cookie and valid nonce.

Virtual patching can be implemented with rulesets that are easily enabled/disabled while you apply the official plugin update.

---

How to verify the fix has been applied correctly

After updating to Everest Backup 2.3.6 (or applying a mitigation), test:

1. Attempt to retrieve a backup listing anonymously — it should fail (403/401) or return only non-sensitive info.
2. Try downloading a backup file anonymously — it should be blocked.
3. Validate WAF logs: blocked requests to the plugin path should appear with corresponding rule IDs.
4. Run a scanning tool (internal) to ensure the plugin endpoints no longer expose information.

If any of these tests show success for anonymous retrieval, re-check that the update rolled out to all instances and that caching/CDN layers are not serving stale content.

---

Long-term defenses and hardening

1. Keep WordPress, themes, and plugins updated — this is fundamental.
2. Maintain an inventory of plugins so that you know quickly if you run a vulnerable plugin.
3. Minimal plugin principle — remove plugins that aren’t actively used.
4. Principle of least privilege — ensure plugin data downloads require appropriate capabilities (manage_options, etc.).
5. Harden backup strategy:
   • Store backups off-site (S3, encrypted remote storage).
   • Avoid storing backups in web-accessible directories.
   • Always encrypt backups (password-protect ZIP or encryption at rest).
6. Use nonces and capability checks for every action that returns or modifies sensitive data.
7. Implement server-level protections such as forcing authentication on directories that contain backups.
8. Logging and monitoring — retain web logs and WAF logs and monitor for spikes, unusual endpoints, or archive downloads.
9. Periodic security reviews and code audits for plugins that handle backups or sensitive operations.

---

Recommendations for developers (plugin authors)

If you are a plugin developer building backup or file-handling features:

• Enforce capability checks on every endpoint: use current_user_can(‘manage_options’) or a capability that matches the required role.
• Validate authentication server-side; never rely only on security through obscurity.
• Use WordPress nonces for actions invoked via admin-ajax or REST; verify nonces on server.
• Never place backup files in publicly accessible folders; if you must, enforce server-level authentication.
• Sanitize and validate all inputs and restrict output to authorized actors.
• Require HTTPS for all data movement and use signed links for temporary downloads that expire.
• Add unit/integration tests that simulate unauthenticated access to ensure access control is enforced.
• Publish a Vulnerability Disclosure Policy (VDP) and 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 relevant logs for analysis (webserver, WP, WAF).
3. Immediately rotate database credentials, API keys, and any 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, when required, follow data breach reporting rules in your jurisdiction.
9. Consider a post-incident security review to eliminate root cause and improve processes.

---

Example detection queries and log snippets to search

• Apache combined log pattern for plugin:
  • “GET /wp-content/plugins/everest-backup/” 200
• Look for large Content-Length values on GET requests to plugin paths:
  • Content-Length: > 100000
• WAF entries:
  • Rule 100901 triggered: Blocked access to Everest Backup plugin path

Use your hosting panel or server CLI to run grep/zgrep across rotated log files (examples earlier in this article).

---

Why virtual patching matters now

When a vulnerability that allows unauthenticated access to backups is public, attackers don’t wait. Virtual patching — enforced at the edge or by a WAF — provides a rapid protective shield, blocking malicious requests to vulnerable endpoints while you schedule and test vendor patches.

Voordelen:

• Immediate reduction in attack surface without code changes.
• Centralized rule application for many sites (helpful for hosting providers and multisite managers).
• Fine-grained logging and alerting of exploitation attempts for faster response.

WP-Firewall offers virtual patching capabilities specifically tuned to WordPress patterns. Those protections are designed to block the request vectors described above while preserving legitimate operations.

---

Practical examples: WAF rule suggestions (human-readable)

• Deny all GET requests for files under /wp-content/plugins/everest-backup/* by unauthenticated users.
• Deny REST requests matching /wp-json/*everest*/* unless a valid JWT or session cookie is present.
• Flag and block any request with a query parameter that looks like download= or file= that targets plugin folders.
• Rate-limit requests to endpoints that list backups to 10/minute per IP.

These rules should be implemented with care to avoid breaking legitimate functionality. Always test in blocking (non-disruptive) mode first.

---

Frequently asked questions

Q: If I update to 2.3.6, do I still need to do anything?
A: Update first. After the update, verify that the endpoints behave as expected. If your backups were exposed prior to the update, rotate secrets as described.

Q: Can I rely on deleting old backups?
A: Deleting old backups helps but is not a substitute for fixing the vulnerability. Ensure backups are stored securely and that deletion does not leave stale download links.

Q: Does deactivating the plugin delete backups?
A: No — deactivation usually leaves backup files on disk. Inspect the plugin’s documentation and remove any files stored in public directories if you no longer trust them.

---

Developer-safe guidance for responsible disclosure

• Contact the plugin author privately via their official contact or VDP (if available).
• Provide reproduction steps, affected versions, and a suggested remediation.
• Allow the vendor reasonable time to respond before public disclosure.
• If no response and the vulnerability is being actively exploited, inform the hosting provider and consider coordinated public disclosure practices.

---

New: Get essential protection from WP-Firewall (free plan)

Secure your site with essential defenses — free for every WordPress site

We understand how disruptive vulnerabilities like CVE-2025-11380 can be. WP-Firewall’s Basic (Free) plan gives your site a strong baseline of protection: a managed firewall, unlimited bandwidth, a Web Application Firewall (WAF), malware scanning, and mitigations for OWASP Top 10 risks — all without cost. It’s an easy way to add virtual patching and monitoring while you apply vendor updates and complete your incident checks.

Sign up for the free plan now

(If you need automated malware removal, IP blacklist/whitelist controls, or auto virtual-patching, consider our Standard or Pro plans — we’ll work with you to choose the right level of protection.)

---

Closing thoughts from WP-Firewall’s security team

Broken access control in backup plugins is particularly dangerous because backups are a concentrated store of sensitive information. Treat any indication that backup endpoints are reachable by unauthenticated users as an urgent incident. The appropriate sequence is straightforward: detect → block → patch → verify → harden.

If you need help investigating, hardening, or deploying virtual patches, our team is available to support you. Protecting backups — and the secrets they contain — is one of the most important things you can do to improve your site’s resilience.

Stay safe, update promptly, and monitor logs closely.

— WP-Firewall Security Team