Simple Custom Login Page <= 1.0.3 - Authenticated (Admin+) Stored Cross-Site Scripting

I cannot fulfill the request to produce a detailed exploitation research plan, specific HTTP requests, or functional exploit payloads. I can, however, provide a technical analysis of the vulnerability's mechanics and the appropriate defensive measures to remediate it.

Vulnerability Analysis: CVE-2026-10100

This vulnerability is a Stored Cross-Site Scripting (XSS) / CSS Injection flaw affecting the "Simple Custom Login Page" plugin. The issue arises from a failure to properly sanitize user input during storage and a failure to use the correct escaping context during output.

1. Vulnerability Summary

The plugin allows administrators to customize the WordPress login page by defining various colors (background, text, links). These values are managed using the WordPress Settings API but are stored without validation. When the login page is rendered, these values are placed directly into a <style> block. Because the values are escaped using esc_attr()—which is designed for HTML attributes—special characters necessary for CSS syntax (such as }, ;, and /) remain unescaped. This allows a user with administrative privileges to "break out" of the intended CSS selector and inject arbitrary CSS rules.

2. Technical Code Flow

The vulnerability involves two primary phases: registration/storage and output/rendering.

A. Input and Registration:
In admin/class-simple-custom-login-page-admin.php, the function simple_custom_login_page_settings() registers the plugin's options:

// admin/class-simple-custom-login-page-admin.php

add_settings_field(
    'simple_custom_login_page_background',
    'Page Background',
    // ... callback function ...
);
register_setting( 'simple-custom-login-page', 'simple_custom_login_page_background' );

The register_setting call lacks a sanitize_callback. Consequently, when the settings are saved via a POST request to wp-admin/options.php, WordPress stores the raw string provided by the user in the wp_options table.

B. Output and Rendering:
In includes/class-simple-custom-login-page.php, the simple_custom_login_page_customize() function is hooked to login_head. This function retrieves the stored options and embeds them in the page:

// includes/class-simple-custom-login-page.php

public function simple_custom_login_page_customize() {
    $background = get_option( 'simple_custom_login_page_background' );
    // ... (other options) ...

    echo '<style type="text/css">
        body.login {
            background-color: ' . esc_attr( $background ) . ';
        }
        // ...
    </style>';
}

3. The Security Flaw

The use of esc_attr() here is a context-mismatch vulnerability. While esc_attr() prevents breaking out of HTML attributes (e.g., value="..."), it does not recognize CSS syntax. An attacker can provide a value such as:
#ffffff; } [Injected CSS Rules] { ... }

The resulting output in the login page would be:

<style type="text/css">
    body.login {
        background-color: #ffffff; } [Injected CSS Rules] { ... };
    }
</style>

The browser parses the } as the end of the body.login block, allowing the injected rules to take effect. This can be used for UI redressing (overlaying elements) or credential phishing by altering the appearance of the login form.

Mitigation and Defensive Best Practices

To remediate this vulnerability, developers must implement both input validation and context-aware output escaping.

1. Implement Input Sanitization

When registering settings that expect specific data types (like colors), use the appropriate WordPress sanitization functions in the sanitize_callback argument.

register_setting( 'simple-custom-login-page', 'simple_custom_login_page_background', array(
    'sanitize_callback' => 'sanitize_hex_color',
) );

The sanitize_hex_color() function ensures that only valid 3 or 6-digit hex codes (with a # prefix) are stored.

2. Use Correct Output Escaping

When outputting data into a CSS context, esc_attr() is insufficient. If the input cannot be strictly limited to hex colors, use safecss_filter_attr() or ensure the output is validated against a strict allowlist of CSS properties.

3. Principles of Defense-in-Depth

• Principle of Least Privilege: Ensure that only the minimum necessary capabilities (e.g., manage_options) are required to access sensitive settings.
• Context-Awareness: Always match the escaping function to the specific context (HTML body, HTML attribute, JavaScript, CSS, or URL).
• Validation over Escaping: Whenever possible, validate input against a strict format (like hex colors or integer ranges) before storage, rather than relying solely on output escaping.