Avertissement de la communauté XSS dans les descriptions de catégorie (CVE20260693)

Cross Site Scripting (XSS) dans WordPress Autoriser HTML dans le plugin de descriptions de catégorie
Nom du plugin Autoriser HTML dans les descriptions de catégorie
Type de vulnérabilité Script intersite (XSS)
Numéro CVE CVE-2026-0693
Urgence Faible
Date de publication CVE 2026-02-13
URL source CVE-2026-0693

Urgent: Stored XSS in “Allow HTML in Category Descriptions” (<= 1.2.4) — Ce que les propriétaires de sites WordPress doivent faire maintenant

Résumé : 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 advisory explains technical details, threat scenarios, immediate mitigations, detection and clean-up steps, and longer-term hardening from the perspective of a Hong Kong security expert.

Remarque : Si vous utilisez ce plugin et avez une version affectée installée, considérez cela comme une tâche de sécurité de site à haute priorité — même si la vulnérabilité nécessite des privilèges d'administrateur, l'impact peut être significatif en pratique.


Quelle est la vulnérabilité ?

  • Type : Script intersite stocké (XSS).
  • Affected component: WordPress plugin “Allow HTML in Category Descriptions” — versions ≤ 1.2.4.
  • CVE : CVE-2026-0693.
  • CVSS : 5.9 (moyen), Vecteur : 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.

Pourquoi cela importe : Les administrateurs sont des comptes de confiance. Un attaquant qui compromet un compte admin (ou trompe un admin pour sauvegarder une description conçue) peut persister des scripts qui victimisent d'autres utilisateurs admin ou visiteurs du site. Les conséquences incluent la défiguration du site, la collecte de données d'identification, des redirections malveillantes ou la prise de contrôle complète du site par le biais d'attaques en chaîne.


Comment un attaquant peut exploiter cela

  1. L'attaquant obtient ou compromet un compte Administrateur (hameçonnage, réutilisation de mot de passe, insider), ou trompe un admin pour sauvegarder une charge utile.
  2. Through 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., , an SVG with an onload/onerror handler, or attribute-based payloads such as onmouseover, srcset, or javascript: URIs.
  3. La charge utile est stockée dans la base de données (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. Les actions possibles de l'attaquant incluent :
    • Collecter des cookies/localStorage et les envoyer à un serveur distant.
    • Utiliser la session de navigateur authentifiée de la victime pour appeler les points de terminaison WordPress REST/AJAX (créant potentiellement des utilisateurs, installant des plugins, modifiant des options) si les vérifications de nonce ou de capacité sont faibles.
    • Injecter un contenu malveillant supplémentaire (publicités, redirections, formulaires de collecte de données d'identification) ou modifier des pages administratives.

Nuance importante : De nombreuses installations WordPress définissent les cookies d'authentification comme HttpOnly, empêchant l'accès direct aux cookies par JS. Cependant, JavaScript peut toujours effectuer des requêtes XHR/fetch authentifiées si les protections de même origine et de nonce sont absentes ou si les nonces sont volés. Les attaquants peuvent enchaîner XSS avec d'autres faiblesses pour accroître l'impact.

Interaction utilisateur : Bien que certains rapports classifient cela comme nécessitant une interaction utilisateur (par exemple, un administrateur visitant une page conçue), le XSS stocké est persistant et peut s'exécuter automatiquement lorsque les pages sont chargées.


Actions immédiates et prioritaires (dans l'heure qui suit)

  1. Désactivez le plugin maintenant

    Go to wp-admin → Plugins and deactivate “Allow HTML in Category Descriptions” 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 → ajouter -désactivé.

  2. Mettez le site en mode maintenance (si approprié)

    Si vous soupçonnez une exploitation active (redirections visibles, défiguration, spam), bloquez temporairement l'accès public pendant que vous enquêtez.

  3. Auditez et faites tourner les identifiants administratifs

    Forcez les réinitialisations de mot de passe pour tous les comptes Administrateur. Révoquez les sessions et les jetons (Utilisateurs → Tous les utilisateurs → pour chaque admin, “Déconnexion partout” ou utilisez des outils d'expiration de session). Appliquez des mots de passe forts et activez l'authentification à deux facteurs (2FA) pour les comptes administrateurs.

  4. Bloquez les nouvelles requêtes qui tentent de sauvegarder des charges utiles XSS

    Si vous pouvez déployer un filtrage des requêtes au niveau de l'hôte, du CDN ou via un pare-feu d'application Web (WAF), bloquez les requêtes POST qui tentent de sauvegarder des descriptions de catégorie contenant des motifs semblables à des scripts. Voir les règles WAF suggérées plus loin dans cet article.

  5. Sauvegardez votre site (fichiers + DB)

    Créez une sauvegarde complète avant de modifier ou de nettoyer le site. Exportez la base de données et téléchargez wp-content et uploads pour des copies judiciaires.

  6. Scannez immédiatement les indicateurs de compromission

    Recherchez des utilisateurs inattendus, des fichiers inconnus, des tâches planifiées (travaux wp_cron), des valeurs d'option modifiées et du contenu injecté dans les publications, les pages et les descriptions de taxonomie.


Enquête : trouvez des descriptions de catégorie malveillantes et évaluez les dommages

Les descriptions de catégorie sont stockées dans la base de données ; recherchez rapidement du contenu semblable à des scripts.

Utiliser WP-CLI (recommandé si vous avez un accès shell) :

wp db query "SELECT term_taxonomy_id, term_id, description FROM wp_term_taxonomy WHERE description LIKE '%
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 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 '(
  • Widgets and theme options: check wp_options for injected HTML.
  • Plugin/theme files for unfamiliar or obfuscated code.

If you find suspicious descriptions, export them for forensics before making mass modifications.


Cleaning infected descriptions safely

Option A — Manual removal (small number of entries)

Use wp-admin → Posts/Terms editor and manually edit descriptions to remove payloads: Posts → Categories → edit each suspect category description.

Option B — Database cleanup (large or automated cleanup)

Test on a backup first. Example SQL to remove blocks from term descriptions UPDATE wp_term_taxonomy SET description = REGEXP_REPLACE(description, ']*>.*?', '', 'si') WHERE description REGEXP ']*>';

Stripping event handler attributes like onload/onerror is more complex; prefer a PHP-based sanitizer to avoid breaking legitimate markup.

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

Create a one-off PHP script and run via WP-CLI eval-file or an admin-only execution path:

 '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 with:

wp eval-file sanitize-term-descriptions.php

Notes: Using wp_kses with a minimal allowlist is safer than regex-only approaches. Test on a staging site or backup first.


Suggested defensive WAF rules and short-term virtual patching

If you have the ability to configure a WAF, CDN rules, or host request filtering, add rules to block attempts to store suspicious payloads or to block rendering of known-suspicious content. These measures are temporary mitigations while you remove the vulnerable plugin or fully remediate the site.

Simple detection heuristics

  • Block POST requests to /wp-admin/term.php or REST endpoints used to save term descriptions that contain , onerror=, onload=, javascript:, data:text/html, svg/onload, iframe, or suspicious src attributes with data:/javascript:.
  • Block requests that include 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