Critical: Path Traversal + Arbitrary Directory Deletion in JetBackup / Backup Guard (CVE-2026-4853) — What WordPress Site Owners Need to Know and How to Protect Themselves

Publié : 17 Apr, 2026
Plugin affecté : JetBackup / Backup Guard (plugin slug: backup)
Versions vulnérables : <= 3.1.19.8
Version corrigée : 3.1.20.3
CVE : CVE-2026-4853
Gravité : Low (CVSS: 4.9) — but do not be lulled: practical impact can be significant if an attacker obtains or already controls an Administrator account.

Written by Hong Kong security researchers and practitioners. This advisory explains the technical details, realistic risk scenarios, detection and mitigation strategies, practical WAF rules, incident response steps, and hardening guidance so site owners and hosts in the region and beyond can act quickly and confidently.

Résumé exécutif (court)

• Quoi : Path traversal in plugin backup delete handler via the nom de fichier parameter. An authenticated Administrator can use traversal sequences (../) to target directories outside expected backup folders and trigger deletion.
• Qui est affecté : Sites running the plugin at versions <= 3.1.19.8.
• Impact : Arbitrary directory deletion (site files, uploads, backups, logs) — destructive if exploited. Requires Administrator privileges to exploit, so attacks are most likely after admin account compromise or misuse.
• Correction immédiate : Update the plugin to 3.1.20.3 or later.
• Atténuations provisoires : Apply WAF rules to block traversal payloads, restrict admin-panel access by IP, disable the plugin or the vulnerable deletion endpoint until patched, harden file permissions and ensure robust off-site backups.

How the vulnerability works (technical overview, non-exploitable explanation)

The issue stems from insufficient validation and canonicalization of a user-supplied nom de fichier parameter used to construct filesystem paths for deletion. If the plugin concatenates a base path with the supplied filename without normalizing or enforcing that the resolved path remains within an expected directory, an attacker can include sequences like ../../ to escape the intended folder and delete arbitrary files or directories.

Typical root causes for this class of bug:

• No canonicalization / realpath check — trusting a concatenated path without verifying the resolved path is within an allowed base directory.
• Using arbitrary filenames instead of restricting to basenames or a whitelist of known backups.
• Insufficient CSRF/nonce protections on sensitive endpoints (even though this specific flaw requires admin capability to exploit).
• Allowing recursive deletion routines to operate on attacker-controlled paths.

Because deletion functions can be recursive, the effect can escalate from removing a single file to wiping entire directories, including backups and uploads.

Exploitation scenarios and practical impact

Although exploitation requires Administrator privileges, real-world scenarios that enable such abuse include:

1. Admin credential compromise: Phishing, password reuse, or leaked credentials leading to an attacker logging in as an admin and issuing crafted delete requests.
2. Malicious insider or contractor: A legitimate admin abusing their access.
3. Attaques en chaîne : An attacker with partial control (e.g., a vulnerable plugin or theme) can escalate or combine weaknesses to gain admin access and then trigger destructive deletes.

Impact potentiel :

• Removal of backup directories and stored backups (loss of recovery path).
• Deletion of uploads, themes, plugins, or wp-content files.
• Erasure of logs and forensic artifacts.
• Potential deletion of configuration or directories outside webroot if traversal allows leaving the intended base directory.
• Service outage and costly recovery efforts.

Immediate action checklist (what to do right now)

1. Mettez à jour le plugin à 3.1.20.3 or later. Test on staging before rolling to production.
2. Si vous ne pouvez pas mettre à jour immédiatement :
   • Disable the plugin or the delete functionality until patched.
   • Restreignez l'accès à /wp-admin/ and plugin endpoints to trusted IP addresses where possible.
   • Apply temporary WAF rules to block path traversal patterns in the nom de fichier paramètre.
3. Rotate all administrator credentials and enforce multi-factor authentication for admin accounts.
4. Verify off-site backups and ensure a tested recovery plan exists.
5. Monitor logs closely for suspicious deletion requests and file removals.
6. Inform stakeholders (site owners, hosts, operations) and prepare an incident response plan if deletions are observed.

Detection: how to detect attempted or successful exploitation

Search access logs, audit logs and filesystem events for indicators such as:

