Plugin Name	WPvivid Backup and Migration
Type of Vulnerability	WordPress vulnerabilities
CVE Number	CVE-2026-1357
Urgency	Critical
CVE Publish Date	2026-02-14
Source URL	CVE-2026-1357

February 2026 — What the Latest WordPress Vulnerability Data Means for Site Owners (and How a WAF Should Protect You)

Every month fresh vulnerability data arrives from public research and reporting channels. The February 2026 dataset makes a few things painfully clear: attackers keep targeting plugin functionality that touches file uploads, authentication flows, and administrative user creation — and many of these issues are being actively exploited in the wild.

This post is written from the perspective of hands‑on WordPress security practitioners. We’ll explain the key trends from the latest public vulnerability statistics, walk through recent exploited plugins and the attack vectors they expose, and give practical, prioritized steps you can take to protect your sites today — including immediate virtual patches and WAF measures you can apply while waiting for vendor updates.

If you run or manage WordPress sites, read this start-to-finish and use the checklists. Treat these recommendations as operational guidance — they’re the same actions we use for customer hardening and incident mitigation.

---

At a glance: key statistics you need to know

From the consolidated public vulnerability data for the WordPress ecosystem (year-to-date):

• Total tracked WordPress vulnerabilities: ~1,509
• Vulnerabilities disclosed by coordinated security researchers/alliance programs: ~643
• Most common vulnerability classes (all-time, aggregated):
  • Cross-Site Scripting (XSS): ~38.8%
  • Broken Access Control: ~24.5%
  • Miscellaneous / Other: ~20.8%
  • Cross-Site Request Forgery (CSRF): ~6.3%
  • SQL Injection (SQLi): ~4.6%
  • Sensitive Data Exposure: ~3.6%
  • Arbitrary File Upload: ~1.4%

Two other important operational stats:

• ~59% of disclosed vulnerabilities are reported as fixed; ~41% still unfixed.
• Plugin software accounts for ~88% of tracked vulnerabilities; themes ~12%; core tracked at ~0% in this snapshot.

Implication: plugin attack surface dominates risk. That means plugin selection, lifecycle management, and compensating controls (like a WAF) are the strongest levers you have.

---

Recent exploited plugin incidents — what actually happened

Below are several representative incidents from the recent feed of exploited or widely impactful vulnerabilities. These are real plugin names and summarized attack vectors so you can evaluate exposure on your own sites.

1. WPvivid Backup and Migration (<= 0.9.123) — Unauthenticated Arbitrary File Upload
   • What it is: A file upload implementation allowed unauthenticated requests to store arbitrary files, often without proper validation or storage path restrictions.
   • Why it’s dangerous: Arbitrary file upload commonly leads to remote code execution if the upload can end up in a web‑accessible directory and be executed (e.g., via PHP). Even if code execution isn’t immediate, it’s an easy foothold for attackers to upload webshells, backdoors, or exfiltrate backups.
   • Immediate mitigations: block the vulnerable endpoint (WAF rule), enforce strict file type and MIME checks, deny script execution in upload directories, apply the vendor patch.
2. Profile Builder (< 3.15.2) — Unauthenticated Arbitrary Password Reset / Account Takeover
   • What it is: Flawed password reset or account management endpoints that allowed an attacker to reset or change another user’s password without adequate validation or rate limiting.
   • Why it’s dangerous: Leads to account takeover — especially critical if administrative or editor accounts are affected.
   • Immediate mitigations: disable password reset endpoints if not required, add rate limits and CAPTCHA, enforce email confirmation workflows, and apply patch.
3. LA‑Studio Element Kit for Elementor (<= 1.5.6.3) — Backdoor via parameter (example: lakit_bkrole) that creates admin users
   • What it is: A hidden or poorly validated parameter in an endpoint that can lead to automatic administrative user creation.
   • Why it’s dangerous: Attackers can instantly elevate privileges on a site by creating admin users; backdoors often persist even after other cleanup.
   • Immediate mitigations: search the codebase for the parameter, remove any backdoor code, force password rotation for admin accounts, disable plugin until patched, and use WAF to block requests that include the specific parameter or suspicious payload patterns.
