CVE-2026–10100: Stored XSS in Simple Custom Login Page WordPress Plugin

A newly disclosed WordPress plugin vulnerability, tracked as CVE-2026–10100, affects the Simple Custom Login Page plugin in versions up to and including 1.0.3. The issue has been classified as an authenticated stored Cross-Site Scripting vulnerability and was publicly published on June 1, 2026. According to Wordfence, the vulnerability has a CVSS 3.1 score of 4.4, rated as Medium severity.

While the vulnerability requires administrator-level access to exploit, it is still interesting because it shows how even seemingly harmless customization fields, such as color settings, can become a security risk when input validation and output escaping are not handled in the correct context.

What Is CVE-2026–10100?

CVE-2026–10100 affects the Simple Custom Login Page plugin for WordPress. This plugin allows site administrators to customize the WordPress login page, including visual settings such as page background color, form background color, text color, and link color.

The vulnerability exists because the plugin did not properly sanitize color option values before storing them. These values were registered through WordPress' Settings API without a proper sanitize_callback, and were later rendered inside a <style> block on the wp-login.php page.

The problem is not only that the values were insufficiently sanitized. The deeper issue is that they were escaped using esc_attr(), which is not appropriate for a CSS context. According to the CVE description, this escaping does not neutralize characters such as semicolons, braces, slashes, or asterisks, allowing attacker-controlled CSS to be injected into the login page.

Technical Summary

The vulnerability can be summarized as follows:

CVE ID: CVE-2026–10100 Product: Simple Custom Login Page Software type: WordPress plugin Affected versions: Up to and including 1.0.3 Patched version: 1.0.4 Vulnerability type: Stored Cross-Site Scripting / CSS injection CWE: CWE-79 — Improper Neutralization of Input During Web Page Generation CVSS score: 4.4 Medium Required privileges: Administrator-level access Researcher: Nguyen Duong

At first glance, an administrator-only vulnerability may seem less dangerous than a flaw exploitable by anonymous users or low-privileged accounts. However, the security impact depends heavily on where the injected content is displayed.

In this case, the injected CSS is rendered on the WordPress login page, which is viewed by unauthenticated users. That means a malicious administrator, compromised admin account, or attacker with temporary administrative access could modify the login interface in a way that affects every user attempting to log in.

Stored XSS is often associated with JavaScript execution, session theft, or account takeover. CVE-2026–10100 is slightly different because the disclosed impact focuses on arbitrary CSS injection into the login page.

CSS injection may sound less severe than JavaScript execution, but it can still create real-world security risks. On a login page, CSS can be abused to alter the visual layout, hide legitimate elements, display misleading interface components, or make fake fields appear trustworthy.

This opens the door to UI-redress and credential-phishing scenarios. For example, an attacker could visually manipulate the login page to make users believe they are interacting with the legitimate WordPress authentication form while actually being guided toward deceptive content or misleading instructions.

Wordfence explicitly notes that the vulnerability can enable UI-redress and credential-phishing attacks against unauthenticated visitors who load the affected login page.

Root Cause: Wrong Trust Boundary and Wrong Escaping Context

The core weakness behind CVE-2026–10100 is a combination of two common mistakes:

First, the plugin trusted color settings without enforcing strict validation. Color fields should generally accept only safe formats, such as predefined values or validated hexadecimal color codes. When a field is expected to contain a color, the application should reject anything that does not match the expected format.

Second, the plugin output those values inside a CSS context while using an escaping function designed for HTML attributes. Escaping must always match the output context. A value printed inside HTML text, an HTML attribute, JavaScript, a URL, or a CSS block requires different handling.

This is a classic example of why generic escaping is not enough. A function may be safe in one context and insufficient in another.

Attack Requirements and Practical Impact

The vulnerability requires an authenticated attacker with administrator-level privileges or higher. This limits the exploitability compared to vulnerabilities reachable by subscribers, contributors, unauthenticated visitors, or compromised low-privilege users.

However, this does not make the issue irrelevant.

There are several realistic situations where this vulnerability could still matter:

An attacker may temporarily gain access to an administrator account and use the plugin settings to persist a phishing-oriented visual modification.

A malicious insider with administrative access could alter the login page to deceive other users.

A compromised WordPress environment could use the login page as a phishing surface against site operators or clients.

A multisite or managed WordPress environment may have delegated administrators whose access is broad enough to change plugin settings but not necessarily trusted to alter authentication flows.

The vulnerability therefore sits in a middle ground: it is not a mass unauthenticated takeover bug, but it affects a highly sensitive surface — the login page.

Remediation

The recommended fix is straightforward: update the Simple Custom Login Page plugin to version 1.0.4 or later. Wordfence lists version 1.0.4 as the patched release.

Site administrators should also review the current login page appearance after updating, especially if the plugin was previously used to customize colors. Any suspicious styling, unexpected layout changes, hidden fields, or unusual login instructions should be investigated.

For developers, the key lesson is to validate and escape based on context. Color values should not be treated as arbitrary strings. They should be validated using strict allowlists or format checks before being saved, and they should be safely emitted in the correct output context.

Defensive Recommendations

WordPress administrators should take the following steps:

Update Simple Custom Login Page to version 1.0.4 or newer.

Review all administrator accounts and remove unused or unnecessary privileged users.

Check the WordPress login page for unexpected visual changes.

Audit plugin settings after any suspected admin account compromise.

Use multi-factor authentication for administrator accounts.

Monitor plugin vulnerability databases for newly disclosed WordPress issues.

Developers should also ensure that Settings API fields define proper sanitization callbacks. When a setting represents a color, it should be validated as a color, not stored as arbitrary input.

Why This CVE Is a Useful Reminder

CVE-2026–10100 is not the most severe WordPress vulnerability, but it is a useful reminder of an important principle: customization features are still input surfaces.

A color picker, branding field, logo URL, button label, or layout option may look harmless, but every stored value that later reaches a browser becomes part of the application's attack surface.

Security issues often appear when developers assume that "admin-only" input does not need strict validation. In reality, admin panels are frequently targeted, accounts can be compromised, and settings can become persistence mechanisms.

The most important lesson from this vulnerability is simple: validate early, escape correctly, and always respect the output context.

References

NVD — CVE-2026–10100 Wordfence Intelligence — Simple Custom Login Page <= 1.0.3 Authenticated Stored Cross-Site Scripting CWE-79 — Improper Neutralization of Input During Web Page Generation

Contents