Description

Modern Events Calendar Lite enregistre une famille d'actions admin-ajax.php "load more" non authentifiées pour ses skins de liste d'événements (list, grid, masonry, agenda, timeline, tile, custom). Chaque gestionnaire lit le tableau de requête atts contrôlé par l'attaquant, le fait passer par une fonction auxiliaire nommée sanitize_deep_array() qui — lorsqu'elle est appelée avec ses arguments par défaut — n'effectue aucune désinfection du tout — puis concatène les valeurs atts['include'] (et atts['exclude']) brutes dans un fragment SQL post_id IN (...) exécuté avec $wpdb->get_results() et sans $wpdb->prepare().

Comme les points d'entrée sont enregistrés sur wp_ajax_nopriv_*, aucune authentification, aucun compte, nonce ou interaction utilisateur n'est requis. Un attaquant distant non authentifié peut injecter du SQL arbitraire dans la clause WHERE d'un SELECT sur wp_mec_dates et lire toutes les données de la base WordPress (empreintes de mots de passe utilisateur, secrets/clés wp_options, données d'autres extensions) via des techniques aveugles temporelles / booléennes / basées sur les erreurs.

Cause racine

1. Un « sanitizer » qui ne nettoie rien sur le chemin par défaut

app/libraries/main.php:9607 :

La garde (is_array($excludes) and !count($excludes)) fait de la fonction une pure opération nulle lorsque $excludes est le tableau vide par défaut — chaque valeur est recopiée telle quelle. L'intention était visiblement "s'il existe une liste d'exclusion, ignorer ces clés" ; la logique booléenne ignore au contraire tout lorsqu'aucune liste d'exclusion n'est fournie.

2. L'appelant ne fournit pas de $excludes

app/skins/list.php:499-501 (load_more()) :

sanitize_deep_array($_REQUEST['atts']) est appelée avec un seul argument → $excludes prend par défaut array() → la branche d'opération nulle ci-dessus → $atts est la valeur brute et non fiable de $_REQUEST['atts'].

3. Concaténation brute dans la clause IN (...)

app/libraries/skins.php :

Les éléments du tableau sont directement intégrés via implode() dans la chaîne SQL, sans cast entier ni échappement. (absint()/(int) sur chaque élément aurait fermé cette faille.)

4. Exécution sans requête préparée

app/libraries/db.php:79 :

La chaîne entièrement construite est transmise telle quelle à $wpdb->get_results().

Flux de contamination (requête → puits) :

Accessibilité

app/skins/list.php:51-52 :

L'enregistrement nopriv rend le point d'accès atteignable avant toute authentification. La même structure de load_more() et le constructeur de requête partagé skins.php sont présents dans les skins frères, chacun avec sa propre action wp_ajax_nopriv_*, de sorte que la même injection est atteignable via l'une quelconque des :

Aucun nonce n'est vérifié dans load_more(), et l'action n'exige la présence d'aucun shortcode d'extension sur une page — les gestionnaires AJAX sont enregistrés inconditionnellement à l'initialisation.

Preuve de concept (vérifiée en laboratoire, MEC Lite 6.5.6, WordPress 6.6.5, MariaDB 10.x)

Toutes les requêtes sont non authentifiées (aucun cookie, aucun nonce). La valeur injectée est placée dans atts[include][] ; la charge utile ferme les deux parenthèses ouvertes du groupe IN ((...) AND (... IN ( et ajoute un OR <sleep> de niveau supérieur pour que la condition soit évaluée pour chaque ligne analysée, puis commente la fin )) ORDER BY ... :

La requête exacte exécutée (capturée depuis WP_DEBUG_LOG) pour une valeur canari d'erreur atts[include][]=0)MEC_SQLI_CANARY était :

— le jeton littéral MEC_SQLI_CANARY apparaît tel quel dans l'instruction exécutée, confirmant la concaténation brute. Le paramètre atts[exclude][] (skins.php:803 / 603, NOT IN) est injectable à l'identique (confirmé en laboratoire : atts[exclude][]=0)) OR SLEEP(3)# → ~3.5s). La requête et l'injection identiques ont été reproduites sur 7.33.0 (version actuelle) — même canari, même comportement SLEEP.

PoC automatisé

mec-unauth-sqli-poc.py (inclus) est entièrement autonome et ne nécessite aucun identifiant : il confirme l'injection (référence vs SLEEP), puis effectue une extraction aveugle temporelle de données arbitraires (par défaut : @@version, utilisateur de la base, et user_login:user_pass du premier administrateur). Il valide chaque réponse (HTTP 200) et espace les requêtes avec --delay + back-off pour survivre aux WAF/limiters de débit (par ex. mod_evasive). Aucune donnée n'est modifiée (contexte SELECT en lecture seule).

Impact

