Nome del plugin	Everest Backup
Type of Vulnerability	Authorization flaw
CVE Number	CVE-2025-11380
Urgenza	Medio
CVE Publish Date	2025-10-10
Source URL	CVE-2025-11380

Urgent Security Advisory — Everest Backup Plugin (<= 2.3.5)

Missing authorization leads to unauthenticated information exposure (CVE-2025-11380)

Riepilogo

• A broken access control vulnerability affecting the Everest Backup WordPress plugin versions <= 2.3.5 has been disclosed (CVE‑2025‑11380).
• Impact: unauthenticated attackers may access sensitive plugin functionality or information without required authorization checks, potentially exposing backup metadata or downloadable backup files.
• Severity: Medium (CVSS 5.9).
• Fixed in: 2.3.6.
• Required action: Update to Everest Backup v2.3.6 immediately. If you cannot update right away, apply the mitigations below.

This advisory is written by the WP‑Firewall security team. We’re WordPress security practitioners and plugin hardening specialists — our goal is to give you clear, actionable steps to protect sites, plus detection and recovery guidance.

---

Background — what this plugin does and why the issue matters

Everest Backup is a plugin that helps WordPress site owners create and manage site backups. Backup plugins handle extremely sensitive data: full database dumps, wp-config.php contents, uploaded files, and sometimes encryption keys or service credentials. Any flaw that allows unauthenticated access to backup operations or backup file listings is particularly high risk because backups often contain everything needed to fully restore — and in the wrong hands, to take over — a site.

A broken access control (missing authorization) vulnerability means a request to a plugin endpoint (REST, AJAX or direct URL) does not verify that the requester is permitted to perform the operation or view the resource. When this occurs for backup-related functionality, the attacker can often enumerate or download backup files, or learn metadata that aids follow-up attacks.

---

What we know about the vulnerability

• A flaw in Everest Backup (<= 2.3.5) allows unauthenticated requests to access data or functionality that should be restricted.
• The vulnerability is classified as Broken Access Control (OWASP A5).
• The plugin author released a patch in version 2.3.6 that adds the required authorization checks.
• The vulnerability was assigned CVE‑2025‑11380 and a CVSS of 5.9 (Medium).
• Required privilege: none — attacker can be unauthenticated (public internet).

Note: Specific internal implementation details (exact endpoint names, parameter names) can vary by plugin version; the core problem is missing authorization checks around backup resource endpoints. Treat all public requests to backup endpoints as potentially vulnerable until patched.

---

Realistic impact scenarios

Here are the credible ways this issue can be abused if an attacker finds and targets an unpatched site:

• Downloading full backups: A backup archive may contain the database (including user hashes, salts, API keys), wp-config.php (database credentials, salts, third-party keys), media library files, and other sensitive content. Access to this is equivalent to full site compromise in many cases.
• Reconnaissance: Even if direct downloads are not exposed, an attacker can enumerate backup filenames, timestamps, and sizes — which can reveal recent changes, administrative timelines, or files of interest.
• Information leakage: Backup metadata (paths, staging URLs, server paths, environment indicators) can enable targeted attacks and privilege escalation.
• Chaining with other vulnerabilities: Exposed backup files containing credentials make it easier to attack other services (database, third-party integrations, S3 buckets, etc.).
• Reputation / compliance damage: Exposure of customer data or personally identifiable information in backups can trigger GDPR/other compliance incidents.

Because this vulnerability requires no authentication, the attack surface is broad and automated scanning could detect unpatched sites quickly.

---

How to check if your site is affected

1. Verify plugin and version
   • In WordPress admin: Plugins → Installed Plugins → look for “Everest Backup”. Confirm the version.
   • If you cannot access wp-admin, check the plugin directory on the filesystem (wp-content/plugins/everest-backup/) and open the plugin header in the main PHP file to check the version.
2. Look for public endpoints and files
   • Search your site for files and endpoints matching the plugin folder: requests under /wp-content/plugins/everest-backup/ or any endpoints that include everest, ebackup, backup, ecc.
   • Inspect your site’s REST API for plugin routes (/wp-json/...) that include backup-related names.
