Plugin Name	Allow HTML in Category Descriptions
Type of Vulnerability	Cross-Site Scripting (XSS)
CVE Number	CVE-2026-0693
Urgency	Low
CVE Publish Date	2026-02-13
Source URL	CVE-2026-0693

Urgent: Stored XSS in “Allow HTML in Category Descriptions” (<= 1.2.4) — What WordPress Site Owners Must Do Now

Summary: A stored Cross-Site Scripting (XSS) vulnerability (CVE-2026-0693) has been disclosed in the WordPress plugin “Allow HTML in Category Descriptions” (versions <= 1.2.4). An authenticated user with Administrator-level privileges can inject malicious HTML/JavaScript into category descriptions that can later execute in visitors’ or other administrators’ browsers. There is currently no official patch for the vulnerable versions. This post explains the technical details, threat scenarios, immediate mitigations, detection and clean-up steps, and longer-term hardening — from the perspective of WP‑Firewall, a dedicated WordPress security provider.

Note: If you run this plugin and have an affected version installed, treat this as a high-priority site security task — even though the vulnerability requires administrator privileges, the impact can be significant in practice.

---

What is the vulnerability?

• Type: Stored Cross-Site Scripting (XSS).
• Affected component: WordPress plugin “Allow HTML in Category Descriptions” — versions <= 1.2.4.
• CVE: CVE-2026-0693.
• CVSS: 5.9 (medium), Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:L.
• Root cause: The plugin allows administrators to save unfiltered HTML in taxonomy descriptions without proper sanitization or output encoding. Malicious JavaScript stored in a category description can be executed in the context of a page that renders that description (front-end or certain admin views), enabling cookie theft, privilege abuse, or actions performed with the victim’s browser session.

Why this matters: Administrators are trusted accounts, and an attacker that can induce a privileged user to perform an action (or can itself act as a compromised admin) can persist malicious scripts that victimize other admin users or site visitors. Even if an admin-only action is required to trigger the vulnerability, the consequences range from site defacement and redirect campaigns to full site takeover.

---

How an attacker can exploit this

Typical exploit flow:

1. Attacker obtains or compromises an Administrator account (phishing, reused password, insider, etc.), or tricks an admin to perform an action that results in the payload being stored (see user interaction note below).
2. Using the plugin interface (category edit screen) or another entry point that updates taxonomy descriptions, the attacker injects a payload into the category description field — e.g., <script>…</script> or an SVG with an onload/onerror handler, or an attribute-based payload such as onmouseover, srcset, or javascript: URIs.
3. The payload is stored in the database (term_taxonomy.description).
4. When an admin or visitor views the category page (or any admin page rendering that description), the script runs in their browser within the site’s origin.
5. The malicious script can:
   • Collect cookies/localStorage and send them to a remote server.
   • Use the victim’s authenticated browser session to call WordPress REST endpoints or AJAX endpoints (potentially creating users, installing plugins, or modifying options) if the targeted requests lack nonce checks or proper capability checks.
   • Inject further malicious content (ads, redirects, credential harvesting forms).
   • Modify admin pages or inject backdoors that persist beyond removal of initial script.

Important nuance: Many modern WordPress installations set auth cookies as HttpOnly, preventing direct cookie access by JS. However, JavaScript can still perform authenticated requests (fetch/XHR) if same-origin and nonce protections are absent or can be stolen via other vectors. Attackers can chain XSS with other weak controls to achieve privilege escalation or full compromise.

User interaction: The exploit is categorized as requiring user interaction in some writeups — typically a privileged user may need to visit a specific page or click a crafted link that triggers execution. Regardless, stored XSS is persistent and can be triggered automatically when pages are loaded (no extra clicks required by a visitor).

---

Immediate, prioritized actions (within the next hour)

1. Disable the plugin now
   • Access your site (wp-admin → Plugins) and deactivate the “Allow HTML in Category Descriptions” plugin immediately.
   • If you cannot access the admin panel, disable via FTP or hosting file manager by renaming the plugin folder: wp-content/plugins/allow-html-in-category-descriptions → append -disabled.
2. Put the site in maintenance mode (if appropriate)
   • If you suspect active exploitation (visible redirects, defacement, spam content), consider temporarily blocking public access while you investigate.
3. Audit and rotate administrative credentials
   • Force a password reset for all Administrator accounts.
   • If you have suspicious admin activity, revoke sessions and tokens (Users → All Users → for each admin, “Log out everywhere” or use a plugin to expire sessions).
   • Enforce strong passwords and enable Two-Factor Authentication (2FA) for admin accounts.