Accès non authentifié, accessible depuis le réseau, en lecture complète de la base de données : empreintes de mots de passe wp_users, wp_options (auth_key, secrets API, jetons), et toute autre table. En pratique, cela s'enchaîne en prise de contrôle totale du site (craquage de hash hors ligne, vol de secrets/sessions). L'impact sur l'intégrité est limité — l'injection s'exécute dans un SELECT via $wpdb->get_results(), qui ne permet pas les requêtes empilées — d'où I:N. Des SLEEP/BENCHMARK intensifs pourraient dégrader la disponibilité, mais l'impact principal, démontré de façon fiable, est la confidentialité (C:H), ce qui donne un CVSS 7.5.

Fichiers affectés

Les numéros de ligne sont donnés pour 7.33.0 (actuel) avec 6.5.6 entre parenthèses ; le code est identique sur toute la plage.

Les skins frères (grid, masonry, agenda, timeline, tile, custom) partagent le même load_more() + constructeur de requête skins.php et enregistrent chacun une action wp_ajax_nopriv_* → même bug, multiples points d'entrée.

Distinction par rapport aux CVE d'injection SQL antérieures de Modern Events Calendar

Il s'agit d'un point d'injection distinct et jamais signalé auparavant. Chaque injection SQL MEC documentée publiquement cible une action et un paramètre AJAX différents, et toutes ont été corrigées dans des versions antérieures à cette découverte (elle est confirmée active en laboratoire dans 7.33.0) :

• Chemin de code différent. Les problèmes non authentifiés antérieurs se trouvent dans le gestionnaire d'événement unique mec_load_single_page ; celui-ci se trouve dans la pagination « load more » des skins (load_more() → MEC_skin::initialize() → constructeur post_id IN (...) de app/libraries/skins.php), atteinte via la branche par défaut sans effet de sanitize_deep_array(). Les correctifs de mec_load_single_page ne touchent pas skins.php.
• Aucune condition de configuration préalable. CVE-2021-4458 (id) n'était exploitable qu'avec l'échappement d'entrée PHP/WordPress désactivé (un état non par défaut) parce que cette valeur se trouve dans un contexte entre guillemets. Ici, les valeurs atts[include]/atts[exclude] arrivent dans un contexte numérique non entre guillemets IN(...) et sont exploitées avec des parenthèses + mots-clés SQL (0)) OR SLEEP(3)#), ce que wp_magic_quotes() ne neutralise pas. C'est donc exploitable sur une installation WordPress par défaut — confirmé en laboratoire sur WP 7.0 standard (magic quotes activés).
• Survit à tous les correctifs antérieurs. Confirmation d'exploitation sur 7.33.0 — quatre ans et une version majeure après le dernier correctif de mec_load_single_page (6.4.0).

Note de divulgation / périmètre

Modern Events Calendar Lite a été retiré de wordpress.org le 2022-05-11 (« Raison : violation des directives »), de sorte que la version wordpress.org est figée en 6.5.6. Cela ne signifie pas que l'extension est abandonnée — Webnus a poursuivi le développement hors plateforme : la version Lite actuelle distribuée depuis mec.webnus.net est la 7.33.0, et le chemin de code vulnérable y est identique octet pour octet (confirmé en laboratoire ; l'injection SQL se déclenche à l'identique sur 7.33.0). Le bug affecte donc toutes les versions de la gamme post-retrait, pas seulement la copie figée de wordpress.org.

Implications pour l'acheminement de la divulgation (l'objection « fermé sur wordpress.org » est bien plus faible qu'il n'y paraît) :

• C'est un produit actuel, distribué par le fournisseur et pris en charge, pas un code abandonné — une divulgation coordonnée à Webnus est le canal principal ; ils publient activement des mises à jour et devraient corriger.
• MEC Pro (vendu activement ; 7.x actuel) est construit sur cette même base de code 7.x. app/libraries/skins.php, app/libraries/main.php, et app/libraries/db.php sont des bibliothèques centrales partagées, donc Pro est quasi certainement affecté. Cela devrait être confirmé contre le code source de Pro avant de l'affirmer formellement, mais l'architecture de bibliothèques partagées le rend très probable. Un impact Pro confirmé rend la découverte sans ambiguïté dans le périmètre de Patchstack (un composant vendu publiquement) et mérite un CVE MITRE/Patchstack indépendamment du statut de la liste wordpress.org.
• Pour les consommateurs qui s'appuient spécifiquement sur la liste wordpress.org (certains critères de prime Wordfence ; l'exclusion de « composant fermé » de Patchstack telle qu'appliquée à la version gratuite Lite), citez l'impact de la 7.33.0 distribuée par le fournisseur + Pro plutôt que la 6.5.6 figée.

Un CVE est justifié au fond : injection SQL non authentifiée, accessible depuis le réseau, permettant la lecture complète de la base, dans un produit actuel distribué par le fournisseur avec une base d'installations historiques à six chiffres.

Chronologie