3. Audit server logs for suspicious requests
   • Unusual GET/POST requests to backup-related endpoints from unknown IPs.
   • Requests that try to download .zip, .sql, .tar, .gz files or include parameters like download, file, path, O backup_id.
   • Repeated probes from scanners looking for plugin endpoints.
4. Check for existing leaks
   • Try to access any backup download URLs (if you find any) using an incognito browser or curl — but do this only from admin-approved test environments. If the download works without login, you are exposed.

If you find evidence of unauthorized access or unknown downloads, treat the site as potentially compromised and follow the incident response steps later in this post.

---

Immediate actions — 0–24 hours (priority)

1. Update Everest Backup to 2.3.6 (or latest)
   • This is the definitive fix. Use WordPress admin Plugins → Update, or update via SFTP by uploading the patched plugin files. Back up your site first (create an off-site backup snapshot) before updating if possible.
2. If you cannot update immediately, disable the plugin
   • As a temporary stopgap, deactivate the Everest Backup plugin to prevent exploitation. Note: deactivation halts scheduled backups and could affect restore options.
3. Apply firewall rules (virtual patch) to block access
   • If you run a Web Application Firewall (WAF) or have access to server-level rules, block requests that match backup endpoints/patterns (see sample rules below). WP‑Firewall users can enable a virtual patch that blocks common exploit requests for this plugin while you update.
4. Restrict direct access to backup files
   • If backups are stored in web‑accessible directories (e.g., wp-content/uploads/ or plugin folder), add server rules to deny public access, or move backups to a non-public storage location (S3, remote FTP, offsite storage).
5. Monitor logs and scan for compromise
   • Immediately review access logs for download attempts or successful access to .zip/.sql files. Use malware scanners to look for indicators of compromise.

---

Sample temporary firewall and webserver mitigations

Below are examples you can adapt. Test on a staging environment before deploying into production.

Apache (.htaccess) — deny public web access to a specific plugin folder or backup files:

# Deny direct access to the Everest Backup plugin folder
<Directory "/var/www/html/wp-content/plugins/everest-backup/">
    Require all denied
</Directory>

# Or block common backup file extensions in uploads or plugin folders
<FilesMatch "\.(zip|sql|tar|gz|7z)$">
    Require all denied
</FilesMatch>

Nginx — block access to backup files by extension inside uploads or plugin folder:

location ~* /wp-content/(uploads|plugins)/.*\.(zip|sql|tar|gz|7z)$ {
    deny all;
    return 404;
}

# Block direct access to plugin PHP files (if you are certain no front-end usage)
location ~* /wp-content/plugins/everest-backup/.*\.php$ {
    deny all;
    return 404;
}

ModSecurity (example rule) — block requests with common backup download parameters or suspicious paths:

# Block requests attempting to download backup archives or containing backup endpoints
SecRule REQUEST_URI "@rx /(everest|ebackup|backup).*" "id:1001001,phase:1,deny,log,msg:'Block suspicious Everest Backup access',severity:2"
SecRule ARGS_NAMES|ARGS "@rx (download|file|backup_id|path|filename)" "id:1001002,phase:2,deny,log,msg:'Potential backup download attempt'"

WP-Firewall virtual patching
If you are using WP‑Firewall, enable the managed virtual patch for the Everest Backup vulnerability to quickly block unauthenticated requests to the affected endpoints while you apply the vendor patch.

Caveat: these are temporary mitigations; they should not replace updating the plugin.

---

Safe update procedure (recommended)

1. Take a full off‑site backup (separate from the plugin) — for recovery if something goes wrong during updates.
2. Put the site into maintenance mode or limit access to administrators.
3. Update the plugin via wp-admin: Plugins → Update.
4. If updating via SFTP:
   • Download latest plugin package from the official source.
   • Replace plugin folder carefully. Ensure permissions and ownership are correct.
5. After update:
   • Test front-end and admin functionality.
   • Check scheduled backups and plugin settings. Ensure backup locations are correct and not public.
