UpdraftPlus EUVD-2026-66877

Exploitation requires all of the following: the target WordPress site must have UpdraftPlus installed at a version prior to 1.26.7; at least one valid backup must exist on the site that can be triggered for restoration; and a logged-in WordPress administrator must click or load a crafted URL or page controlled by the attacker (UI:R). The attacker requires no credentials on the target site (PR:N per CVSS vector). Exploitation is materially limited by: the necessity of targeting a specific authenticated admin session through social engineering, the high attack complexity (AC:H) reflecting that the CSRF payload must be successfully delivered while the admin session is active, and the requirement for a stored backup to exist. Exploitation cannot be automated at scale (SSVC Automatable: no).

The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L, score 5.9) captures the key constraints: high attack complexity because the attacker must successfully lure an authenticated administrator into triggering the CSRF payload, and required user interaction that limits automated mass exploitation. EPSS at 0.10% (1st percentile) reinforces that community exploitation probability is very low. SSVC Exploitation: none and Automatable: no are consistent - there is no evidence of in-the-wild abuse and the social engineering prerequisite prevents spray-and-pray automation. Despite the I:H rating (full integrity of site data can be overwritten), the real-world risk is moderate rather than critical: exploitation requires per-target effort, prior knowledge of the site's plugin installation, and the existence of a restorable backup. No confidentiality impact is recorded. This vulnerability warrants timely patching but is not an emergency-response priority absent evidence of active targeting.

An attacker identifies a WordPress site running UpdraftPlus prior to 1.26.7 and confirms the existence of at least one stored backup. The attacker crafts a malicious HTML page or phishing email containing a forged HTTP request to the restore action and delivers it to the site administrator. When the administrator loads the page while logged into the WordPress dashboard, the browser automatically sends the forged request with valid session cookies, causing the site to silently restore the selected backup - reverting the database and files, potentially undoing recent security patches, user accounts, and content.