CVE-2025-14855: Preuve de concept de XSS stocké dans le plugin WordPress SureForms

• Cible : Plugin WordPress "SureForms"
• Plugin WordPress : https://wordpress.org/plugins/sureforms/
• Type de vulnérabilité : Cross-Site Scripting stocké (XSS)
• CVE : CVE-2025-14855
• Référence : https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/sureforms/sureforms-220-unauthenticated-stored-cross-site-scripting
• Authentification : Non authentifié (Invité/Public)
• Impact : Exécution de code à distance (RCE) via le détournement de session administrateur
• Découvert par : https://nguyentiendung1006.wixsite.com/tiendung

1. Résumé

Une vulnérabilité critique de XSS stocké existe dans le plugin SureForms. La vulnérabilité provient d'une implémentation côté client non sécurisée dans entries.js où les entrées utilisateur sont décodées de manière programmatique (inversant la désinfection côté serveur) puis rendues à l'aide de dangerouslySetInnerHTML sans désinfection côté client appropriée. Cela permet à des attaquants non authentifiés d'injecter des charges utiles JavaScript malveillantes via des champs de formulaire standard, contournant les filtres wp_kses par défaut de WordPress.

2. Identification de la version

Pour vérifier si un site cible exécute SureForms, inspectez l'en-tête du fichier de traduction qui contient généralement le numéro de version.

URL cible : http://target-site.com/wp-content/plugins/sureforms/languages/sureforms.pot

Commande de vérification :

curl -s "http://target-site.com/wp-content/plugins/sureforms/languages/sureforms.pot" | grep "Project-Id-Version"

3. Rétro-ingénierie et analyse de la cause racine

La vulnérabilité réside dans l'interface d'administration basée sur React responsable de l'affichage des entrées de formulaire (entries.js).

3.1. La logique du "décodeur automatique" (Le contournement)

Dans le fichier minifié entries.js, il existe une fonction d'assistance (identifiée comme Xv dans la build analysée) conçue pour gérer les entités HTML.

Logique du code (reconstituée) :

// Fonction Xv : Prétraitement des valeurs de champ
var Xv = function(input) {
    var value = input.value;
    
    // CAUSE RACINE DE LA VULNÉRABILITÉ :
    // Si la chaîne contient des entités HTML (ex : <), crée une zone de texte,
    // injecte le contenu et extrait la valeur. 
    // Cela DÉCODE effectivement les entités HTML en balises HTML brutes.
    // Exemple : "<img ...>" devient ""
    
    if (typeof value === "string" && value.match(/&[a-zA-Z0-9#]+;/)) {
        var textarea = document.createElement("textarea");
        textarea.innerHTML = value;
        
        // Logique pour annuler la désinfection
        if (textarea.value.includes("<") || textarea.value.includes(">")) {
             value = textarea.value; // Maintenant 'value' contient du HTML BRUT
        }
    }
    return { ...input, value: value };
}

Analyse : Cette fonction contrecarre la sécurité du backend. Même si WordPress stocke correctement <script> en tant que <script> dans la base de données, cette fonction le reconvertit en <script> immédiatement après l'avoir récupéré depuis l'API.

3.2. Le sink dangereux

Après le décodage, les données sont transmises au composant de rendu (identifié comme Jv).

Logique du code (reconstituée) :

// Fonction Jv : Rendu du champ
var Jv = function(props) {
    var field = props.field;
    var val = field.value; // Cette valeur est désormais du HTML brut (post-décodage)

    // LE DÉCLENCHEUR : Vérifie si la chaîne ressemble à du HTML
    if (typeof val === "string" && val.match(/<[^>]+>/g)) {
        // LE SINK : Rendu via dangerouslySetInnerHTML SANS désinfection côté client (ex : DOMPurify)
        return React.createElement("span", {
            dangerouslySetInnerHTML: { __html: val }
        });
    }
    
    // Rendu sûr pour le texte non HTML
    return React.createElement("span", null, val);
}

4. Déroulement de l'attaque

1. Injection : Un attaquant non authentifié soumet un formulaire sur le frontend. Au lieu d'utiliser des balises HTML brutes (qui seraient supprimées/désinfectées par le backend WordPress), l'attaquant envoie des entités HTML.

2. Stockage : WordPress considère l'entrée (ex : <img...) comme un texte sûr et la stocke dans la base de données.

3. Exécution (Le piège) :

   • L'administrateur navigue vers SureForms > Entries.
   • Le navigateur récupère les détails de l'entrée via l'API JSON.
   • La fonction Xv détecte les entités et décode <img... en ` Entries.

4. Cliquez sur l'entrée soumise à l'étape 1 pour voir les détails.

5. Résultat : Le navigateur exécutera la charge utile JavaScript (alert('XSS_SUREFORMS')).