✅ VULNÉRABILITÉ CONFIRMÉE — Charge utile XSS stockée écrite et exécutée

Impact confirmé :

• HTML/JS arbitraire non authentifié stocké dans la base de données CCT sans désinfection
• XSS déclenchée pour chaque visiteur chargeant une page contenant le widget Maps Listing
• Vol de cookies, détournement de session, collecte d'identifiants stockés, prise de contrôle de l'administrateur

Détails de la vulnérabilité

Résumé technique

La vulnérabilité est une combinaison de deux faiblesses indépendantes :

1. Absence de désinfection des entrées (stockage) : La méthode sanitize_field_value() du gestionnaire d'éléments CCT n'a aucun chemin de désinfection pour les champs de type text. Le cas default: ne fait que convertir les horodatages — le HTML brut passe et est persisté en base de données.

2. Sink XSS basé sur le DOM (rendu) : Le widget Maps Listing lit la valeur de champ stockée via get_marker_label(), l'enveloppe dans htmlspecialchars(json_encode(...)) pour l'attribut HTML data-markers, et le JavaScript frontal lit l'attribut avec getAttribute() (qui décode les entités HTML), puis insère markerData.label directement via innerHTML — exécutant tout HTML/JavaScript intégré.

Composants affectés

Chaîne d'exploitation

Étape 1 — Écriture REST non authentifiée

Le contrôleur REST public des CCT vérifie les permissions via check_user_permissions() :

Lorsqu'un CCT est configuré avec rest_put_access = 'public' (une configuration prise en charge et documentée pour les formulaires publics), le point de terminaison est entièrement non authentifié. N'importe quel client HTTP peut envoyer une requête POST à /wp-json/jet-cct/{slug}.

Étape 2 — Stockage non désinfecté

Le gestionnaire REST appelle $handler->update_item($params), qui atteint sanitize_field_value() :

Un champ de type text atteint la branche default:. maybe_to_timestamp() renvoie la valeur inchangée pour les chaînes non datées. La charge utile XSS `` est stockée telle quelle.

Étape 3 — Étiquette récupérée sans échappement

Lorsque le widget Maps Listing effectue le rendu, get_marker_label() lit le champ :

La valeur renvoyée est placée dans le tableau de données des marqueurs :

Étape 4 — L'encodage d'attribut n'empêche pas l'XSS via innerHTML

Le tableau des marqueurs est encodé pour un attribut HTML :

json_encode sérialise `` comme la chaîne "". htmlspecialchars encode ensuite en HTML l'intégralité du JSON, produisant :

Ceci est écrit dans l'attribut HTML data-markers. L'encodage ne protège que la limite de l'attribut. Lorsque JavaScript lit l'attribut, le navigateur décode les entités HTML, restaurant les caractères d'origine :

Étape 5 — Injection innerHTML (déclenchement de l'XSS)

Dans frontend-maps.js, la chaîne d'étiquette brute est insérée directement dans une chaîne de contenu HTML :

Cette chaîne de contenu est ensuite définie comme innerHTML de l'élément marqueur :

Chaque visiteur qui charge une page contenant le widget Maps Listing déclenche la charge utile.

Preuve de concept

Prérequis

1. Les modules maps-listings et custom-content-types de JetEngine sont activés.
2. Un CCT nommé locations (slug : locations) existe avec :
   • rest_put_enabled = true
   • rest_put_access = 'public'
   • Un champ de type text nommé label
3. Un widget Maps Listing sur n'importe quelle page frontale est configuré avec :
   • marker_type = 'text'
   • marker_label_type = 'meta_field'
   • marker_label_field = 'label'

Étape 1 — Écriture de la charge utile XSS (non authentifiée)

Réponse:

Étape 2 — Confirmer le stockage de la charge utile brute

Réponse:

La balise `` est stockée telle quelle — aucune désinfection n'a eu lieu.

Étape 3 — Déclenchement de l'XSS (la victime visite la page)

Tout visiteur, authentifié ou non, qui charge une page contenant le widget Maps Listing exécutera la charge utile. L'attribut HTML rendu contient :

JavaScript lit data-markers, décode les entités HTML, analyse le JSON et l'insère dans le DOM :

Démonstration en direct — Flux de charge utile de bout en bout

Analyse des causes racines

Cause 1 — Champs text exemptés de désinfection

sanitize_field_value() gère explicitement wysiwyg avec une désinfection basée sur wp_kses, mais place tous les autres types de chaînes dans une branche default: qui n'effectue aucun échappement HTML. L'hypothèse selon laquelle les champs text sont du texte brut est violée lorsque ces valeurs sont ensuite rendues comme HTML via le chemin innerHTML du widget Maps.

Cause 2 — htmlspecialchars mal appliqué

htmlspecialchars(json_encode($result)) est appliqué pour protéger la limite de l'attribut HTML. C'est correct et nécessaire — mais cela ne suffit pas à empêcher l'XSS lorsque la valeur est ensuite relue via JavaScript et insérée dans le DOM via innerHTML. L'encodage est réversible par le navigateur. La correction appropriée consiste à appliquer esc_html() (ou htmlspecialchars) à la valeur individuelle label avant l'encodage JSON, afin que la charge utile soit stockée dans le JSON comme texte encodé en entités. Lorsque JavaScript l'insère via innerHTML, le navigateur rend <img> comme texte, et non comme une balise HTML.

Alternativement, remplacez innerHTML par textContent dans le JavaScript pour le champ d'étiquette.

Cause 3 — Portée insuffisante de la politique de désinfection

Le chemin d'écriture de l'API REST (update_item) ne traite pas toutes les valeurs stockées comme des sinks HTML potentiels. La politique de désinfection n'est définie que par type de champ, les champs text étant silencieusement exemptés alors qu'ils sont rendus comme HTML côté front via le widget Maps.

Correction

Chronologie

Références

• Avis Wordfence — CVE-2025-67923
• Avis de Patchstack
• Changelog de JetEngine — 3.7.8
• OWASP — XSS stocké
• OWASP — XSS basé sur le DOM
• CWE-79 : Neutralisation inappropriée de l'entrée lors de la génération de pages Web