Urgent: Stored XSS in “Keep Backup Daily” (<= 2.1.2) — What WordPress Owners Need to Know and Do Now

Date: 20 Mar, 2026

Vulnerability: Authenticated (Administrator) Stored Cross-Site Scripting (XSS) via backup title

Affected versions: Keep Backup Daily plugin <= 2.1.2

Patched in: 2.1.3

CVE: CVE-2026-3577

Reported priority: Low (CVSS 5.9) — but should not be ignored

From a Hong Kong security expert perspective: this advisory provides a practical, no-nonsense breakdown of a stored XSS affecting the Keep Backup Daily plugin. The guidance below is targeted at developers, site owners and administrators who need clear, actionable steps for detection, triage and recovery.

Summary: an authenticated administrator can store JavaScript or HTML in a backup title. If that content is later rendered unsafely in the admin UI, it executes in the browser of whoever views that UI — enabling session theft, privilege escalation or persistent compromise.

1 — What happened (technical summary)

• The plugin stores a backup “title” value and renders it in an admin view without proper escaping/sanitization.
• An authenticated administrator can create a backup with JavaScript or HTML in the title. Because the UI outputs that title without context-aware escaping, the content can execute in the browser of another user who views the page.
• This is a stored (persistent) XSS vulnerability: malicious content persists in the backend (database or metadata) and is served to users later.
• The vendor released a fix in version 2.1.3 that implements appropriate sanitization/escaping. Sites still on <= 2.1.2 remain at risk.

2 — Risk analysis and impact

Although injection requires an administrator to plant the payload, the impact is non-trivial in real-world contexts. Practical concerns include:

• Compromised admin accounts / rogue admins: If an attacker or insider obtains admin credentials, they can plant a persistent payload that runs when other admins view the UI — spreading the compromise.
• Privilege escalation & persistence: Executed JavaScript has the same privileges as the logged-in admin. It can exfiltrate session tokens, perform admin actions (install plugins, create users), and inject backdoors into files.
• Multi-site and supply-chain risk: Managed platforms, agency environments or multi-site setups increase the blast radius since multiple accounts/sites may access the same admin surfaces.
• Reputation & SEO damage: Persistent scripts can cause redirects, spam insertion, or stealthy content modification that harms SEO and trust.

3 — Exploitation scenarios (high-level)

We do not publish exploit code, but here are credible threat scenarios:

• Credential reuse: Attacker uses stolen/reused credentials to log in, plants malicious backup title, waits for other admins to view the UI and captures session tokens.
• Phishing-assisted execution: Attacker entices an admin to click an internal link; the stored XSS executes and performs actions via the admin UI on behalf of the victim.
• Insider abuse: A disgruntled or malicious administrator plants payloads to sabotage or exfiltrate data.

4 — Immediate actions (triage & patching)

1. Update: Upgrade Keep Backup Daily to 2.1.3 or later immediately. This is the definitive fix.
2. If you cannot update immediately:
   • Temporarily disable the plugin if backups can be handled elsewhere (host backups, alternate plugins).
   • Limit access to the backup interface (restrict by IP or VPN, and lock down admin accounts).
   • Enable heightened monitoring of admin actions.
3. Rotate credentials and enable MFA: Enforce multi-factor authentication for all administrators and rotate passwords if compromise is suspected.
4. Inspect backups and metadata: Search for backup titles containing
5. Full site scan: Scan uploads, themes, plugins and database for malicious changes; look for recent file modifications and unexpected admin users.
6. Audit logs: Review admin activity logs for backup creation, user creation, plugin installations and suspicious IP addresses.
7. If compromised: Isolate the site (maintenance mode, temporary network block), preserve logs and filesystem snapshots, and follow an incident response plan.

5 — How to detect exploitation (indicators of compromise)

Look for the following signs:

• Backup titles or metadata containing
• Unexpected admin actions: new admin users, plugin installs, or changes you did not authorise.
• Browser anomalies reported by admins: popups, automatic form submissions, or redirects when opening the backup page.
• Outbound requests from the admin dashboard to unknown external domains (possible exfiltration endpoints).
• Web server logs showing POST requests to plugin endpoints with suspicious payloads.

Search plugin-specific database tables and wp_options for suspicious metadata entries.

6 — WAF / Virtual patching guidance (recommended rules)

If you cannot update immediately, a well-tuned WAF or virtual patch can reduce exposure temporarily. Guidance:

• Target rules to plugin-specific endpoints that handle backup creation/edit actions to avoid broad false positives.
• Block or sanitize requests containing tag-like content in fields that should only be plain text (backup title).
• Deny or challenge requests with patterns like
• Progressively deploy rules: monitor/log first, then challenge (CAPTCHA), and finally block once tuned.

Conceptual ModSecurity example (adjust to your environment and test before use):

SecRule REQUEST_METHOD "POST" "chain,deny,status:403,id:100001,phase:1,log,msg:'Block possible stored XSS in backup title'"
    SecRule ARGS_POST_NAMES|ARGS_NAMES "backup_title|title|backup-name" "chain"
    SecRule ARGS|REQUEST_BODY "(?:<\s*script\b|on\w+\s*=|javascript:|%3Cscript%3E)" "t:none,t:lowercase,log,deny"

Conceptual Nginx+Lua pseudo-code:

-- pseudo-code: check request body for suspicious patterns in fields named 'backup_title'
local body = ngx.req.get_body_data()
if body then
  if string.match(body:lower(), '"backup_title"%s*:%s*"[^"]*

SELECT option_id, option_name, option_value
FROM wp_options
WHERE option_name LIKE '%backup%'
  AND (option_value LIKE '%

SELECT ID, post_title, post_date
FROM wp_posts
WHERE post_content LIKE '%