CVE-2026-115241 in WPvivid Plugin
Summary
by MITRE • 11/04/2026
The WPvivid — Backup, Migration & Staging WordPress plugin before 0.9.137 does not verify that a submitted snapshot identifier names a snapshot it actually created before using it as a database table-name prefix, so an authenticated administrator can supply the site's table prefix, or any other string, and cause the WPvivid — Backup, Migration & Staging WordPress plugin before 0.9.137 to drop every matching table, including the core WordPress tables, destroying the site's database.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in versions of the WPvivid Backup, Migration & Staging plugin prior to version 0.9.137 represents a critical failure in input validation and trust boundary enforcement within an administrative context. The flaw stems from the application's handling of snapshot identifiers during database restoration or migration operations. Specifically, when a user initiates a process that involves restoring data from a previously created backup, the plugin accepts a snapshot identifier provided by the administrator without verifying whether this identifier corresponds to a legitimate snapshot file generated and managed by the WPvivid system itself. This lack of verification allows an attacker with administrative privileges to manipulate the underlying database structure through arbitrary string injection in the context of table name construction.
From a technical perspective, the core issue lies in how the plugin constructs SQL queries or interacts directly with the database abstraction layer using user-supplied input as part of the table prefix. In WordPress environments, all tables are typically prefixed with a unique identifier to prevent collisions between multiple installations on shared databases and to add a minor layer of obscurity against certain automated attacks. The WPvivid plugin uses this snapshot-related string to determine which tables should be targeted for dropping or modification during restoration processes. Because the software fails to validate that the provided prefix matches an existing, authorized backup record, it proceeds to execute destructive commands based on arbitrary input supplied by the administrator account.
The operational impact of this vulnerability is severe and potentially catastrophic for any WordPress site running the affected plugin version. An authenticated attacker, such as a compromised administrator account or a malicious insider with elevated privileges, can exploit this flaw to drop every table in the database that matches an arbitrary prefix string. By supplying common prefixes like wp_ or other standard configurations, the attacker can systematically delete core WordPress tables including those storing users, posts, options, and settings. This results in complete data loss for the website's content and configuration, effectively rendering the site non-functional until a full restoration from external backups is performed. The destruction of user tables may also lead to lockouts if administrative credentials are removed or corrupted during the process.
This vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to sanitize or verify that input conforms to expected constraints before processing it in security-critical operations. Furthermore, because exploitation requires authentication at the administrator level, this flaw is often categorized under privilege escalation scenarios where a lower-level compromise leads to total system destruction rather than just data exfiltration. In terms of MITRE ATT&CK frameworks, this behavior resembles techniques associated with Impact categories, specifically Data Destruction or Denial of Service via resource exhaustion and deletion. The attack vector leverages the trust placed in administrative actions without implementing sufficient safeguards against malicious intent within that role.
Mitigation strategies must focus on immediate remediation through software updates and enhanced defensive coding practices for future development. Site administrators should upgrade to WPvivid version 0.9.137 or later, where this validation logic has been corrected to ensure that only valid, system-generated snapshot identifiers are accepted for database operations. For environments unable to update immediately due to compatibility constraints, implementing strict role-based access control is essential to limit the number of users with administrative privileges and monitoring login activity for anomalies. Additionally, maintaining regular, off-site backups independent of the plugin's internal backup mechanism provides a critical recovery path in case such an incident occurs. Developers should enforce principle of least privilege by ensuring that destructive database operations require additional confirmation steps or are restricted to specific, verified contexts rather than accepting arbitrary strings as table prefixes.