Admin Custom Login CVE-2026-2487

Exploitation requires an authenticated WordPress account holding administrator-level privileges or higher - unauthenticated attackers cannot trigger this vulnerability. Beyond authentication, one of two specific non-default deployment conditions must hold: either (1) the WordPress installation is operating as a multi-site network (where the unfiltered_html capability is withheld from sub-site administrators by default), or (2) the unfiltered_html capability has been explicitly removed from administrator roles on a single-site installation as a deliberate hardening measure. On a standard single-site WordPress installation where administrators retain unfiltered_html (the WordPress default), the vulnerable code paths do not permit script injection and the vulnerability is not exploitable. These constraints substantially limit the real-world attack surface to multi-tenant hosting environments and hardened enterprise WordPress deployments.

The CVSS 3.1 score of 4.4 Medium with vector AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N is broadly defensible. AC:H captures the deployment conditionality (multi-site or hardened unfiltered_html), and PR:H reflects the administrator-level authentication barrier - both are meaningful real-world constraints. The Scope:Changed metric is appropriate because the payload executes in a victim browser context distinct from the web server. No EPSS score was provided, so probabilistic exploitation likelihood cannot be quantified; however, the combination of PR:H and AC:H strongly suppresses real-world exploitability. No KEV listing and no identified POC further reduce urgency. The primary residual risk is in multi-tenant WordPress hosting environments where multiple semi-trusted administrators share a network - a hostile or compromised admin could use this to attack end users or other admins accessing the login page. On typical single-site WordPress installations with default capabilities, this vulnerability is entirely non-exploitable. The omission of UI:R in the provided vector is debatable: stored XSS does require victim page visitation, and an independent assessment would rate UI:R, yielding a lower base score.

An authenticated WordPress administrator on a multi-site network navigates to the Admin Custom Login settings panel and submits a JavaScript payload embedded in a login-page customization field - such as a background image URL or custom CSS input - that is stored to the database without sanitization. Every subsequent visitor to the WordPress login page, including unauthenticated users, loads the injected script in their browser, enabling the attacker to harvest credentials entered into the login form, steal session cookies, or redirect users to a phishing page. No public exploit code has been identified, but the attack pattern is straightforward for any administrator with plugin settings access.