Backuply EUVD-2026-102613

Requires: (1) an authenticated account with subscriber-level access or above whose profile Biographical Info field accepts the crafted payload; (2) WordPress profiles storing a biographical description (default behavior); and critically (3) an Administrator subsequently creating a backup that captures the attacker's wp_usermeta value AND then performing a restore of that backup via Backuply - the injection only fires inside the INSERT during the restore operation. Limiting factors: exploitation is second-order and cannot be self-triggered by the attacker (UI:R - depends on an admin restore action that may never occur or may occur long after payload planting); it requires valid authentication (PR:L, no anonymous path); and it is a blind write primitive with no response returned, so it is used to modify records (e.g., default_role in wp_options) rather than directly exfiltrate data.

This is a genuine high-priority issue tempered by meaningful preconditions. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H, base 8.0) indicates network-reachable exploitation by a low-privileged (PR:L) authenticated user, but with required user interaction (UI:R) - here the interaction is an Administrator performing a backup restore, which is a significant real-world dependency, not a trivial click. The impact triple (C:H/I:H/A:H) reflects the end state of full site takeover via privilege escalation, even though the injection primitive itself only writes/modifies DB records. No EPSS score, SSVC decision, KEV listing, or POC indicator was provided in the input, so exploitation probability cannot be quantified from the data; per precision rules this is 'no public exploit identified at time of analysis.' The key tension is that successful attack is gated on an Administrator restoring an attacker-poisoned backup - a second-order chain that limits opportunistic mass exploitation and makes this more plausible in targeted scenarios (e.g., shared-hosting, agencies managing many sites, or supply-chain backup handling) than in broad automated campaigns. Net: real and serious where the restore workflow is used, but the UI:R/second-order dependency keeps it below the urgency of a directly remote-unauthenticated SQLi.

A subscriber-level user sets a crafted SQL payload in their WordPress profile's Biographical Info field. Later, an Administrator creates a backup (which exports that value verbatim into an INSERT into wp_usermeta) and then restores it; during restore the payload breaks out of the INSERT and runs attacker-controlled SQL with full DB privileges, flipping the default_role option to administrator and enabling open registration. No public POC is identified in the provided data; the low attack complexity means payload crafting is straightforward, but exploitation hinges on the admin-triggered restore.