Aperçu

Le 1er juin 2026, une vulnérabilité XSS stockée affectant le plugin Remplaçant de mots WordPress (versions ≤ 0.4) a été divulguée publiquement et a reçu le numéro CVE-2026-3620. Le problème est un XSS stocké authentifié, réservé aux administrateurs — ce qui signifie qu'un utilisateur avec des privilèges d'administrateur dans WordPress peut enregistrer une entrée malveillante qui est ensuite rendue sans échappement approprié, provoquant l'exécution de JavaScript dans le navigateur des visiteurs du site ou d'autres utilisateurs administratifs.

Bien que cette vulnérabilité nécessite un accès administrateur pour introduire la charge utile, les conséquences peuvent être graves : prise de contrôle persistante de compte, défiguration de site, installation de porte dérobée, vol de cookies/tokens, élévation de privilèges et mouvement latéral à l'intérieur du site. Le score de base CVSS rapporté est de 5.9 (moyen), mais le risque pratique dépend fortement de la capacité d'un attaquant à acquérir ou à contraindre un compte administrateur (ingénierie sociale, mots de passe réutilisés, appareils compromis, entrepreneur malveillant, etc.).

Ce guide résume comment la vulnérabilité fonctionne, les scénarios d'attaque réalistes, les indicateurs de détection, les étapes de confinement et d'atténuation (y compris les corrections temporaires), le durcissement à long terme et les conseils aux développeurs pour corriger la cause profonde.

Crédit : vulnérabilité divulguée dans un avis public (CVE-2026-3620). Recherche créditée à san6051 (COFFSec).

What is Stored XSS and why is an “authenticated admin” vector important?

Le Cross-Site Scripting (XSS) stocké se produit lorsqu'un attaquant stocke un script malveillant dans des données côté serveur (base de données, table des options, publications, paramètres de plugin, etc.) et que ce script est ensuite livré à d'autres utilisateurs sans échappement ou assainissement appropriés. Étant donné que la charge utile est persistante, de nombreux visiteurs et utilisateurs peuvent être affectés au fil du temps.

An “authenticated administrator” qualifier means only accounts with Administrator capabilities can save the malicious payload. That reduces the immediate attack surface compared to unauthenticated bugs, but it remains dangerous because:

• Les comptes administrateurs sont des cibles fréquentes via le phishing, le remplissage d'identifiants et l'ingénierie sociale.
• Les administrateurs peuvent créer du contenu et des données de site persistantes.
• Un attaquant peut contraindre un administrateur à coller ou importer des charges utiles, ou utiliser un administrateur compromis pour injecter directement des entrées malveillantes.
• Le XSS stocké qui se rend dans le tableau de bord administrateur peut immédiatement compromettre d'autres sessions administratives.

Even “admin-only” stored XSS can lead to full site compromise when combined with real-world attacker techniques.

Comment fonctionne la vulnérabilité du Remplaçant de mots (niveau élevé)

Le problème technique de base est simple :

1. Le plugin expose une interface utilisateur pour que les administrateurs définissent des règles de remplacement qui sont stockées dans la base de données.
2. Lorsque ces paramètres sont enregistrés, le plugin échoue à assainir ou à valider correctement le contenu de remplacement.
3. Lorsque le plugin rend ces valeurs stockées sur le front-end ou dans le tableau de bord admin, il affiche le contenu en HTML sans échapper, permettant l'exécution de JavaScript intégré.
4. Le script s'exécute avec l'origine du site, permettant des actions en tant que visiteur victime ou administrateur.

Les modèles dangereux typiques incluent :

• Stocker du HTML brut ou du texte non échappé et l'afficher directement (par exemple, echo $value;) au lieu d'utiliser esc_html(), esc_attr() ou wp_kses().
• Construire des chaînes de remplacement qui sont insérées dans le HTML de la page ou dans des attributs sans échapper correctement.
• Permettre aux gestionnaires d'événements ou aux URI javascript: d'être sauvegardés comme partie des entrées.

Scénarios d'attaque réalistes

