Le 29 septembre 2026, Cloudflare a publié « We tested our own WAF with frontier AI models. Here's what we found », signé par Vikram Grover, Daniele Molteni et Kuber Nandwani. L'éditeur y raconte comment il a fait jouer l'attaquant à des modèles d'IA de frontière contre son propre pare-feu applicatif, sur l'environnement de préproduction d'un client consentant. Le décompte est public : 1 107 tentatives enregistrées, 558 requêtes bloquées, 49 pistes retenues après revue humaine, trois changements de règles. Le billet ne nomme ni le modèle ni son fournisseur ; il dit seulement avoir rejoué les mêmes scénarios avec deux versions d'une même famille de modèles.
Ce que la publication apporte, c'est le protocole : boucle d'attaque, réglages de la zone testée, c'est-à-dire le domaine configuré chez Cloudflare, plafond d'essais, critères de tri. Les invites, le code et les noms de modèles ne figurent pas dans le billet. Il est paru à 13 h TU, à la même heure que « Enforce positive security with Cloudflare Application Profiles », lancement d'un produit maison cosigné par Daniele Molteni, et sous la même étiquette « Birthday Week » : ce test est aussi sorti dans une semaine d'annonces.
Deux appels de modèle, un programme de pilotage en Python, aucune vue sur les règles
Le testeur fait deux appels au modèle par itération. Le premier reçoit la requête de départ, le contexte et un court historique des résultats, puis propose la variation suivante, que le code construit et envoie. Le second reçoit le statut de la réponse, une sélection d'en-têtes et le corps renvoyé, et sert à choisir l'étape d'après. Aucun des deux ne voit les expressions de règles, leurs identifiants, le détail du score d'attaque ni l'identité de la couche qui a bloqué. Le modèle ne tire pas les requêtes lui-même : le code vérifie le nom d'hôte contre une liste d'autorisation, désactive les redirections, applique le plafond d'essais, et aucun des deux appels ne peut déployer une règle. Le tout est écrit en Python, sans s'appuyer sur un outil de test d'intrusion existant.
Quarante-cinq scénarios ont été exécutés, dont quarante-quatre sur six catégories : XSS, injection SQL, injection de commandes, falsification de requêtes côté serveur (SSRF), traversée de répertoire ou inclusion de fichier local, et Log4j. Le quarante-cinquième portait sur l'injection dans les journaux, rapportée à part. Le test utilisait un agent utilisateur autorisé par le client, pour que ses contrôles de trafic automatisé laissent les requêtes atteindre le pare-feu : ces contrôles sont donc restés hors du périmètre mesuré.
L'adresse 169.254.169.254 réécrite jusqu'au point final
La trajectoire publiée porte sur un scénario de SSRF visant le service de métadonnées d'un fournisseur de cloud, dont l'adresse peut exposer des identifiants temporaires. Le pare-feu renvoie d'abord une page de blocage 403 sur l'adresse écrite en clair, 169.254.169.254. Le modèle la rejoue en entier décimal, 2852039166 : bloquée. Puis en octal, 0251.0376.0251.0376, déplacée de la chaîne de requête vers un corps de formulaire : bloquée. À la dix-huitième tentative, il garde la méthode, l'emplacement de l'entrée, le type de contenu et la forme du chemin, et ajoute un point final au nom d'hôte. Le client reçoit une redirection au lieu d'une page de blocage.
Cloudflare borne ce que l'épisode établit : aucune réponse d'origine aboutie, aucun élément indiquant que l'application a récupéré les métadonnées. La colonne « hypothèse » du tableau n'est ni une transcription littérale ni une preuve. Une requête non bloquée a le statut de piste à examiner ; elle n'établit aucun exploit.
558 blocages, 49 pistes, 500 tentatives écartées du décompte
Le tableau de résultats donne quatre nombres : 1 107 tentatives de mutation enregistrées, décrites comme des itérations du modèle sur 45 scénarios actifs ; 558 requêtes bloquées avant d'atteindre l'application ; 49 pistes pertinentes pour le pare-feu, documentées après revue humaine ; un ensemble post-tri de 607, somme des deux précédents. Par différence entre les deux nombres publiés, 500 essais, soit 45 % du total, n'ont rien laissé à compter : requête HTTP inutilisable, cible jamais atteinte, ou charge utile devenue inoffensive.
Cinq contrôles filtraient les requêtes non bloquées avant qu'elles comptent comme pistes : requête valide réellement envoyée, passage sans ambiguïté, charge encore malveillante après mutation, comportement imputable au pare-feu, reproductibilité sans risque. Rapporter 49 à 1 107 reviendrait donc à confondre un reliquat de tri avec un taux de contournement.
48 des 49 pistes relèvent de l'injection de commandes et du SSRF ; Cloudflare décrit une couverture proche du complet sur le XSS, l'inclusion de fichier local, l'injection SQL et Log4j. Le plafond d'essais borne l'exercice. La boucle s'arrête quand les mutations cessent de produire des variations utiles, ou quand ce plafond est atteint : à 45 scénarios et 25 essais au plus, le maximum théorique est de 1 125 tentatives, et les 1 107 enregistrées s'en approchent à 18 près, si la limite de 25 porte sur la même unité que le décompte publié. L'éditeur note que certains scénarios répétaient des idées déjà essayées vers la fin des 25 tentatives.
Un blocage à 30 pour un seuil recommandé à 20
La configuration de la zone est donnée : blocage sur un score d'attaque de 30 ou moins, jeu de règles géré activé en entier, OWASP Core Rule Set en niveau de paranoïa 3. La documentation de Cloudflare, mise à jour le 16 avril 2026, décrit un score de 1 à 99 attribué par apprentissage automatique, 1 pour une requête presque certainement malveillante, 99 pour une requête probablement propre. Le seuil initial qu'elle recommande pour une règle de blocage est de 20 ou moins, et la plage 21-50 peut selon elle inclure des requêtes légitimes signalées à tort. La zone testée bloquait dix points au-dessus de ce point de départ.
Le niveau de paranoïa 3 va dans le même sens : la documentation du CRS le présente comme un niveau de sécurité de banque en ligne accompagné de nombreux faux positifs, que le projet dit accepter et attendre. Ces réglages dessinent une zone durcie, loin d'une installation de série, testée par ailleurs sans ses contrôles de trafic automatisé. Les 558 blocages décrivent une borne haute des signatures et du score pris seuls ; ils renseignent peu sur un site laissé en réglages par défaut, et c'est la limite à garder en tête avant de reprendre ce ratio comme référence.
Trois changements SSRF traçables dans le changelog public
Le travail de correction a contribué à trois changements dans le jeu de règles géré : deux nouvelles détections, « SSRF - Obfuscated Host » et « SSRF - Restricted Protocol », dans la livraison du 21 juillet, plus une amélioration de la règle existante « SSRF - Cloud », que le billet ne date pas dans son texte mais relie à la livraison du 4 août 2026, où le changelog montre cette règle passant de désactivée à blocage. La détection « SSRF - Obfuscated Host » vient directement, écrit Cloudflare, de requêtes qui encodaient des adresses internes sous des formes numériques non standard. La trajectoire publiée montre ce type de réécriture, en décimal puis en octal, mais ces formes y sont bloquées : la requête qui passe est celle au point final, que le billet ne relie à aucune des trois règles.
Le changelog public des règles gérées recense les deux nouvelles détections dans la livraison du 21 juillet 2026, sous des identifiants tronqués (« ...a935ee5d » et « ...215e7d31 »), toutes deux signalées comme de nouvelles détections, avec une action qui passe de la journalisation au blocage. C'est ce qui rend l'exercice vérifiable de l'extérieur. Une asymétrie reste ouverte : les trois changements cités portent tous sur le SSRF, alors que les 48 pistes principales se répartissent entre injection de commandes et SSRF.
Mode journal, pile à jour, puis un test en boîte blanche
Cloudflare ajoute que ses clients n'ont pas besoin de reproduire l'expérience et leur conseille plutôt de faire tourner les règles gérées en mode journal, puis de vérifier que le trafic légitime n'est pas touché avant de passer au blocage. Il rappelle qu'une charge utile qui franchit le pare-feu a encore besoin d'une application vulnérable pour aboutir, et que tenir sa pile logicielle à jour reste l'une des défenses les plus solides.
L'éditeur annonce une suite en boîte blanche, où le modèle connaîtra à la fois les vulnérabilités de l'application et les règles qui la protègent. Le billet du 29 septembre n'en donne pas la date.