AddFunc Head & Footer Code XSS (CVE-2026-2305): What WordPress Site Owners Need to Know

Date: 10 April 2026 — Severity: Low (CVSS 6.5) — Affected versions: ≤ 2.3 — Patched in: 2.4 — Required privilege: Contributor (authenticated)

Summary: An authenticated stored cross-site scripting (XSS) issue in AddFunc Head & Footer Code (versions up to 2.3) allows a contributor-level user to save script-like payloads via custom fields that may later be rendered unsanitized. This note provides a pragmatic, practitioner-focused breakdown of the risk, detection, cleanup and mitigation steps from the perspective of a Hong Kong-based security expert.

Executive summary — what happened and why it matters

• The plugin allowed user-supplied content from post custom fields to be included in output without sufficient sanitization or escaping.
• An authenticated user with Contributor privileges (able to create or edit posts and add custom fields) could save content containing script tags or event handlers.
• If that content is later rendered on the front-end or inside admin screens without proper escaping, the stored script executes in the viewer’s browser.
• Impact depends on render context:
  • Front-end execution can affect visitors (malicious redirects, form spoofing, crypto‑miner injection, content manipulation).
  • Execution in admin pages can target higher-privilege users and lead to account takeover, changes to settings, plugin/theme modifications, or backdoors.
• The plugin was patched in version 2.4. Updating to 2.4+ is the correct and primary remediation.

Why a Contributor can be dangerous — real-world threat model

Site owners often assume Contributors are low risk because they cannot publish. That’s true for publishing workflows, but Contributors can typically create posts, edit drafts and add custom fields (site configuration permitting). Stored XSS in custom fields is dangerous because the payload is persistent and will execute whenever rendered without escaping.

Key points:

• Persistency: malicious content is stored in the database and can be triggered later.
• Privilege amplification: if admin users view the infected content in the dashboard, an attacker can pivot using the admin’s authenticated session.
• Real attack vectors include CSRF combined with XSS to perform privileged actions (create admin accounts, change options, install code).

Typical exploitation flow (high level, non-actionable)

1. Attacker registers or compromises a Contributor account.
2. Attacker saves a post or draft and injects malicious content into a custom field (e.g., or attribute payloads such as onerror=…).
3. Content is stored in postmeta.
4. When the post is rendered in a context that outputs the field unsanitized (front-end, admin preview, meta box), the browser executes the JavaScript.
5. If an administrator views the affected admin screen, the script may perform privileged actions using the admin’s session (exfiltrate cookies, create admin users, modify files, install backdoors).

Some advisories list “User Interaction Required” — in practice the interaction can be as simple as opening the post editor or a crafted preview link.

Practical steps to protect your site — immediate actions (checklist)

1. Update the plugin — If you use AddFunc Head & Footer Code, update to 2.4 or later immediately. This is the canonical fix.
2. If you cannot update immediately
   • Temporarily remove or disable the plugin.
   • Restrict Contributors from adding or editing custom fields until patched.
   • Apply virtual patching at the WAF level if you have that capability (see WAF guidance below).
3. Scan for malicious content in custom fields

   Use WP-CLI or direct DB queries (with a backup) to find meta values containing

4. Audit user accounts — Verify Contributors and Editors; remove stale or suspicious accounts. Enforce strong passwords and 2FA for privileged roles.
5. Check for signs of compromise — unknown admin accounts, unexpected plugin/theme files, modified files, scheduled tasks, or outbound connections.
6. Rotate credentials if compromise is suspected — reset admin passwords, revoke API keys, and invalidate sessions.
7. Backup before cleanup — take a full files+DB backup before making remediation changes to preserve evidence and allow rollback.
8. Harden custom fields — require sanitization on save and escaping on output (see developer guidance below).

How to find malicious stored XSS entries safely

Always work from a full backup and start with read-only queries to identify suspicious entries, then review them manually.

# Find postmeta that contains 
			
				
			
					

							
			
			
			





		

		
					
				 
 
   
 
  
 
 Review My Order
 0 
 
 
  
 
 
  
 
 
 
 Subtotal
 
Taxes & shipping calculated at checkout
 
 
  
 
 
 
   Checkout