• Compte administrateur malveillant : Un attaquant contrôlant un compte admin installe des entrées de remplacement qui injectent du JavaScript dans les pages et les tableaux de bord, permettant la création de nouveaux admins, des modifications de thème ou des abus de l'API REST.
• Admin compromis via phishing/reutilisation de credentials : Un attaquant trompe un administrateur pour qu'il colle ou sauvegarde des entrées de remplacement fournies par l'attaquant ou clique sur une URL d'importation contenant des charges utiles.
• Mauvaise utilisation par des tiers : Un entrepreneur ou une agence avec accès admin introduit du contenu non échappé.
• Pivot ciblé : Le XSS stocké s'exécute dans le tableau de bord admin et vole des jetons d'authentification ou des nonces, permettant d'autres actions.

Bien qu'une prise de contrôle à distance non authentifiée ne soit pas disponible uniquement par ce bug, l'ingénierie sociale et le compromis ciblé comblent souvent cette lacune.

Impact et objectifs typiques des attaquants

Une fois que le XSS stocké s'exécute, les attaquants visent généralement à :

• Voler des jetons de session et prendre le contrôle des comptes.
• Créer de nouveaux utilisateurs Administrateur ou élever les privilèges.
• Installer des portes dérobées persistantes (plugins malveillants, thèmes modifiés, téléchargements PHP).
• Rediriger les visiteurs vers des arnaques ou des téléchargements automatiques.
• Afficher du contenu frauduleux ou injecter du code de monétisation.
• Collecter des données clients à partir de formulaires, de commentaires ou de pages de commerce électronique.
• Passer aux panneaux d'hébergement ou aux API si des identifiants sont présents dans l'interface admin.

Contexte CVE et gravité

• Identifiant CVE : CVE-2026-3620
• Versions affectées : Plugin Word Replacer ≤ 0.4
• Type : Cross-Site Scripting (XSS) stocké
• Privilège requis : Administrateur
• État du correctif (au moment de la divulgation) : Aucun correctif officiel du plugin disponible
• CVSS de base : 5.9
• Crédit de recherche : san6051 (COFFSec)

Even with a “medium” CVSS, treat this vulnerability as urgent for sites where admin accounts are at risk or where administrators accept input from third parties.

Détection — indicateurs de compromission

Techniques de détection clés :