4. Academy LMS (<= 3.5.0) — Unauthenticated Privilege Escalation via Account Takeover
   • What it is: Logic issues in account/session handling allowing attackers to escalate privileges.
   • Why it’s dangerous: Shift from a low‑privilege user to an administrator can lead to full site compromise.
   • Immediate mitigations: tighten session handling, enforce capability checks on any user operations, enable two‑factor authentication for admin accounts.
5. Booking Activities (<= 1.16.44) — Privilege Escalation
   • What it is: Broken access control in AJAX or admin endpoints that didn’t validate current user capabilities.
   • Why it’s dangerous: Unprivileged users or unauthenticated requests performing admin actions.
   • Immediate mitigations: block the relevant endpoints, add capability checks, update plugin.

---

Why attackers focus on these vectors

• File uploads: easy to abuse, especially on sites that accept media or backups. Many developers rely on client-side checks only, or insufficient server-side validation — a classic mistake.
• Authentication flows and password reset: often rely on predictable tokens, lack rate limiting, or are implemented without nonces — leading to account takeovers.
• Backdoor parameters: some plugins expose hidden hooks or development keys that aren’t removed before release; attackers scan for these predictable parameters and automate admin creation.
• Broken access control: endpoint-level checks are often missing, particularly in admin-ajax and REST endpoints.

Because these categories are both common and highly impactful, they show up in the highest percentages in aggregated vulnerability statistics.

---

Immediate actions for site owners — prioritized checklist (what to do in the first 24 hours)

1. Inventory and exposure check (15–60 minutes)
   • Identify all sites using the affected plugin names and versions referenced above.
   • For each site, confirm plugin version. If version is vulnerable, treat as compromised until proven otherwise.
2. Containment (30–120 minutes)
   • If an exploited or high‑risk vulnerability is present and you cannot patch immediately:
     • Put the site into maintenance mode (external visitors blocked).
     • Disable the vulnerable plugin (wp-admin → Plugins → Deactivate) if safe; if not possible, use a WAF rule to block access to the vulnerable endpoints.
     • Rotate administrative passwords and API keys.
   • If you suspect active compromise, take the site offline and preserve logs for forensics.
3. Apply virtual patching / WAF rules (minutes)
   • Block the vulnerable endpoint paths and parameter patterns that were used in reported exploits.
   • Restrict file upload endpoints: disallow known bad content types, only permit necessary extensions, and refuse executable extensions (e.g., .php) in upload requests.
   • Rate‑limit or CAPTCHAs on password reset and authentication endpoints.
4. Scan and validate (1–4 hours)
   • Run a malware scan across the site and file system; look for recently modified files, unknown admin users, and webshell signatures.
   • Check user list (Users → All Users) for unexpected accounts with admin privileges and remove/lock them.
   • Review server & access logs for suspicious POST requests, upload activity, and new admin creation events.
5. Patch and verify (4–24 hours)
   • Apply vendor security patch as soon as it is available and verified.
   • Test the site in staging for functionality and for residual malicious files.
   • If you identify compromise: restore from a clean backup taken before the compromise, after ensuring the exploit’s vector is closed.
6. Post‑incident hardening (24–72 hours)
   • Revoke and reissue credentials (WordPress admin users, FTP/SFTP, database, API tokens).
   • Harden permissions: disallow file editing via wp-config.php (define('DISALLOW_FILE_EDIT', true);), and tune file system permissions.
   • Ensure WAF and malware scanner are in place and configured for continuous protection.

---

WAF and virtual patching — your emergency shield

A modern Web Application Firewall (WAF) gives you time: instead of waiting for vendors to release and your team to test patches, the WAF can apply virtual patches that block exploit patterns. Virtual patching is particularly valuable when exploits are already in the wild.

