Une faille critique récemment divulguée dans l’OWASP Core Rule Set permet à des attaquants de contourner la validation du jeu de caractères et de lancer discrètement des attaques de type cross-site scripting (XSS) contre des applications web.
Cette faille affaiblit un contrôle de sécurité important sur lequel de nombreuses organisations comptent au niveau du pare-feu applicatif web (WAF) pour détecter et bloquer les attaques encodées.
La vulnérabilité « permet à des attaquants de contourner la validation du jeu de caractères en exploitant la manière dont les règles chaînées de ModSecurity traitent les collections », a déclaré l’équipe OWASP CRS.
Comment fonctionne le contournement du jeu de caractères d’OWASP CRS
La vulnérabilité, suivie sous l’identifiant CVE-2026-21876, affecte une règle centrale de l’OWASP Core Rule Set, largement déployée dans les environnements Apache ModSecurity, ModSecurity v3 et Coraza.
Comme le CRS est couramment utilisé comme première ligne de défense pour les applications web, cette faille réduit l’efficacité des protections des WAF conçues pour bloquer les charges utiles d’attaque encodées, renforçant la dépendance aux contrôles de l’application en backend.
Le problème concerne les versions 3.3.x à 3.3.7 et 4.0.0 à 4.21.0 du CRS, ce qui expose potentiellement un grand nombre d’environnements de production.
Au cœur du problème se trouve la règle 922110, conçue pour détecter et bloquer les encodages de caractères dangereux — tels que UTF-7 et UTF-16 — dans les requêtes de formulaire multipart.
Ces encodages sont utilisés depuis longtemps par les attaquants pour contourner les filtres d’entrée et transmettre des charges utiles de cross-site scripting (XSS) d’une manière susceptible de contourner une logique de validation naïve.
Les chercheurs ont constaté que la règle n’évalue pas systématiquement toutes les parties d’une requête HTTP multipart. Elle ne valide au contraire que le dernier segment, ignorant complètement les composants précédents.
Ce comportement permet aux attaquants de construire des requêtes multipart dans lesquelles une charge utile JavaScript malveillante encodée en UTF-7 est placée dans une partie antérieure de la requête, suivie d’un contenu UTF-8 inoffensif dans la dernière partie.
Comme la règle n’inspecte que le dernier segment, la requête peut traverser le WAF sans déclencher d’alerte.
La vulnérabilité a reçu un score CVSS de 9,3, qui reflète son exploitabilité à distance et l’absence d’exigence d’authentification.
Bien qu’aucune exploitation active n’ait été signalée, cette technique utilise des méthodes XSS bien connues fondées sur l’encodage et nécessite peu d’efforts pour être mise en œuvre.
Réduire les risques liés aux défaillances des règles d’OWASP CRS
L’application des dernières mises à jour d’OWASP CRS constitue l’étape la plus importante, mais des contrôles supplémentaires peuvent aider à détecter les tentatives de contournement et à limiter leur impact potentiel.
- Mettez immédiatement à niveau les déploiements d’OWASP CRS vers la version 4.22.0 (CRS 4.x) ou 3.3.8 (CRS 3.3.x), et vérifiez que les règles mises à jour sont effectivement appliquées.
- Vérifiez les configurations et les journaux du WAF pour vous assurer que l’inspection des requêtes multipart fonctionne correctement et qu’aucune ancienne règle ne reste chargée.
- Limitez les encodages de caractères acceptés à UTF-8 au niveau du serveur web et de l’application, en bloquant explicitement les encodages obsolètes tels que UTF-7.
- Implémentez des WAF règles personnalisées ou compensatoires pour détecter ou bloquer les requêtes multipart contenant des déclarations de jeu de caractères mixtes ou inhabituelles.
- Renforcez les défenses au niveau de l’application en imposant une validation robuste des entrées, un encodage des sorties adapté au contexte et des en-têtes de Content Security Policy (CSP) restrictifs.
- Améliorez la surveillance et la préparation aux incidents en suivant les schémas de trafic multipart anormaux et en validant les protections.
- Testez et affinez les plans de réponse aux incidents au moyen d’exercices sur table et de simulations d’attaques.
Ensemble, ces mesures contribuent à préserver l’efficacité des protections des WAF, même lorsque certaines règles présentent des limites.
Le risque de supposer que les outils de sécurité fonctionnent toujours
Même des contrôles de sécurité bien établis et largement approuvés peuvent être compromis par de subtiles failles logiques ou d’implémentation, difficiles à détecter dans le cadre du fonctionnement courant uniquement.
Alors que les attaquants cherchent de plus en plus à sonder les cas limites des outils de sécurité, s’en remettre à des protections configurées une fois pour toutes devient progressivement moins efficace.
Cette réalité souligne la nécessité de mettre régulièrement à jour, de valider et de tester les contrôles défensifs afin de s’assurer qu’ils continuent de fonctionner comme prévu face à l’évolution des techniques d’attaque.
Par conséquent, de nombreuses organisations réexaminent leurs hypothèses de sécurité et se tournent vers des principes de confiance zéro qui privilégient la vérification continue à la confiance implicite.