4. Block new requests that attempt to save XSS payloads
   • If you run a Web Application Firewall (WAF) or can quickly deploy request filtering at the host or CDN (or via WP‑Firewall rules), block POST requests that attempt to save category descriptions containing script-like patterns. See suggested WAF rules later in this post.
5. Backup your site (files + DB)
   • Create a full backup before modifying or cleaning the site. Preferably, export the database and download a snapshot of wp-content and any uploads or custom files.
6. Scan for indicators of compromise right away
   • Look for unexpected users, files, scheduled tasks (wp_cron jobs), option values changed recently, and injected content across posts, pages, and taxonomy descriptions.

---

Investigation: find malicious category descriptions and scope the damage

Category descriptions are stored in the database; to find suspicious content quickly, run searches for script-like content.

Use WP‑CLI (recommended if you have shell access):

• Search term descriptions containing “<script”:

  wp db query "SELECT term_taxonomy_id, term_id, description FROM wp_term_taxonomy WHERE description LIKE '%<script%';"

• Search for common XSS vectors (onerror, onload, javascript:, data:, svg, iframe, <img>):

  wp db query "SELECT term_taxonomy_id, term_id, description FROM wp_term_taxonomy WHERE description REGEXP '(script|onerror|onload|javascript:|data:|iframe|svg|img)';"

If you don’t have WP‑CLI, run the equivalent SQL in phpMyAdmin or your hosting database tool.

Also check:

• Posts and pages: search post_content for similar patterns (SELECT ID, post_title FROM wp_posts WHERE post_content REGEXP '(<script|onerror|onload|javascript:)').
• Widgets and theme options: wp_options table content might also contain injected HTML.
• Plugin/theme files for unfamiliar code.

If you find suspicious descriptions, export them to a safe place (forensics) before making mass modifications.

---

Cleaning infected descriptions safely

Option A — Manual removal (recommended if few entries):

• Use wp-admin → Posts/Terms editor and manually edit descriptions to remove the payload.
• For categories: WP Admin → Posts → Categories → edit each suspect category description.

Option B — Database cleanup (for large or automated cleanup):

• Replace dangerous tags using SQL (test on backup first):

  -- Remove <script>...</script> blocks from term descriptions
  UPDATE wp_term_taxonomy
  SET description = REGEXP_REPLACE(description, '<script[^>]*>.*?</script>', '', 'si')
  WHERE description REGEXP '<script[^>]*>';
    

• Strip event handler attributes like onload/onerror (this can be complex — consider a PHP-based sanitizer instead to avoid breaking markup).

Option C — Sanitize through a PHP script using WordPress functions (safer):

Create a one-off PHP script and run it via WP-CLI eval-file or admin hook:

<?php
// sanitize-term-descriptions.php
require_once 'wp-load.php';

$terms = get_terms( array(
  'taxonomy' => 'category',
  'hide_empty' => false,
) );

$allowed_tags = array(
  'a' => array('href' => true, 'title' => true, 'rel' => true, 'target' => true),
  'b' => array(),
  'strong' => array(),
  'i' => array(),
  'em' => array(),
  'p' => array(),
  'br' => array(),
  'ul' => array(),
  'ol' => array(),
  'li' => array(),
  'span' => array('class' => true),
  // add only tags/attributes you trust
);

foreach ( $terms as $term ) {
    $clean = wp_kses( $term->description, $allowed_tags );
    if ( $clean !== $term->description ) {
        wp_update_term( $term->term_id, 'category', array('description' => $clean) );
        echo "Cleaned term {$term->term_id}
";
    }
}
?>

Run via:

wp eval-file sanitize-term-descriptions.php

Notes:

• Using wp_kses with a strictly limited allowed tags set is safer than attempting to regex-strip attributes manually.
• Test changes on a staging site or backup first.

---

Suggested defensive WAF rules and short-term virtual patching

If you use a WAF (managed host, CDN, or WP‑Firewall), add rules to block attempts to store suspicious payloads or to block rendering of known-suspicious content.

Simple detection heuristics:

• Block POST requests to wp-admin/term.php or REST endpoints used to save term descriptions that contain <script, onerror=, onload=, javascript:, data:text/html, svg/onload, iframe, or suspicious src attributes with data:/javascript:.
• Block requests that include <svg with event handlers, or style="background:url(javascript: style injections.

Example ModSecurity-style rule (pseudocode — tune for your environment):

