Critical XSS in Keep Backup Daily Plugin

Plugin Name	Keep Backup Daily
Type of Vulnerability	Cross-Site Scripting (XSS)
CVE Number	CVE-2026-3577
Urgency	Low
CVE Publish Date	2026-03-20
Source URL	CVE-2026-3577

Authenticated (Admin) Stored XSS in Keep Backup Daily (<= 2.1.2) — Risk, Detection, and Practical Mitigations from WP‑Firewall

Summary: A stored Cross‑Site Scripting (XSS) vulnerability (CVE‑2026‑3577) was reported in the Keep Backup Daily WordPress plugin affecting versions <= 2.1.2. The vulnerability allows a malicious script to be stored in a backup’s title and executed in the context of privileged users. The issue is patched in version 2.1.3. Below we explain the risk, real‑world impact, recommended short‑term mitigations (including WAF/virtual patching), and long‑term secure coding and operational practices.

We write as practitioners who defend WordPress sites every day. Our goal is to give clear, practical steps site owners and developers can take immediately — whether you run a single site, manage dozens, or build plugins/themes.

---

TL;DR (What to do right now)

• If you use Keep Backup Daily, update to 2.1.3 or later immediately. This is the single best fix.
• If you cannot update right away:
  • Apply WAF rules or virtual patches to block suspicious input (see example rules below).
  • Search for stored payloads (backup titles containing HTML/script tags) and remove or sanitize them.
  • Reset and rotate admin credentials and invalidate sessions if you find evidence of exploitation.
  • Audit other plugins and users for suspicious accounts or activity.
• Harden admin access: enable strong passwords, role audits, session management, and 2FA.
• Consider placing temporary restrictions so only trusted IP ranges can reach wp‑admin.

---

What is the vulnerability?

• A stored Cross‑Site Scripting (XSS) flaw exists in Keep Backup Daily plugin versions up to and including 2.1.2.
• The vulnerability occurs because user‑supplied backup titles are not properly sanitized or escaped before being stored or later rendered in the admin UI.
• An attacker with the ability to add or edit backups (Administrator role) can include JavaScript or HTML payloads in the backup title. When the backup listing or other pages render that title in a privileged admin’s browser, the script executes with the admin’s privileges.
• The flaw is classified as “stored XSS” because malicious content is persisted on the server and triggered later when the victims load affected pages.
• CVE: CVE‑2026‑3577. CVSS (reported) 5.9. Patched in Keep Backup Daily 2.1.3.

Important nuance: This vulnerability requires an account with administrative privileges (or equivalent access to the backup creation/edit functionality) to write the payload. That limits direct remote exploitation by anonymous attackers — but the impact can be severe in real‑world scenarios where an admin account is compromised or where an attacker can trick a privileged user into performing an action (for example, via social engineering, or via lower‑privilege accounts that can create backups on some installations). Stored XSS in the admin context can be abused to:

• Steal authentication cookies or session tokens.
• Perform actions on behalf of the admin (install plugins, create users).
• Upload or modify files (backdoors) or create scheduled tasks.
• Pivot to broader site compromise and persistence.

---

Realistic attack scenarios

1. Malicious insider or compromised admin account:
   • An attacker controls an admin account or can create backups. They inject a script into a backup title. When another admin views the backups list, the script executes and issues admin‑level actions (install malware, add a backdoor user).
2. Social engineering + limited access:
   • An attacker convinces an admin to import or click a crafted backup link or to view a particular admin screen. If the crafted backup title contains payload, it executes in that admin’s browser.
3. Secondary compromise by plugins/themes:
   • If an attacker has compromised a lower‑privilege plugin that can create backups or otherwise add entries, they might be able to store payloads that later execute when a higher privilege user views the list.

Even though initial write requires elevated privileges, stored XSS in admin areas is high‑value because it targets privileged contexts.

---

What to avoid: don’t panic, but act fast

This is not a public, unauthenticated remote code execution. Nevertheless:

• Treat stored XSS in admin screens seriously. The consequences are disproportionately large — local stored script execution in an admin browser is effectively equivalent to giving remote attackers admin control if they can get an admin to load the malicious page.
• Don’t leave the plugin unpatched for long. Apply the vendor patch or remove the plugin if you do not need it.

---

Immediate remediation steps (action plan)