1. Rechercher dans la base de données des règles ou des entrées de remplacement suspectes :

   Look for HTML tags (<script>, <iframe>) or event attributes (onclick, onmouseover) stored in options or post meta.

   Exemples de requêtes SQL :

   SELECT option_name, option_value
   FROM wp_options
   WHERE option_name LIKE '%word_replac%' OR option_name LIKE '%word_replacer%';
   
   SELECT * FROM wp_postmeta WHERE meta_value LIKE '%<script%';
   
   SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';

   Inspect for encoded payloads (base64), “javascript:” URIs, eval(, document.cookie, XMLHttpRequest, fetch(.

2. Scan front-end pages: Crawl public pages and grep for unexpected inline <script> tags or event handlers not originating from known plugins/themes.
3. Audit admin pages and user lists: Check for new admin users and recent changes to plugin/theme files.
4. Server and application logs: Look for POSTs to admin pages or import endpoints, unusual user agents, or source IPs.
5. Malware scanners: Use WordPress-aware scanners to find injected JS or common patterns.
6. Surveillez les connexions sortantes : Unexpected outbound HTTPS requests after suspicious entries were added can indicate live exploitation.

Immediate containment & triage (what to do now)

If your site uses the vulnerable Word Replacer plugin (≤ 0.4), act immediately:

1. Isolate admin accounts: Force password reset for all Administrators and enable or enforce MFA.
2. Désactiver ou supprimer le plugin : If safe to do so, deactivate and delete Word Replacer until a patched release is available.
3. Scan for malicious stored content: Search options/postmeta for <script>, javascript:, on* attributes and remove or sanitize suspicious entries. Export data first for forensic preservation if needed.
4. Inspect users and files: Remove unknown admin accounts; compare plugin/theme files against clean copies.
5. Sauvegardes : Take a full backup (files + DB) immediately for forensic preservation, then create a clean restore point.
6. Logs and forensics: Preserve webserver and PHP logs around the window of possible compromise.
7. Communiquez : For e-commerce or membership sites, be ready to notify stakeholders if user data may have been exposed.

Patching virtuel via WAF ou règles serveur

If you cannot remove the plugin immediately, virtual patching through a Web Application Firewall (WAF) or server-level rules is an effective temporary mitigation. Operators can deploy rules to:

• Block admin POST submissions that contain <script>, “javascript:” URIs, or inline event handlers in fields associated with the plugin.
• Restrict access to the plugin admin page to trusted IP ranges.
• Sanitize or strip dangerous input patterns on the fly.

Example ModSecurity-style rule (illustrative — test in staging):

SecRule REQUEST_METHOD "@streq POST" "phase:2,chain,deny,id:1003001,log,msg:'Block possible Word Replacer stored XSS payload'"
  SecRule ARGS|ARGS_NAMES "@rx (<script|javascript:|on\w+\s*=|document\.cookie|window\.location)" "t:none,t:urlDecodeUni,log"

Nginx example — block POSTs to a plugin admin page (adjust path & IP list):

location ~* /wp-admin/admin\.php$ {
  if ($request_method = POST) {
    if ($arg_page = "word-replacer") {
      allow 203.0.113.45;   # trusted admin IP
      deny all;
    }
  }
}

Warning: IP-based restrictions can lock out legitimate administrators using dynamic IPs. Test rules in staging before applying to production.

Quick temporary WordPress-level mitigation (mu-plugin)

If you can add a must-use plugin (mu-plugin), you can intercept option updates and sanitize content that looks like it belongs to Word Replacer. Place the file in wp-content/mu-plugins/block-word-replacer-xss.php.

<?php
/**
 * MU plugin: sanitize Word Replacer option updates to remove inline scripts and event handlers.
 * Install: save as wp-content/mu-plugins/block-word-replacer-xss.php
 */

add_filter( 'pre_update_option', function( $new_value, $old_value, $option_name ) {
    if ( strpos( $option_name, 'word_replacer' ) !== false || strpos( $option_name, 'word-replacer' ) !== false ) {
        // Use wp_kses to allow only safe tags and attributes. Adjust allowed tags as needed.
        $allowed = array(
            'a'      => array( 'href' => true, 'title' => true, 'rel' => true ),
            'br'     => array(),
            'em'     => array(),
            'strong' => array(),
            'b'      => array(),
            'i'      => array(),
            'u'      => array(),
            'p'      => array(),
            'ul'     => array(),
            'ol'     => array(),
            'li'     => array(),
        );
        if ( is_string( $new_value ) ) {
            $new_value = wp_kses( $new_value, $allowed );
        }
    }
    return $new_value;
}, 10, 3 );

Remarques :

• This is a protective stopgap to strip inline JavaScript and unsafe attributes from options matching the plugin. It is not a permanent fix.
• Do not rely on this alone — the plugin code should be fixed at source.

Nginx / Apache blocking for plugin admin UI

If the plugin admin page slug is known (for example: admin.php?page=word-replacer), block direct access by non-trusted IPs at the webserver level.

Nginx example (deny all POSTs to the plugin settings page except specific IPs):

location ~* /wp-admin/admin\.php$ {
  if ( $arg_page = "word-replacer" ) {
    if ( $request_method = POST ) {
      allow 203.0.113.45;  # admin office IP
      deny all;
    }
  }
}

Apache .htaccess example (inside /wp-admin):

<If "%{QUERY_STRING} =~ /page=word-replacer/ && %{REQUEST_METHOD} == 'POST'">
  Require ip 203.0.113.45
</If>

Test carefully — these rules can block legitimate admin activity.

Recovery and clean-up checklist after a confirmed compromise

1. Take the site offline or enable maintenance mode if public traffic is being poisoned.
2. Preserve logs and a forensic backup (full files + DB).
3. Reset credentials for all admin accounts and users with elevated privileges; enforce MFA.
4. Remove malicious replacement entries from the database.
5. Scan and clean the filesystem for injected files or backdoors. Replace modified core, theme and plugin files with fresh copies from trusted sources.
6. Remove unknown plugins/themes and reinstall only from official sources.
7. Rotate API keys, tokens, and any credentials exposed to the admin interface.
8. Restore from a clean backup if infection is widespread and cleanup is not feasible.
9. Re-enable public access only after multiple confirmation scans return clean results.
10. Conduct a post-incident audit to identify how the admin account was compromised (phishing, weak MFA, password reuse) and remediate the root cause.

If you are not confident performing the recovery, engage a professional incident response provider.

Long-term mitigation & best practices

• Principe du Moindre Privilège : Do not use Administrator accounts for everyday tasks; create Editor-level accounts for content editors.
• Minimal admin exposure: Keep the number of admin accounts minimal and review them regularly.
• Appliquer l'authentification multifactorielle : Exigez une authentification multi-facteurs pour tous les comptes administrateurs.
• Mots de passe forts : Utilisez des mots de passe uniques et forts ainsi qu'un gestionnaire de mots de passe.
• Désactiver l'édition de fichiers : Ajouter à wp-config.php: define( 'DISALLOW_FILE_EDIT', true );
• Gardez les logiciels à jour : Update WordPress core, themes and plugins; remove unused components.
• Limit plugins: Install plugins from reputable sources and review code for unusual behaviour when possible.
• Analyse régulière : Run vulnerability and malware scans and monitor logs for unusual admin activity.
• Sauvegardes : Maintain automatic backups with offsite copies and periodic restore testing.
• Environment hardening: Use supported PHP versions, correct file permissions, secure hosting and HTTPS everywhere.
• WAF for virtual patching: Use a WAF to apply central rules that can block common exploit payloads while awaiting official plugin patches.

Developer guidance — how to fix this class of bugs properly

Plugin developers should follow these practices to prevent stored XSS:

1. Sanitize l'entrée lors de l'enregistrement : Utilisez sanitize_text_field() ou sanitize_textarea_field() for plain text. For limited HTML, use wp_kses() avec une liste blanche stricte.
2. Échapper la sortie lors du rendu : Always escape at the point of output: esc_html(), esc_attr(), esc_url() ou wp_kses_post() selon le besoin.
3. Vérifications de capacité et de nonce : Verify user capabilities and nonces before processing POSTs.
4. Évitez de stocker du HTML brut : Avoid storing HTML that will later be embedded in attributes or inline scripts.
5. Minimise dynamic JavaScript: Avoid eval() and dynamic JavaScript construction from user content.
6. Document formats and safe defaults: Ensure safe default states for stored values and document expected formats.
7. Tests automatisés : Add tests to assert that inputs containing <script> are sanitized/escaped before output.
8. Secure upgrades: Provide clear upgrade paths and changelogs when sanitisation changes stored data formats.

Pour les hébergeurs et les fournisseurs de WordPress gérés

Hosting providers can mitigate exposure by:

• Scanning client sites for the vulnerable plugin and notifying customers promptly.
• Temporarily blocking the plugin admin page at the platform level until customers remediate.
• Offering a one-click virtual patch that blocks requests attempting to save script tags to plugin options.
• Assisting customers with forced password resets and enabling MFA.
• Quarantining sites showing active signs of compromise and offering cleanup support where permitted.

Indicators to search for in monitoring and logs

• POST requests to admin pages containing: “<script”, “javascript:”, “onmouseover=”, “onload=”, “document.cookie”, “fetch(“, “XMLHttpRequest(“.
• Unexpected new Administrator accounts.
• File change events in wp-content/plugins ou wp-content/themes shortly after suspicious admin POSTs.
• Outbound connections to unknown domains originating from the webserver.

Recommended immediate action plan — step by step

1. If the plugin is installed and can be removed safely, deactivate and delete Word Replacer (preferred).
2. If removal is not possible, apply a virtual patch via your WAF or server rules that block suspicious admin POSTs.
3. Force-reset admin passwords and enable MFA.
4. Audit the database for suspicious replacement entries and sanitize or remove them.
5. Scan and clean the site with a WordPress-aware malware scanner and perform file integrity checks.
6. Conservez les journaux et les sauvegardes pour une analyse judiciaire.
7. Monitor traffic and admin logs closely for at least two weeks after remediation.