# Block attempts to save category descriptions containing <script> or event handlers
SecRule REQUEST_METHOD "POST" "chain,phase:2,deny,log,msg:'Block term description XSS attempt'"
    SecRule REQUEST_URI "@contains /wp-admin/term.php" "chain"
    SecRule ARGS_POST:description "@rx (<script|onerror|onload|javascript:|data:|iframe|svg|img\s+[^>]*on)" "t:none,t:lowercase"

For REST endpoints (if the plugin exposes REST or uses admin-ajax):

# Block suspicious payloads in REST requests
SecRule REQUEST_BODY "@rx (<script|onerror|onload|javascript:|data:|iframe|svg)" "deny,log,msg:'Block REST XSS payload'"

WP‑Firewall-specific approach:

• Add a rule that inspects requests to taxonomy update endpoints for the description parameter and blocks if it matches XSS patterns (configurable).
• Enable request body inspection and add custom rule to sanitize or block saving of disallowed tags/attributes.

Important: WAF rules are a stop-gap. They reduce risk while you remove the plugin or patch the site, but they do not replace removing vulnerable code.

---

Detection: what to look for after cleanup

• Unexpected admin users or new accounts with elevated roles.
• Scheduled tasks that run unknown code (check wp_options cron entries and wp_cron).
• Unexpected plugins or themes installed/changed (compare file checksums with repository versions).
• Suspicious outgoing connections and DNS lookups from your server.
• Requests in logs that reflect the payload pattern or include suspicious redirection or exfiltration endpoints.
• Unusual admin activity timestamps, IPs, or failed login attempts.

Useful WP‑CLI commands:

• List users and roles:

  wp user list --role=administrator

• Show recent cron events:

  wp cron event list --due-now

• Check changed plugin/theme files (if you have a clean reference):

  wp plugin verify-checksums plugin-slug

---

Incident response & recovery checklist

1. Quarantine the site (maintenance mode or temporary block) if exploitation is suspected.
2. Take full backups (files + DB) and preserve copies for forensic review.
3. Disable the vulnerable plugin immediately.
4. Sanitize database entries (term descriptions, posts, options).
5. Rotate all admin passwords and API keys. Revoke and reissue any compromised tokens.
6. Enable 2FA for all privileged accounts; limit admin accounts.
7. Review and remove any backdoors (unexpected PHP files, base64/obfuscated code).
8. Reinstall WordPress core, themes, and plugins from trusted sources if tampering is found.
9. Restore from a known-good backup if the site integrity cannot be confidently restored.
10. Monitor logs and site behavior closely for a period after remediation.

If you are not comfortable performing these steps yourself, engage a trustworthy WordPress security professional or service.

---

Longer-term mitigation & hardening

• Principle of least privilege: Give Administrator role sparingly. Use Editor or custom roles for day-to-day content editing when possible.
• Limit untrusted HTML input: Avoid plugins that permit arbitrary HTML from privileged users. Where HTML is necessary, enforce strict sanitization using wp_kses with a small allowlist.
• Keep plugins and themes to a minimum and only install from reputable sources. Regularly audit installed plugins and remove unused ones.
• Use version control and file integrity monitoring to detect unauthorized changes to theme and plugin files.
• Use secure authentication practices: 2FA, strong passwords, password managers, and account usage monitoring.
• Harden REST API and AJAX endpoints: Ensure nonce and capability checks on server-side handlers.
• Implement WAF protection and continuous malware scanning — ideally with request body inspection to catch injected payloads in POST requests.
• Monitor vulnerability advisories for the plugins you use; subscribe to trustworthy security mailing lists or service notifications.

---

Sample PHP hardening snippet for theme or mu-plugin

If you want to prevent saving HTML to term descriptions at the WordPress application level (a temporary hardening if you cannot remove the plugin immediately), you can strip unsafe tags on term creation/update:

Create a mu-plugin (must-use plugin) wp-content/mu-plugins/sanitize-term-descriptions.php:

<?php
/*
Plugin Name: Sanitize Term Descriptions - emergency
Description: Strip dangerous HTML from term descriptions as an emergency stopgap.
Author: WP-Firewall Security Team
*/

add_action('created_term', 'wf_sanitize_term_description', 10, 3);
add_action('edited_term', 'wf_sanitize_term_description', 10, 3);

function wf_sanitize_term_description($term_id, $tt_id = 0, $taxonomy = '') {
    $term = get_term($term_id, $taxonomy);
    if (!$term) {
        return;
    }
    // Allow only minimal HTML
    $allowed = array(
        'a' => array('href' => true, 'title' => true, 'rel' => true, 'target' => true),
        'br' => array(),
        'p' => array(),
        'b' => array(),
        'strong' => array(),
        'i' => array(),
        'em' => array(),
    );
    $clean = wp_kses($term->description, $allowed);
    if ($clean !== $term->description) {
        wp_update_term($term_id, $taxonomy, array('description' => $clean));
    }
}
?>