1. Update the plugin (FIRST PRIORITY)
   • Upgrade Keep Backup Daily to version 2.1.3 or later immediately on all affected sites.
   • If automatic updates are enabled and trusted, ensure the update completed successfully.
2. If you cannot update immediately: enable temporary virtual patching or WAF rules
   • Block/monitor requests that create or edit backups with suspicious characters (script tags, angle brackets).
   • Block POST requests to the plugin’s endpoints that include suspicious payloads in the title field.
   • Filter output when admin pages render backup titles (block markup that includes script tags).
3. Search for stored payloads and clean them
   • Look for backup titles that contain “<“, “>” or “script”, or other suspicious HTML.
   • Remove or sanitize those rows from the database. Replace with safe text.
4. Rotate all active admin passwords and invalidate sessions
   • Force logout of all users and require fresh authentication.
   • Enable 2‑factor authentication for all admin users.
5. Run a full security scan
   • Scan files and database for webshells, recently modified files, new admin users, or scheduled tasks (cron events).
6. Audit logs
   • Review access logs and plugin logs. Look for suspicious admin actions, changes to plugin files, or unknown IP addresses.
7. Restore from a known good backup if compromise identified
   • If you find evidence of compromise that you cannot confidently clean, restore from a pre‑compromise backup and apply the plugin update immediately.

---

WP‑Firewall short‑term virtual patch (recommended)

If you run WP‑Firewall, you can deploy virtual patching rules which do not require modifying plugin code. Virtual patching blocks exploitation patterns at the HTTP layer. Below are safe example patterns you should consider. (Treat them as starting points; test on staging before applying sitewide.)

Note: these examples are pseudocode/regex guidance intended for WAF engines. Exact implementation depends on your firewall tooling.

Block suspicious backup title input (server‑side POSTs to plugin endpoints):

# Example: block POST where title parameter contains <script or onerror=
SecRule REQUEST_METHOD "POST" "phase:2,chain,deny,status:403,msg:'Block possible XSS in backup title'"
SecRule ARGS_NAMES|ARGS "(/(backup|title)/i)" "chain"
SecRule ARGS|ARGS_NAMES "<script|</script>|onerror=|javascript:" "t:none,log,deny"

Block storing of HTML tags in fields intended to be plain text:

# Deny if parameter 'backup_name' contains angle brackets
SecRule ARGS:backup_name "<|>" "id:12345,phase:2,deny,log,msg:'XSS attempt in backup title'" 

Block common XSS vectors on admin pages:

# Block script tags in any request hitting admin-ajax or plugin backends
SecRule REQUEST_FILENAME "admin-ajax.php|/wp-admin/admin.php|/wp-json/keep-backup-daily/" "phase:1,chain,deny,msg:'Admin XSS protection'" 
SecRule REQUEST_BODY "<script|onmouseover=|onload=|javascript:" "t:none,deny,log"

Rate limiting and IP reputation checks:

• Temporarily restrict requests that create backups from unusual IPs or geolocations.
• Apply additional scrutiny to API endpoints.

Important: Virtual patching is a mitigation — not a substitute for an official plugin update. Test carefully to avoid blocking legitimate admin workflows.

---

Safe code fixes for plugin developers (recommended edits)

If you are a developer maintaining the plugin or a site developer who can edit plugin templates, do two things:

1. Sanitize input on save
2. Escape output on render

Example: When saving backup title in PHP:

<?php
// When receiving POST data for title
if ( isset( $_POST['backup_title'] ) ) {
    // sanitize input to strip HTML entirely
    $title = sanitize_text_field( wp_unslash( $_POST['backup_title'] ) );
    // Save $title to the database
}
?>

When rendering the title in admin lists:

// Safe escape
echo esc_html( $backup->title );

If limited HTML is required, use a strict allowed list with wp_kses():

$allowed = array(
    'b' => array(),
    'i' => array(),
    'strong' => array(),
    'em' => array(),
);
$safe_title = wp_kses( $raw_title, $allowed );
echo $safe_title;

Always ensure capability checks and nonces on form handlers:

if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( 'Insufficient privileges' );
}
check_admin_referer( 'create_backup_nonce', 'backup_nonce' );

---

How to detect whether your site was targeted

1. Search backup records for HTML/script tags

Using WP‑CLI:

# Look for script tag in posts or plugin-related tables (example)
wp db query "SELECT id, backup_title FROM wp_keep_backup_daily_backups WHERE backup_title LIKE '%<script%';"