• HTTP requests to plugin deletion endpoints with parameters named fileName, nom de fichier, fichier, nom containing traversal sequences, for example:
  • filename=../../
  • filename=..%2F..%2F
  • fileName=%2e%2e%2fwp-content%2fuploads
• Any parameter values containing ../, ..\ ou équivalents encodés en URL (%2e%2e%2f, %2e%2e%5c).
• Sudden disappearance of files or directories in wp-content, téléchargements or plugin backup folders.
• File-system monitoring alerts for high numbers of dissocier ou rmdir operations.
• Admin logins from unusual IPs followed by delete requests.

High-level detection rules:

• Flag requests where parameters named case-insensitively like nom de fichier contain traversal tokens.
• Alert on admin-ajax calls with plugin-specific actions that contain traversal sequences.
• Log and review any rmdir ou dissocier errors affecting unexpected paths.

Examples of forensic commands (use carefully and with appropriate permissions):

# Find files in webroot modified in last 7 days
find /var/www/html -type f -mtime -7 -ls

# Search access logs for traversal patterns
grep -E "(filename|fileName|file)=.*(\.\./|%2e%2e%2f)" /var/log/nginx/access.log | tail -n 200

Virtual patching & WAF rules (practical signatures you can apply now)

A WAF can block many exploitation attempts. Below are defensive rule templates — test them in monitoring mode before blocking in production.

ModSecurity-style (conceptual)

# Block requests where any argument name contains 'filename' and value contains ../ or encoded variants
SecRule ARGS_NAMES|ARGS "@rx (?i:filename)" "phase:2,deny,log,msg:'Block possible Backup plugin path traversal attempt', \
  chain"
SecRule ARGS "@rx (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)" "t:none,deny,status:403"

Exemple Nginx

if ($arg_filename ~* "\.\./|%2e%2e%2f") {
    return 403;
}
# Repeat checks for $arg_fileName or other expected parameter names

Practical guidance for WAF rules:

• Target rules to the plugin’s delete endpoint (e.g., /wp-admin/admin-ajax.php?action=backup_delete) pour réduire les faux positifs.
• Detect raw and encoded traversal sequences including Unicode variants.
• Combine pattern matching with rate-limiting and IP whitelists for admin endpoints.
• Log full request payloads for forensic review when blocking.

Example safe hardening code for plugin authors / dev teams

Plugin developers should canonicalize paths, enforce whitelists, and verify that resolved paths are inside an allowed directory. Example conceptual PHP handling:

<?php
// Example: safe-delete.php (conceptual)
if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( 'Unauthorized', 403 );
}

// Verify nonce if deletion is triggered via AJAX / form
check_admin_referer( 'backup_delete_action', 'backup_nonce' );

$raw_filename = isset( $_REQUEST['fileName'] ) ? wp_unslash( $_REQUEST['fileName'] ) : '';

if ( empty( $raw_filename ) ) {
    wp_die( 'Missing filename', 400 );
}

// Only allow basename (no slashes allowed) OR apply a strict whitelist
$filename = basename( $raw_filename );

// Ensure the target directory is the plugin's expected backup directory
$backup_dir = wp_normalize_path( WP_CONTENT_DIR . '/uploads/plugin-backups' );
$target_path = wp_normalize_path( $backup_dir . '/' . $filename );

// Resolve real paths
$real_backup_dir = realpath( $backup_dir );
$real_target = realpath( $target_path );

if ( $real_backup_dir === false || $real_target === false ) {
    wp_die( 'Invalid path', 400 );
}

// Ensure the resolved target is a child of the expected backup dir
if ( strpos( $real_target, $real_backup_dir ) !== 0 ) {
    wp_die( 'Forbidden', 403 );
}

// At this point it's safe to delete the specific allowed file
if ( is_file( $real_target ) ) {
    unlink( $real_target );
    wp_send_json_success( array( 'message' => 'Deleted' ) );
} else {
    wp_send_json_error( array( 'message' => 'Not a file' ) );
}
?>

Key checks shown:

• Capability check (current_user_can)
• Vérification de nonce
• 7. Utilisation de basename() or a whitelist to prevent slashes
• 7. Utilisation de realpath() and prefix checks to ensure the target is inside the expected directory

Host-level mitigations you can apply now