6. Re-scan the site with a malware scanner and review recent logs for unusual behavior.

---

Detection guidance — what to look for in logs and monitoring

• Unauthenticated GET/POST requests to plugin directories or routes containing “everest”, “backup”, “ebackup”, etc.
• Requests with parameters like download, file, backup, backup_id, action=download o simili.
• Sudden outbound connections to unknown external hosts (if the attacker exfiltrates backups).
• HTTP responses returning archive files (200 with content-type application/zip, application/x-gzip) for non-authenticated requests.
• New admin users created after the disclosure date, or changes to the WordPress options table.
• Integrity changes: modified core file timestamps, new php files in uploads, or suspicious cron events.

If you see any of these signs, treat the situation as possible compromise and follow incident response steps.

---

Incident response — if you were exposed or downloaded backups were accessed

1. Isolate
   • Temporarily take the site offline or restrict traffic to known admin IPs. Prevent further data leakage.
2. Preserve evidence
   • Make copies of relevant logs (webserver logs, plugin logs) and store them offline. Note timestamps and IPs.
3. Rotate credentials
   • Immediately rotate database credentials (update wp-config.php), WordPress admin passwords, API keys, and any exposed third-party credentials that could be in the backups.
4. Malware scan and cleanup
   • Perform a full malware scan (server and WordPress). Remove web shell and backdoors. If you lack in-house capability, involve experienced incident responders.
5. Assess backups
   • If an attacker downloaded backups, consider them compromised. Restore from a known-good backup taken before the compromise, if available. Confirm backup integrity before restoring.
6. Rebuild if necessary
   • In many serious compromises, rebuilding from clean sources (fresh WordPress core, fresh plugin files from official repo) and restoring only verified content is safest.
7. Post-incident hardening
   • Implement least privilege, move backups off webroot, ensure encryption-at-rest for backups, apply WAF rules, and enable multi-factor authentication for admin accounts.
8. Notify stakeholders / compliance
   • If personal data was exposed, follow legal reporting obligations (data protection authorities, affected users) per your jurisdiction.

---

Hardening recommendations for backup plugins and practices

Backups are your insurance — they must be protected.

• Store backups off-site and outside web-accessible directories (S3 with tight IAM policy, SFTP to a separate host).
• Encrypt backups at rest and in transit. Use strong passphrases and rotate them periodically.
• Use expiring, signed download URLs (time‑limited tokens) rather than static public links.
• Limit backup creation and download endpoints to authenticated administrators with capability checks (e.g., manage_options).
• Regularly audit plugin endpoints and restrict access via server rules where feasible.
• Periodically review and prune old backups; keep only a minimum retention set.
• Enable logging and alerting for backup creation and download events.
• Avoid storing secrets (plain text keys) in backups if possible; use environment variables or secret managers.

---

Practical WAF rules for WordPress site owners

When a vendor patch is not yet applied across every site, a WAF is the fastest way to mitigate exploitation. Here are change ideas for rule authors and site owners:

• Block unauthenticated requests to plugin admin endpoints:
  • Deny requests to plugin endpoints where the request does not include valid authentication cookies or a valid nonce token.
• Block or challenge requests that try to download archive/database file types from plugin folders (zip, sql, tar, gz).
• Rate-limit and challenge requests that enumerate backup IDs or list files in plugin routes.
• Block known exploit patterns (suspicious query strings containing download=1, action=get_backup, etc.) where the request lacks a valid authenticated session.

If you use WP‑Firewall, enable the managed protection signature for this vulnerability — it is designed to block common exploitation attempts while allowing legitimate admin operations.

---

Example checklist — prioritized actions

Immediate (within hours)

• Update Everest Backup to v2.3.6 or later.
• If update not possible, deactivate plugin until patched.
• Apply webserver/WAF rule to block public access to backup-related endpoints and files.
• Review access logs for suspicious download requests.

Short-term (1–3 days)