Practical WAF strategies (generic, vendor-agnostic):

• Block by URI path: deny POST requests to endpoints known to have vulnerable upload or account management functionality.
• Block by parameter or parameter value pattern: e.g., deny requests that include suspicious params such as “lakit_bkrole” or other developer-reserved flags.
• Block file upload content types and enforce server-side MIME validation:
  • Deny requests that claim to be image/* but have PHP or other script content.
  • Enforce max file size and scan uploads with a malware scanner (on the WAF side if supported).
• Employ rate limiting and CAPTCHA protections on password reset and login endpoints.
• Detect and drop requests attempting to create users via AJAX or REST without valid nonces/capabilities.
• Monitor and alert on abnormal admin user creation events.

Example conceptual rule (do not use as a PoC in public): block POST requests with parameter name patterns associated with backdoor endpoints; block POST to known vulnerable upload endpoints unless authenticated and validating a nonce. Implement logging so you can review blocked attempts.

Note: WAF virtual patching is a compensating control, not a substitute for applying vendor patches. It reduces risk and buys you time to perform safe patching and forensics.

---

How to prioritize patches (quick decision guide)

1. If the vulnerability is being actively exploited in the wild — patch immediately. Treat active exploitation as maximum urgency.
2. If vulnerability enables authentication bypass, privilege escalation, file upload, or RCE — patch within hours to days; apply virtual patching immediately.
3. If the vulnerability is XSS or CSRF without privilege escalation — prioritize in line with business context; persistent XSS on high-traffic pages is still critical if it affects admin users or checkout flows.
4. Use CVSS scores as a guide but weigh business context. A medium CVSS on an admin plugin used by your organization may be more urgent than a high CVSS on a rarely used plugin.

---

Incident response checklist (technical steps for suspected compromise)

• Snapshot system state: full file system and database backups, collect logs (webserver, PHP, database, firewall), and preserve timestamps.
• Isolate compromised hosts or sites (network-level block if possible).
• Rotate secrets: WordPress salts and keys, admin passwords, SFTP keys, and any third‑party API tokens.
• Run file integrity checks against a known good baseline; look at recently modified files and uploaded files.
• Check for scheduled tasks/crons: WP cron tasks or server cronjobs that could reintroduce persistence.
• Search for suspicious PHP functions in themes/plugins (e.g., base64_decode, eval, system, exec, passthru) — but be mindful: some plugins legitimately use encoding functions, so don’t remove until confirmed.
• Remove unauthorized admin accounts and set strong password policies + 2FA for remaining admins.
• Rebuild or clean site from a verified clean backup if you cannot be certain of the integrity.
• Provide a post‑mortem: what was exploited, scope of access, remediation steps, and prevention controls.

---

Developer guidance: how plugin authors can prevent these problems

1. Validate and sanitize everything server-side — input, filenames, MIME types.
2. Use capability checks for every action that modifies state. Never rely solely on client-side checks.
3. Implement nonces and proper permission checks for AJAX and REST endpoints.
4. Avoid hidden “developer” parameters in production code. Remove or gate them behind strong authentication.
5. Don’t write uploaded files to web‑accessible directories without creating safeguards. Store uploads outside web root when possible and serve them via controlled proxies.
6. Follow the principle of least privilege: plugins should not run with admin-level operations unless necessary.
7. Use prepared statements with $wpdb->prepare for database operations; escape output properly to prevent XSS.
8. Provide clear changelogs and security update notices so sites can easily patch.

---

Hardening checklist — configuration and process improvements

• Disable file editing in wp-admin: define('DISALLOW_FILE_EDIT', true);
• Enforce strong passwords and enable two‑factor authentication for admin accounts.
• Limit plugin installations: keep the number of plugins minimal and only install from trusted authors.
• Use role separation: create specific accounts for day-to-day content editorial work rather than using admin accounts.
• Enforce HTTPS, HSTS, and secure cookie flags: Secure and HttpOnly cookies; set SameSite attributes where applicable.
• Implement Content Security Policy (CSP) for admin and public pages to reduce XSS impact.
• Automatic updates: enable auto-update for minor core updates; consider automatic updates for high-quality, actively maintained plugins — but always test updates in staging first for critical sites.
• Maintain regular backups with offsite storage and test your restore process monthly.

---

Detection and monitoring: what to watch for

• Unusual POST requests to plugin endpoints you don’t recognize.
• Sudden admin user creations or privilege escalations in the user table.
• Unexpected file changes: new PHP files in uploads/, wp-content/, or theme/plugin directories.
• Repetitive failed login attempts from the same IP range or unusual geographic source.
• Outbound network connections originating from your web server that are unexpected (possible data exfiltration).
• Alerts from your malware scanner or WAF indicating blocked exploit attempts.

Set up automated alerts for these events and integrate them with your incident response channels (Slack, email, SIEM).

---

How WP‑Firewall protects your WordPress sites (concise for operators)

WP‑Firewall combines a managed WAF, malware scanning, and virtual patching strategies that let you:

• Block known exploit patterns before a plugin patch is applied.
• Scan uploads and existing files for malware and suspicious modifications.
• Apply fine‑grained rules to stop unauthenticated file uploads, suspicious parameters, and mass password reset attempts.
• Provide layered controls: IP restrictions, rate limiting, and automated mitigation of OWASP Top 10 risks.

We design rules to be minimally disruptive to legitimate traffic while protecting the most common and dangerous attack vectors attackers exploit today.

---

New: Protect your site immediately with our Free plan — get essential protection now

Secure your WordPress site with a no‑cost plan that provides critical protections while you evaluate more advanced services or prepare patching workflows. The Free plan includes:

• Managed firewall and WAF coverage for common exploit patterns
• Malware scanning to detect suspicious files and changes
• Unlimited bandwidth so protection scales with your site
• Mitigation aimed at the OWASP Top 10 risks

Start free protection and reduce immediate exposure: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(If you need automatic malware removal, allowlisting/blacklisting of IPs, scheduled security reports, or auto virtual patching, we also offer Standard and Pro tiers.)

---

Putting it all together — recommended 30/60/90 day action plan

• First 30 days (triage & containment):
  • Inventory and patch high‑risk plugins.
  • Deploy a WAF with virtual patching rules for any unpatched exposures.
  • Run a full malware scan and clean discovered infections or restore from a verified clean backup.
• Next 60 days (stabilize & harden):
  • Formalize plugin update policies and test updates on staging.
  • Enforce secure defaults (disable file editing, enable 2FA for admins).
  • Implement monitoring and alerting for suspicious admin events and file changes.
• By 90 days (process & prevention):
  • Integrate vulnerability monitoring into your maintenance workflows.
  • Conduct an audit of installed plugins and remove or replace risky components.
  • Train teams on secure plugin development and operational hygiene.

---

Closing thoughts from the WP‑Firewall team

The pattern in the February 2026 vulnerability data is clear: attackers repeatedly exploit plugin weaknesses that touch uploads, authentication, and administrative controls. These are not theoretical risks — they are actively abused in the wild. Your defenses should reflect that reality.

The best protection is layered: good development hygiene and patching policies reduce exposure, but practical compensating controls like a managed WAF and malware scanning reduce risk immediately and at scale. Virtual patching is a lifesaver when patches are delayed or when an exploit is actively used.

If you manage multiple WordPress sites or you run an agency or hosting environment, adopt an operational approach: inventory, prioritize, contain, and automate your protections. Start with the free protections available to you, then scale to proactive services as your needs grow.

Stay safe, and treat every plugin update notice as security‑critical until proven otherwise.

---

If you found this useful, share it with your team and bookmark your update process. If you want help implementing WAF rules, audits, or automated virtual patching across multiple sites, reach out through your existing WP‑Firewall dashboard or start with our free plan: https://my.wp-firewall.com/buy/wp-firewall-free-plan/