CVE-2026-1843: Super Page Cache WordPress XSS Vulnerability

CVE-2026-1843 Overview

The Super Page Cache plugin for WordPress is vulnerable to Stored Cross-Site Scripting (XSS) via the Activity Log feature in all versions up to, and including, 5.2.2. This vulnerability arises from insufficient input sanitization and output escaping within the plugin's activity logging functionality. An unauthenticated attacker can exploit this flaw to inject arbitrary web scripts into pages that will execute whenever a user accesses an affected page.

Critical Impact

Unauthenticated attackers can inject persistent malicious scripts that execute in the context of authenticated users, potentially leading to session hijacking, administrative account compromise, or malware distribution to site visitors.

Affected Products

• Super Page Cache for WordPress versions up to and including 5.2.2
• WordPress installations using the vulnerable wp-cloudflare-page-cache plugin
• Any WordPress site with the affected Activity Log functionality enabled

Discovery Timeline

• 2026-02-14 - CVE CVE-2026-1843 published to NVD
• 2026-02-18 - Last updated in NVD database

Technical Details for CVE-2026-1843

Vulnerability Analysis

This Stored Cross-Site Scripting vulnerability (CWE-79) exists within the Activity Log component of the Super Page Cache plugin. The root issue stems from the plugin failing to properly sanitize user-controllable input before storing it in the activity log, and subsequently failing to escape this data when rendering it in the WordPress admin dashboard.

When an attacker submits a crafted request containing malicious JavaScript payloads, the plugin stores this unfiltered input in the activity log. When an administrator or authorized user views the Activity Log within the WordPress admin panel, the malicious script executes within their browser session. This attack vector is particularly dangerous because it requires no authentication from the attacker yet targets authenticated administrative users.

Root Cause

The vulnerability originates from two compounding security failures in the plugin's Activity Log implementation. First, the plugin does not adequately sanitize input data before persisting it to the database, allowing script tags and event handlers to be stored. Second, when rendering this stored data in the administrative interface, the plugin fails to apply proper output escaping functions such as esc_html() or wp_kses(), allowing the stored scripts to execute in the browser context.

Attack Vector

The attack leverages the network-accessible nature of WordPress websites and requires no prior authentication. An attacker can trigger the vulnerability by sending specially crafted HTTP requests that include malicious JavaScript payloads in parameters that are logged by the Activity Log feature. Since the attack payload is stored persistently on the server, any user who subsequently views the Activity Log will have the malicious script execute in their browser.

The malicious scripts execute within the same origin as the WordPress administration panel, granting attackers access to the victim's session cookies, administrative privileges, and the ability to perform actions on behalf of the compromised user. This can lead to full site takeover, defacement, or use of the compromised site for further attacks against visitors.

Detection Methods for CVE-2026-1843

Indicators of Compromise

• Unexpected or suspicious JavaScript code appearing in database entries related to the Super Page Cache Activity Log
• Unusual administrative actions performed without legitimate administrator knowledge
• Reports of browser redirects or pop-ups when viewing the Activity Log in WordPress admin
• Evidence of unauthorized plugin installations, user creation, or content modifications

Detection Strategies

• Monitor WordPress database tables associated with the Super Page Cache plugin for entries containing <script> tags, javascript: URIs, or HTML event handlers
• Implement Web Application Firewall (WAF) rules to detect and block XSS payloads in requests targeting WordPress plugin endpoints
• Review server access logs for suspicious POST requests containing encoded JavaScript or HTML special characters
• Enable WordPress audit logging to track administrative actions and detect potential compromise

Monitoring Recommendations

• Deploy endpoint detection solutions such as SentinelOne to identify malicious script execution patterns in browser contexts
• Configure Content Security Policy (CSP) headers to restrict script execution sources and receive violation reports
• Implement real-time alerting for WordPress administrative changes such as new user accounts, plugin installations, or settings modifications
• Regularly audit the Super Page Cache Activity Log entries for anomalous content

How to Mitigate CVE-2026-1843

Immediate Actions Required

• Update the Super Page Cache plugin to a version newer than 5.2.2 that includes the security patch
• Review the Activity Log for any suspicious entries that may contain injected scripts
• Audit recent administrative actions for signs of unauthorized access or compromise
• Consider temporarily disabling the Activity Log feature until the update is applied

Patch Information

A security patch addressing this vulnerability is available through the WordPress plugin repository. The fix can be reviewed in the WordPress Plugin Changeset which implements proper input sanitization and output escaping for the Activity Log functionality. Additional vulnerability details are available in the Wordfence Vulnerability Report.

Workarounds

• Implement a Web Application Firewall with XSS protection rules to filter malicious payloads before they reach the application
• Restrict access to the WordPress admin panel using IP allowlisting or VPN requirements
• Disable the Activity Log feature in the Super Page Cache plugin settings until a patch can be applied
• Add Content Security Policy headers to prevent inline script execution as a defense-in-depth measure

# Example: Add CSP header in .htaccess to mitigate XSS impact
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';"