• Restrict admin area access to trusted IPs using firewall or webserver access lists.
• Use open_basedir to limit PHP to permitted directories.
• Configure file permissions so the webserver user cannot delete arbitrary system files (while allowing plugin needs).
• Use SELinux/AppArmor to restrict WordPress/PHP access to the filesystem.
• Enable process-level auditing (auditd) to capture file removals by PHP processes.
• Keep off-site backups outside the webserver filesystem to ensure recoverability.

Réponse aux incidents : si vous soupçonnez une exploitation.

1. Isolate the site immediately (maintenance mode or take offline) to prevent further damage.
2. Preserve logs and forensic data — copy access logs, error logs and application logs to an immutable store.
3. Restore from a known-good off-site backup (not the plugin-managed backups if you suspect deletion).
4. Rotate all administrator credentials and any API keys, tokens or database credentials.
5. Force password resets for privileged users and enable MFA.
6. Scan for backdoors, suspicious cron jobs, new admin users, or modified plugin/theme files.
7. Reinstall WordPress core and plugins/themes from official sources or restore a validated backup.
8. If needed, engage an experienced incident response specialist and share preserved forensic artifacts.

Long-term recommendations and best practices

• Minimal privilege: reduce the number of admin accounts and use least-privilege roles.
• MFA everywhere for privileged roles.
• Regular updates: maintain an update cadence and test updates in staging.
• Hardened backups: keep multiple, automated off-site backups and periodically test restores.
• Plugin vetting: keep a curated list of actively maintained plugins and remove unused ones.
• Secure SDLC: developers must validate inputs, canonicalize paths and apply least-privilege checks on file operations.
• Logging & monitoring: deploy SIEM or log aggregation to alert on suspicious admin activity and deletion events.

Practical WAF rule examples (more)

Validate rules in staging before production. Ideas:

1. Block requests where parameter names match (?i:file(Name)?) and values contain traversal tokens.
2. Block admin-ajax calls with action=backup_delete unless coming from whitelisted IPs or including a valid nonce.
3. Detect and block encoded traversal (%2e%2e%2f) and Unicode variants.
4. Rate-limit delete endpoints to a low number per minute per admin or IP.

Why update even if the CVSS looks “low”?

CVSS is one metric. Context matters. While this flaw requires Administrator privileges, admin accounts are often compromised via weak passwords, reuse, or phishing. Once an attacker has admin access, deletion capabilities can be catastrophic — removing backups, uploads and site data. Also, attackers chain vulnerabilities: a small foothold plus this deletion ability magnifies damage. Treat this as a high-priority operational risk if you run production sites.

Example monitoring queries and alerts

• Alert when an admin user issues a delete call to plugin endpoints with ../ dans les paramètres.
• Alert on bulk file removals from wp-content/uploads or plugin backup folders.
• Daily digest: list of file deletions by PHP-FPM processes in webroot.

# Look for traversal patterns in access logs
grep -E "(filename|fileName|file)=.*(\.\./|%2e%2e%2f)" /var/log/nginx/access.log | tail -n 200

After the patch: verify and validate

• Confirm deletion works for legitimate backup files but cannot traverse out of the designates directory.
• Test backup and restore flows for errors.
• In staging, attempt a traversal deletion payload to verify it is rejected and logged.
• Keep detection rules enabled to alert on unusual activity even after patching.

Timeline and responsible disclosure (brief)

This vulnerability was responsibly disclosed to the vendor and patched in version 3.1.20.3. CVE-2026-4853 was assigned to track the issue. The primary remediation is updating to the patched release.

Practical example: what a hosting admin should do in 15–60 minutes

Fast playbook for hosting admins:

1. 0–10 min: Identify affected sites (installed plugin version <= 3.1.19.8). Notify stakeholders.
2. 10–30 min: If feasible, update the plugin on staging, then production. If not, disable plugin or restrict access to admin endpoints.
3. 30–60 min: Apply temporary WAF rules blocking traversal patterns, rotate admin credentials and enable MFA, verify off-site backups and create an additional backup if possible.

Final notes — balancing urgency with safety

Update to 3.1.20.3 or later as soon as practical. If immediate update is impossible, use layered mitigations: conservative WAF rules, IP restrictions, disabling the plugin, or disabling delete capabilities until the patch is applied. Always ensure off-site backups are intact before making sweeping remediation changes. For complex incidents, engage experienced incident response specialists and preserve forensic data.

Prepared by Hong Kong security experts — practical, region-aware advice for site owners, developers and hosts.