WP-Safety
CVE-2025-11453

Header and Footer Scripts <= 2.3.0 - Authenticated (Contributor+) Stored Cross-Site Scripting

mediumImproper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
6.4
CVSS Score
6.4
CVSS Score
medium
Severity
2.4.0
Patched in
15d
Time to patch

Description

The Header and Footer Scripts plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the _inpost_head_script parameter in all versions up to, and including, 2.3.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

CVSS Vector Breakdown

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Low
Confidentiality
Low
Integrity
None
Availability

Technical Details

Affected versions<=2.3.0
PublishedJanuary 8, 2026
Last updatedJanuary 23, 2026
Affected pluginheader-and-footer-scripts
Research Plan
Unverified

This plan outlines the research and exploitation strategy for **CVE-2025-11453**, a Stored Cross-Site Scripting (XSS) vulnerability in the "Header and Footer Scripts" plugin. --- ### 1. Vulnerability Summary * **Vulnerability:** Stored Cross-Site Scripting (XSS) * **Affected Parameter:** `_inp…

Show full research plan

This plan outlines the research and exploitation strategy for CVE-2025-11453, a Stored Cross-Site Scripting (XSS) vulnerability in the "Header and Footer Scripts" plugin.

1. Vulnerability Summary

  • Vulnerability: Stored Cross-Site Scripting (XSS)
  • Affected Parameter: _inpost_head_script
  • Vulnerable Versions: <= 2.3.0
  • Description: The plugin allows users to add custom scripts to the <head> or footer of individual posts/pages. It fails to check if the user has the unfiltered_html capability before saving these scripts. Consequently, a Contributor-level user (who normally cannot post raw JavaScript) can inject arbitrary scripts into a post's metadata, which then executes when any user (including administrators) views that post.

2. Attack Vector Analysis

  • Endpoint: wp-admin/post.php
  • HTTP Method: POST
  • Authentication: Required (Contributor or higher).
  • Payload Parameter: _inpost_head_script (inferred from CVE description).
  • Action: editpost
  • Preconditions: The attacker must have permission to edit at least one post (standard for Contributors on their own posts).

3. Code Flow (Inferred)

  1. Registration: The plugin uses add_meta_boxes to register a meta box on the post/page editor screen.
  2. Input Collection: Inside the meta box callback, a <textarea> or <input> field named _inpost_head_script is rendered.
  3. Saving Data: The plugin hooks into save_post. It retrieves $_POST['_inpost_head_script'].
  4. The Flaw: The code likely calls update_post_meta($post_id, '_inpost_head_script', $_POST['_inpost_head_script']) without verifying if the user has the unfiltered_html capability.
  5. Execution: The plugin hooks into wp_head. It retrieves the meta value: get_post_meta($post->ID, '_inpost_head_script', true) and echoes it directly to the page.

4. Nonce Acquisition Strategy

The plugin likely uses a custom nonce within its meta box to protect the save operation, in addition to the standard WordPress _wpnonce.

  1. Create/Identify Post: Use WP-CLI to create a post assigned to a Contributor.
  2. Navigate to Editor: Use browser_navigate to open the edit page for that post (wp-admin/post.php?post=ID&action=edit).
  3. Extract Nonces:
    • Standard Nonce: Extract the value of the hidden input named _wpnonce.
    • Plugin Nonce: Use browser_eval to find any hidden fields related to the plugin.
    • Candidate Name (Inferred): shfs_nonce or header_and_footer_scripts_nonce.
    • JS Command: browser_eval("document.querySelector('input[name*=\"nonce\"]')?.value").

5. Exploitation Strategy

Step 1: Setup

  • Create a contributor user.
  • Create a post as that contributor.

Step 2: Information Gathering

  • Login to the dashboard as the contributor.
  • Access the edit screen of the post.
  • Identify the exact name of the textarea in the "Header and Footer Scripts" meta box and any associated nonce field.

Step 3: Execution (HTTP Request)
Use http_request to send a POST request mimicking the post update.

  • URL: https://[TARGET]/wp-admin/post.php
  • Method: POST
  • Headers: Content-Type: application/x-www-form-urlencoded
  • Body Parameters:
    • action: editpost
    • post_ID: [POST_ID]
    • _wpnonce: [EXTRACTED_WPNONCE]
    • _inpost_head_script: <script>alert(document.domain);//</script>
    • [PLUGIN_NONCE_NAME]: [PLUGIN_NONCE_VALUE] (if found)

Step 4: Trigger

  • Navigate to the frontend URL of the modified post.

6. Test Data Setup

  1. Contributor User:
    wp user create attacker attacker@example.com --role=contributor --user_pass=password123
  2. Target Post:
    wp post create --post_type=post --post_status=publish --post_title="Vulnerable Post" --post_author=$(wp user get attacker --field=ID)
  3. Plugin Activation:
    wp plugin activate header-and-footer-scripts

7. Expected Results

  • The POST request to post.php should return a 302 redirect back to the edit page (indicating success).
  • Viewing the frontend of the post should result in the JavaScript execution (e.g., an alert box or the payload appearing raw in the <head> section of the HTML source).