This will proactively clean descriptions when terms are created or edited. It is an emergency measure — do not rely on it long-term if the plugin enables rich HTML editing.

---

How WP‑Firewall helps (brief overview)

As a WordPress security provider, WP‑Firewall provides managed WAF rules, malware scanning, and virtual patching which can detect and block attempts to exploit this stored XSS pattern (payloads saved via taxonomy edits, REST, or admin POSTs). Our service can:

• Detect POST requests attempting to save known XSS vectors in taxonomy descriptions.
• Apply virtual patches (WAF signatures) tailored to the plugin’s behavior to stop exploitation immediately — even before the plugin vendor releases a patch.
• Run automated site scans to find suspicious taxonomy descriptions, malicious files, and backdoors.
• Provide remediation suggestions and step-by-step cleanup guidance.

If you already have a WAF in place, ensure it inspects POST bodies and REST/AJAX payloads — many default setups do not.

---

Example detection signatures to monitor in logs

• Request bodies containing <script or javascript: in combination with wp-admin/term.php, rest endpoints, or admin-ajax.php.
• Admin POSTs that include description with suspicious attributes (onerror=, onload=, data:).
• Sudden increase of requests to taxonomy pages resulting in redirect or external calls to unknown domains.
• Creation or modification of terms at unusual hours or from uncommon IP addresses.

---

Real-world impact scenarios

• Scenario A: An attacker injects a script into a category description that creates a new admin user by calling admin AJAX endpoints using the victim admin’s browser. Result: full site takeover.
• Scenario B: Script loads external malicious JS and redirects visitors to adware or phishing landing pages, harming site reputation and SEO.
• Scenario C: Script harvests form inputs or session information and exfiltrates to attacker-controlled domains, enabling later targeted attacks.

These are realistic consequences even when the initial exploit vector requires an admin action — attackers are adept at social engineering and reusing stolen credentials.

---

Preventative development advice (for plugin/theme authors and agencies)

• Never trust user input — even from administrators. Always sanitize output using context-appropriate escaping (esc_html, esc_attr, wp_kses_post with a strict allowed list).
• For editable HTML fields, persist only sanitized, validated HTML and store safe variants (or use a WYSIWYG that sanitizes on save).
• Implement capability and nonce checks on all server-side endpoints that modify site state (admin-ajax handlers, REST endpoints).
• Add automated unit/integration tests around XSS vectors and sanitize/escape flows in CI.
• Maintain a responsible disclosure channel and update policy so users can get timely fixes.

---

New Title: Secure your site now — start with WP‑Firewall Free Plan

If you want a fast, practical layer of protection while you investigate and remediate this issue, consider WP‑Firewall’s Basic (Free) plan. It includes essential managed firewall rules, a WAF, malware scanning, and mitigation for OWASP Top 10 risks — everything you need to dramatically reduce the attack surface and block common XSS exploitation attempts immediately. Explore the free plan and sign up at:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Plan highlights:

• Basic (Free): managed firewall, unlimited bandwidth, WAF, malware scanner, OWASP Top 10 mitigation.
• Standard ($50/year): everything in Basic + automatic malware removal and IP blacklist/whitelist (20 IPs).
• Pro ($299/year): adds monthly reports, auto virtual patching, plus premium add-ons like Dedicated Account Manager and Managed Security Service.

---

Quick recap & final checklist

• If you run “Allow HTML in Category Descriptions” (<= 1.2.4): disable the plugin immediately.
• Backup site (files + DB) and take forensic copies.
• Scan and sanitize term descriptions (WP‑CLI SQL queries or wp_kses PHP script).
• Rotate admin passwords and enable 2FA. Revoke sessions and API tokens if in doubt.
• Deploy WAF rules to stop POSTs that try to save script-like payloads (virtual patch).
• Inspect for further compromise (new users, new files, changed options).
• Rebuild or restore from a known-clean backup if tampering is extensive.
• Replace the plugin with safer alternatives or use controlled, sanitized HTML only.

---

If you’d like direct assistance with triage, WAF rule creation, rapid virtual patching, or a detailed remediation plan, WP‑Firewall’s Basic plan will give you immediate, managed protections while you take the cleanup steps above. Start your free plan here: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Stay safe and treat taxonomy fields that accept HTML as high-risk inputs — sanitization and strict output escaping are your best defense.