FlawOpen

flawopen.com/Incidents/wordpress-stored-xss-admin-session-campaign-october-2026

● WordPress plugin installations (campaign observations attributed to Patchstack) · CVE-2026-93836 · 2026-10-04 · CVSS 7.2 · Haute
Recherche · FlawOpen

Campagne XSS stocké WordPress : deux extensions, une chaîne de persistance

Patchstack a observé des tentatives d’utilisation du même implant post-exploitation via deux failles XSS stockées dans WordPress. Mettez à jour les deux extensions et recherchez une persistance : un correctif ne nettoie pas un site déjà compromis.[1], [2], [3], [4], [5]

💡 Explication en Langage Simple (ELI5)

Imaginez deux boîtes à suggestions publiques dont les messages sont ensuite ouverts par la personne qui administre le site. Si le site enregistre un message comme balisage exécutable au lieu de l’afficher comme du texte, celui-ci peut agir avec les privilèges du navigateur de l’administrateur lorsqu’il l’ouvre. Le rapport indique que deux failles d’extensions distinctes ont servi de points d’entrée, puis que l’attaquant a tenté de conserver l’accès après une mise à jour.[1], [8], [9]

Concepts Clés et Termes

XSS stocké
Un texte contrôlé par un attaquant est enregistré puis rendu comme balisage exécutable dans un navigateur. Ici, le contexte sensible était l’administration WordPress.[2], [3], [8], [9]
Session de même origine
Le navigateur joint automatiquement la session du site aux requêtes de même origine. Un script déjà exécuté sur ce site peut agir par la page sans lire un cookie HttpOnly.[1], [17], [18]
Persistance
Un accès qui subsiste après la correction de la faille initiale, par exemple des comptes ou fichiers non autorisés. Une mise à jour propre ne supprime pas ces changements.[1]
Attribution CVSS
Les fiches CNA de Wordfence attribuent un score CVSS 3.1 de 7,2 à chaque CVE. Patchstack affiche 7,1 dans son avis WPC Product Bundles ; cet article utilise le score de la fiche CVE et précise la source.[2], [3], [6]
Pistes dans le code source
Les références CNA de Wordfence pointent vers des fichiers versionnés de WPC Product Bundles et Ninja Forms liés à la validation, au stockage et à l’affichage dans l’administration. Ce sont des pistes à consulter, pas un diff de correctif vérifié. Le code PHP ci-dessus illustre l’encodage de sortie ; il ne reconstitue pas le code des extensions.[8], [9], [10], [11], [12], [13], [14], [15], [16]

Correspondances de référentiels

Chronologie de l'Incident

2026-09-21 / 2026-09-22

Les fiches CNA de Wordfence indiquent une publication le 21 septembre, tandis que Patchstack affirme que les failles avaient été divulguées publiquement le 22 septembre. Les sources diffèrent d’un jour ; les fiches CVE indiquent des versions affectées jusqu’à 8.6.6 et 3.15.3, respectivement.[2], [3], [8], [9], [1]

2026-10-04 au 2026-10-05

Patchstack indique avoir observé des tentatives utilisant la même étape post-exploitation, d’abord par WPC Product Bundles, puis par Ninja Forms. Patchstack a publié son analyse le 6 octobre.[1]

Déroulement de l'Attaque Étape par Étape

Étape 1

Deux points d’entrée XSS stockés distincts

Selon Patchstack, une campagne a utilisé CVE-2026-93836 dans WPC Product Bundles et CVE-2026-94504 dans Ninja Forms. Ce sont deux failles distinctes, reliées dans le rapport par une activité ultérieure commune.[1], [2], [3], [8], [9]

Étape 2

Le contenu stocké est ouvert par un administrateur

Les données soumises sont enregistrées puis affichées dans une vue administrative de commande ou de soumission. Si une sortie mal échappée s’exécute comme balisage, la visite de l’administrateur fournit le contexte du navigateur.[1], [8], [9], [10], [11], [12], [13], [14]

Étape 3

Le script hérite du contexte du site

Un code exécuté depuis l’origine WordPress peut envoyer des requêtes de même origine avec la session existante de l’administrateur. HttpOnly protège la confidentialité du cookie, mais n’empêche pas un script déjà exécuté dans cette origine d’utiliser la session.[1], [17], [18]

Étape 4

Un accès secondaire peut survivre à la faille

Patchstack rapporte des tentatives d’installation d’extension et de persistance supplémentaire. Ce sont des observations de campagne, pas un résultat confirmé pour chaque cible ; une mise à jour bloque l’entrée vulnérable, mais ne retire pas les changements déjà effectués.[1], [4], [5]

Code Source : Vulnérable vs Sécurisé

Il s'agit du changement dans le code source de Textarea::admin_form_element() de Ninja Forms, et non d'un modèle générique. La version 3.15.3 insérait directement le texte de soumission stocké dans le corps HTML d'un textarea ; la 3.15.4 applique esc_textarea() avant l'affichage. Le contenu ne peut ainsi plus être interprété comme du balisage dans ce contexte. Cet exemple documente uniquement le chemin Ninja Forms de CVE-2026-94504 ; il ne montre pas le correctif de WPC Product Bundles pour CVE-2026-93836. Utilisez un échappement adapté à chaque contexte ailleurs.[13], [15], [16]

IMPLÉMENTATION VULNÉRABLE
public function admin_form_element( $id, $value )
{
    return "<textarea class='widefat' name='fields[$id]'>$value</textarea>";
}
PATCH SÉCURISÉ ET ROBUSTE
public function admin_form_element( $id, $value )
{
    return "<textarea class='widefat' name='fields[$id]'>" . esc_textarea( $value ) . "</textarea>";
}

Liste de Contrôle de Sécurité pour l'Ingénierie

Sources