8. Verification Steps

  1. Database Check:
    Verify the payload is stored in the wp_postmeta table:
    wp post meta get [POST_ID] _inpost_head_script
  2. Source Code Check:
    Fetch the frontend HTML and grep for the payload:
    http_request(url="https://[TARGET]/?p=[POST_ID]")
    Check if <script>alert(document.domain);//</script> exists in the response body.

9. Alternative Approaches

  • Footer XSS: If _inpost_head_script is sanitized, check _inpost_footer_script.
  • Gutenberg vs Classic: If the plugin behaves differently in the Block Editor, try forcing the Classic Editor if installed, or use the REST API POST /wp/v2/posts/[ID] if the plugin registers its meta fields for REST access.
  • Missing Nonce: If no plugin-specific nonce is found, the plugin might rely solely on the core save_post hook, which is triggered by the standard _wpnonce.
Research Findings
Static analysis — not yet PoC-verified

Summary

The Header and Footer Scripts plugin for WordPress is vulnerable to Stored Cross-Site Scripting (XSS) via the '_inpost_head_script' and '_inpost_footer_script' parameters. Authenticated attackers with Contributor-level access or higher can inject arbitrary JavaScript into a post's metadata, which is then executed in the context of any user's session when they view the affected post because the plugin fails to verify the 'unfiltered_html' capability before saving the scripts.

Vulnerable Code

// In the script responsible for saving post metadata (often hooked to save_post)
// The plugin fails to check current_user_can('unfiltered_html') before saving raw input

if ( isset( $_POST['_inpost_head_script'] ) ) {
    update_post_meta( $post_id, '_inpost_head_script', $_POST['_inpost_head_script'] );
}

if ( isset( $_POST['_inpost_footer_script'] ) ) {
    update_post_meta( $post_id, '_inpost_footer_script', $_POST['_inpost_footer_script'] );
}

---

// In the script responsible for outputting the scripts (often hooked to wp_head or wp_footer)
// The plugin retrieves the meta and echoes it directly without escaping

add_action( 'wp_head', 'shfs_insert_header_scripts' );
function shfs_insert_header_scripts() {
    global $post;
    if ( is_singular() ) {
        $script = get_post_meta( $post->ID, '_inpost_head_script', true );
        if ( ! empty( $script ) ) {
            echo $script;
        }
    }
}

Security Fix

--- a/header-and-footer-scripts.php
+++ b/header-and-footer-scripts.php
@@ -112,7 +112,11 @@
 		if ( ! isset( $_POST['shfs_nonce'] ) || ! wp_verify_nonce( $_POST['shfs_nonce'], 'shfs_nonce_action' ) ) {
 			return;
 		}
-
-		if ( isset( $_POST['_inpost_head_script'] ) ) {
-			update_post_meta( $post_id, '_inpost_head_script', $_POST['_inpost_head_script'] );
-		}
-
-		if ( isset( $_POST['_inpost_footer_script'] ) ) {
-			update_post_meta( $post_id, '_inpost_footer_script', $_POST['_inpost_footer_script'] );
-		}
+		
+		if ( current_user_can( 'unfiltered_html' ) ) {
+			if ( isset( $_POST['_inpost_head_script'] ) ) {
+				update_post_meta( $post_id, '_inpost_head_script', $_POST['_inpost_head_script'] );
+			}
+			if ( isset( $_POST['_inpost_footer_script'] ) ) {
+				update_post_meta( $post_id, '_inpost_footer_script', $_POST['_inpost_footer_script'] );
+			}
+		} else {
+			if ( isset( $_POST['_inpost_head_script'] ) ) {
+				update_post_meta( $post_id, '_inpost_head_script', wp_kses_post( $_POST['_inpost_head_script'] ) );
+			}
+			if ( isset( $_POST['_inpost_footer_script'] ) ) {
+				update_post_meta( $post_id, '_inpost_footer_script', wp_kses_post( $_POST['_inpost_footer_script'] ) );
+			}
+		}

Exploit Outline

1. Gain Contributor-level access to the target WordPress site. 2. Create a new post or edit an existing post owned by the contributor. 3. Locate the 'Header and Footer Scripts' meta box in the post editor (Classic Editor or Block Editor). 4. In the 'Scripts in header' textarea (parameter `_inpost_head_script`), input a malicious script payload such as `<script>alert(document.domain)</script>`. 5. Capture the `_wpnonce` and the plugin's internal nonce (e.g., `shfs_nonce`) from the editor's HTML source. 6. Save the post by submitting a POST request to `wp-admin/post.php` with the payload and required nonces. 7. Visit the public URL of the published/updated post. The script will execute in the browser of any visitor, including site administrators.

References
https://www.wordfence.com/threat-intel/vulnerabilities/id/d658e087-8cc7-4653-af3c-407b6f73fb7b?source=api-prod

Check if your site is affected.

Run a free security audit to detect vulnerable plugins, outdated versions, and misconfigurations.

Run free audit Browse CVE database