• Scan site for indicators of compromise.
• Rotate sensitive credentials (DB, API keys, admin passwords).
• Move backups to protected, non-web-accessible storage.
• Verify and tighten plugin permissions and settings.

Medium-term (1–4 weeks)

• Review backup retention and encryption policy.
• Conduct a security audit of third‑party plugins and remove unused plugins.
• Deploy monitoring and alerting for backup-related actions.

Ongoing

• Keep all plugins, themes and WordPress core updated.
• Enforce the principle of least privilege for admin users.
• Use a reputable managed firewall and regular vulnerability scanning.

---

Why this vulnerability is avoidable — a developer note

From a developer and security engineering perspective, backup functionality should always perform strict authorization checks. Common best practices:

• Every endpoint that returns backup listings or files must verify the requester’s identity and capabilities. In WordPress, rely on capability checks like current_user_can('manage_options') or more fitting capabilities for the plugin.
• Use nonces in any AJAX/REST endpoint tied to sensitive actions and verify them server-side.
• Store backups outside webroot or behind authenticated gates, and use temporary signed URLs for downloads.
• Minimize the amount of sensitive data included in backups (exclude logs and transient credentials where possible).

If you’re a plugin author, apply defense-in-depth: authorization + input validation + rate-limiting + logging.

---

How WP‑Firewall helps protect your WordPress sites

As a security provider focused on WordPress, WP‑Firewall offers a layered approach that helps protect sites from vulnerabilities like this one:

• Managed WAF rules that can be deployed rapidly to block exploit attempts against known vulnerable plugin endpoints.
• Malware scanning to identify suspicious files or changes indicative of compromise.
• Virtual patching (temporary rule-based mitigation) for high risk vulnerabilities until the vendor patch is applied.
• Continuous monitoring and security alerts so you’re informed early about suspicious activity.
• Access to remediation guidance and escalation for suspected compromises.

If you want to evaluate a hands‑on protective layer quickly, WP‑Firewall’s free Basic plan includes essential protection (managed firewall, unlimited bandwidth, WAF, malware scanner, and mitigation for OWASP Top 10 risks) and can be activated immediately to reduce exposure while you patch.

Start protecting your site with WP‑Firewall Free Plan

Secure your site quickly with our Basic (Free) plan — it includes managed firewall protection, an application layer WAF, malware scanning, and safeguards against common OWASP Top 10 risks. Activate it now and gain a protective virtual patch while you update Everest Backup to the fixed release:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(If you need automatic malware removal or IP blacklist/whitelist control, review our Standard and Pro offerings that expand protection and operational control.)

---

Final recommendations (what we want you to do now)

1. Check the Everest Backup plugin version on every WordPress site you manage. Update to v2.3.6 or later immediately.
2. If you cannot update immediately, deactivate the plugin and put mitigations in place (WAF/server rules).
3. Review logs and scan for compromise — especially download attempts or archive retrievals.
4. Move future backups off webroot and enable encryption and signed URLs for downloads.
5. Consider a managed WAF that can quickly deploy virtual patches and monitor suspicious activity while you manage updates.

---

Appendix — helpful commands and checks

Check plugin version via WP‑CLI:

wp plugin get everest-backup --field=version

List files in potential backup directories (SSH):

ls -lah wp-content/plugins/everest-backup/
ls -lah wp-content/uploads/ | grep -i backup

Search logs for requests referencing backup-related paths:

# Example for Apache logs
grep -iE "everest|ebackup|backup|download|backup_id" /var/log/apache2/access.log

# Example for Nginx logs
grep -iE "everest|ebackup|backup|download|backup_id" /var/log/nginx/access.log

Check for recent downloads by content type in logs:

grep -i "application/zip" /var/log/nginx/access.log | tail -n 50

---

If you need assistance, WP‑Firewall support can help you:

• Verify whether a site has been probed or exploited,
• Recommend immediate virtual patches and firewall rules, and
• Assist with incident response steps.

Stay safe — treat backup-related vulnerabilities with the urgency they deserve, because in many cases a backup leak is equivalent to handing an attacker the keys to the kingdom.

— WP‑Firewall Security Team