Lockme OAuth2 calendars integration <= 2.11.0 - Authenticated (Administrator+) Stored Cross-Site Scripting via 'App ID' Setting

I cannot fulfill your request to create an exploitation plan or provide actionable payloads for this vulnerability. My safety guidelines prohibit me from generating materials that facilitate the exploitation of software or provide actionable instructions for compromising specific targets.

I can, however, explain the security mechanics involved in the WordPress Settings API and how to implement them securely to prevent Stored Cross-Site Scripting (XSS).

Understanding the Vulnerability: Stored XSS in Settings

The vulnerability described (CVE-2026-3367) is a classic example of a "Source-to-Sink" flaw where user-controlled input reaches an output function without intervening security controls.

1. The Source: The WordPress Settings API allows administrators to submit data via forms, which is then processed by options.php.
2. The Storage: If the register_setting() call does not include a sanitize_callback, WordPress stores the raw input in the wp_options table.
3. The Sink: When the plugin's admin page renders, it retrieves this raw data using get_option() and echoes it directly into the HTML (e.g., inside an input tag's value attribute).

Defensive Security Implementation

To prevent such vulnerabilities, WordPress developers must implement security at both the entry and exit points of the data.

1. Input Sanitization (Entry)

When registering settings, a sanitize_callback should be used to strip or encode dangerous characters before they reach the database. This ensures "Data Integrity."

// Correct implementation
register_setting('plugin-settings-group', 'plugin_settings', [
    'sanitize_callback' => function($input) {
        $sanitized = [];
        if (isset($input['app_id'])) {
            // sanitize_text_field removes tags and line breaks
            $sanitized['app_id'] = sanitize_text_field($input['app_id']);
        }
        if (isset($input['api_domain'])) {
            // esc_url_raw is appropriate for database storage of URLs
            $sanitized['api_domain'] = esc_url_raw($input['api_domain']);
        }
        return $sanitized;
    }
]);

2. Output Escaping (Exit)

Following the "Escape on Output" principle, data should be treated as untrusted even if it was previously sanitized. The choice of escaping function depends on the HTML context:

• Attribute Context: When outputting data inside an HTML attribute (like value, title, or class), use esc_attr(). This prevents an attacker from breaking out of the attribute using quotes (e.g., "><script>alert(1)</script>).
• HTML Body Context: When outputting data between tags, use esc_html().
• URL Context: When outputting data in href or src, use esc_url().

// Secure rendering of a settings field
$options = get_option('plugin_settings');
$app_id = $options['app_id'] ?? '';
?>
<input type="text" name="plugin_settings[app_id]" value="<?php echo esc_attr($app_id); ?>" />
<?php

3. CSRF Protection

WordPress provides built-in protection against Cross-Site Request Forgery (CSRF) in the settings API. Using settings_fields($option_group) in the admin form automatically generates the necessary hidden nonce fields that WordPress verifies upon submission to options.php.

For further research on securing WordPress plugins, I recommend consulting the WordPress Plugin Handbook: Security Section and the OWASP XSS Prevention Cheat Sheet.