If the plugin stores backups in custom post types or options, adapt query accordingly.

2. Search entire database for suspicious patterns

# Generic check for "<script" across database
wp db query "SELECT table_name, column_name FROM information_schema.columns WHERE table_schema = DATABASE() AND DATA_TYPE IN ('text','varchar');" > columns.txt
# Then grep those columns for <script — caution: this approach needs a script to iterate columns safely

3. Check file modification dates

Look for recently changed files, new plugin or theme files, and unknown PHP files in uploads.

4. Review admin sessions and recent logins

• Check wp_users for recent password resets.
• Check security/audit logs if available.

5. Scan with a trusted malware scanner (file & DB)

---

Incident response checklist (if you detect exploitation)

1. Isolate:
   • Temporarily place site in maintenance mode or restrict admin access by IP.
   • If using managed hosting, engage the host to isolate.
2. Identify:
   • Locate stored XSS payloads (backup titles).
   • Search for web shells or suspicious scheduled tasks.
3. Contain:
   • Remove the malicious backup entries (backup titles).
   • Apply WAF rules to block payloads.
4. Eradicate:
   • Remove any backdoors, unknown admin users, or modified core/plugin files.
   • Restore from a clean backup if eradication is complex.
5. Recover:
   • Apply plugin updates (Keep Backup Daily 2.1.3 or later).
   • Harden admin accounts: reset passwords, enable 2FA, rotate API keys, and invalidate sessions.
6. Post‑incident:
   • Conduct a full audit and root cause analysis.
   • Implement monitoring and continuous scanning.
   • Notify stakeholders if required by policy/compliance.

---

Hardening advice — reduce the likelihood of similar issues

• Principle of least privilege
  • Grant admin rights only to those who truly need them. Use lower privilege roles for daily tasks.
• Enable strong authentication
  • Enforce strong passwords and 2FA for all admin accounts.
• Audit users regularly
  • Remove stale accounts; limit shared accounts.
• Keep plugins and themes up to date
  • Prioritize security updates and test in staging before production.
• Limit plugin footprint
  • Remove unused plugins and themes to reduce attack surface.
• Monitoring and alerting
  • Monitor admin page access, file changes, and new scheduled tasks.
• Staging and testing
  • Deploy updates first to staging and verify WAF rules and site functionality.
• Content security policy (CSP)
  • Implement CSP where possible to limit where scripts can be loaded from (note: CSP must be implemented carefully on WordPress sites).

---

Log and forensic tips

• Preserve logs immediately (web server, PHP error logs, access logs).
• Keep DB snapshots before cleaning for deep forensics.
• Record exact timestamps and IPs associated with suspicious actions.
• If you suspect data theft, document impacted accounts and follow legal/notification requirements in your jurisdiction.

---

Guidance for hosts and agencies managing many sites

If you manage multiple sites, apply these controls centrally:

• Bulk patching process
  • Implement a scheduled patching program to apply plugin updates quickly across your fleet.
• Centralized WAF policies
  • Deploy virtual patches to block the known exploitation pattern until every site is updated.
• Role and session policies
  • Enforce side policies like SSO, centralized logging, and 2FA across client sites.
• Automated scanning and reporting
  • Run periodic scans to detect stored XSS and unpatched plugins.
• Client communications
  • Notify clients about the vulnerability and the steps you’ve taken, including actions they should perform (password resets, 2FA).

---

Example database cleanup SQL (use with extreme caution; test first)

If backups are stored in a plugin table named wp_keep_backup_daily_backups and backup_title is the column:

-- Find suspicious entries (dry run)
SELECT id, backup_title, created_at FROM wp_keep_backup_daily_backups
WHERE backup_title LIKE '%<script%' OR backup_title LIKE '%<%';

-- Remove script tags from backup_title safely using REGEXP_REPLACE (MySQL 8+)
UPDATE wp_keep_backup_daily_backups
SET backup_title = REGEXP_REPLACE(backup_title, '<script[^>]*>.*?</script>', '')
WHERE backup_title REGEXP '<script';

-- Alternatively, set to sanitized placeholder
UPDATE wp_keep_backup_daily_backups
SET backup_title = CONCAT('Sanitized backup - ID ', id)
WHERE backup_title REGEXP '<script';

Important: Back up the database before any mass updates. If you’re uncomfortable running SQL, work with your developer or host.

---

Why stored XSS in admin context is high‑value to attackers

• Admin sessions and cookies grant access to site management; scripts running in that context can impersonate the admin and perform any action available via the admin UI.
• Stored XSS can persist across admin sessions — giving attackers time to act.
• Attackers often chain vulnerabilities: initial access (weak admin password or other plugin compromise) + stored XSS → full site takeover.

---

How WP‑Firewall protects you (what we provide and how it helps)

As the team that builds and manages WP‑Firewall, we design protections that help both prevent and respond to incidents like this one:

• Managed Web Application Firewall (WAF)
  • Virtual patching: deploy rule sets to block exploitation patterns immediately, without touching plugin code.
  • HTTP request inspection and blocking for known XSS payload patterns, both on public and admin endpoints.
  • Rate limiting and IP reputation checks to catch repeated exploit attempts.
• Malware scanning
  • Continuous file and database scanning that looks for script injections, suspicious PHP files, and backdoor signatures.
• Mitigation of OWASP Top 10 risks
  • Automated rule mappings for common injection vectors, including XSS and more advanced injection types.
• Unlimited bandwidth and reliable enforcement
  • WAF runs at the application layer and is optimized not to interfere with legitimate admin workflows when properly configured.
• Auto‑remediation options (on paid plans)
  • For example, automatic blocking of known exploit payloads and quarantining of suspicious files.

Remember, the WAF is a layer in a defense‑in‑depth strategy — not a replacement for timely updates, secure coding, or least‑privilege administration.

---

Developer checklist: building resilient plugins

If you write plugins, follow these practices to avoid stored XSS and similar issues:

1. Validate & sanitize input:
   • Use sanitize_text_field() for text inputs.
   • For HTML inputs, use wp_kses() with a strict allowed list.
2. Escape output:
   • Always escape before printing in templates: esc_html(), esc_attr(), esc_url(), or wp_kses_post() as appropriate.
3. Capability checks & nonces:
   • Verify user capabilities (current_user_can()) and nonces for admin actions.
4. Minimal trust:
   • Treat every input as hostile, even from authorized users.
5. Logging & monitoring hooks:
   • Provide hooks for audit logging and make debug information easy to extract.
6. Security reviews & automated tests:
   • Include security unit tests that validate data flows and proper escaping.

---

New: Secure your admin area in minutes — Try WP‑Firewall Basic (Free)

We regularly see practitioners need a fast, no‑risk way to add a robust layer of protection while they patch and clean. Our Basic (Free) plan is designed exactly for that — to give immediate, essential protection with no cost and no long‑term commitment.

What the Basic (Free) plan includes:

• Managed firewall with essential WAF protections
• Unlimited bandwidth for firewalling
• Malware scanner to detect file and database injections
• Mitigation coverage for OWASP Top 10 risks

If you want immediate baseline protection—deployed in minutes—sign up for the WP‑Firewall Basic (Free) plan here:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Final recommendations — prioritized checklist

1. Update Keep Backup Daily to 2.1.3 (or remove it if not needed).
2. If you cannot update immediately:
   • Deploy WAF rules or virtual patching blocking script tags in backup titles.
   • Search and sanitize stored backup titles.
   • Force a credential rotation and invalidate sessions.
3. Harden admin access: 2FA, role audits, and remove unnecessary admin users.
4. Scan the site for web shells, backdoors, and unusual files.
5. Put monitoring in place to detect abnormal admin page access or modifications.
6. If you manage multiple sites, push the update across your fleet and use centralized WAF rules.

---

Closing thoughts from WP‑Firewall

Stored XSS in admin pages is deceptively dangerous. Attackers rarely need to land an RCE if they can run JavaScript in the context of an admin session — the admin’s browser becomes the vector for privilege escalation and persistence. Patching the plugin is necessary, but we strongly recommend a layered response: update the plugin, harden admin access, scan for persisted payloads, and use virtual patching/WAF while you finish clean-up.

If you need help implementing WAF rules, scanning your sites, or restoring and hardening after an incident, our security team at WP‑Firewall can assist. We provide managed WAF, malware scanning, and incident response guidance tailored to WordPress. Consider starting with our Basic (Free) plan to get immediate protection while you patch and validate.

Stay safe, and if you need a hand, we’re here to help.