L'API Docker de Crawl4AI : quand un champ de configuration navigateur devient une RCE non authentifiée

De quoi s’agit-il ?

Crawl4AI est un crawler et scraper web open source très répandu, pensé pour les LLM : on lui indique des pages, il pilote un navigateur Chromium sans interface, et il renvoie un texte propre destiné à l’ingestion RAG et à l’outillage d’agents. Une faille critique d’injection d’arguments dans son serveur d’API Docker a été publiée le 6 juillet 2026 (avis GitHub GHSA-r253-r9jw-qg44) et corrigée en version 0.9.0. Le problème : l’API acceptait un champ de configuration navigateur fourni par la requête et transmettait son contenu directement aux arguments de lancement de Chromium. Comme l’API Docker livrée par défaut n’a aucune authentification, une seule requête HTTP vers une instance accessible suffisait à exécuter des commandes arbitraires sur l’hôte — d’où une sévérité maximale, notée 10.0. Cette faille s’inscrit dans la même vague de bugs d’exécution de code à distance notés 10.0 début juillet, qui a aussi touché PraisonAI, Langroid et d’autres, où des frameworks exécutaient des entrées fournies par le modèle ou la requête sans frontière de confiance.

Comment ça fonctionne

Le crawler expose des points d’entrée comme /crawl, /crawl/stream et /crawl/job. Chacun accepte un objet browser_config, dont l’un des membres — extra_args — est censé permettre aux exploitants de passer des options Chromium supplémentaires. Avant le correctif, tout ce qu’un appelant plaçait dans cette liste alimentait la commande de lancement effective du navigateur. Chromium possède plusieurs options qui redéfinissent la manière dont il crée ses propres processus enfants ; lorsqu’on lui demande de lancer un utilitaire via un binaire choisi par l’attaquant et d’ignorer son amorçage habituel de mise en bac à sable, il exécute cette commande directement, sous l’identité de l’utilisateur du conteneur. Un correctif partiel en v0.8.9 avait ajouté une liste de blocage, mais elle ne couvrait que les options liées au proxy et au DNS et laissait accessibles les options de lancement de processus. Aucun payload n’est reproduit ici ; c’est le mécanisme qui compte. La faille relève de l’injection d’arguments (CWE-88) menant à une injection de code (CWE-94), et comme la portée CVSS est « modifiée » (Changed), le rayon d’impact peut dépasser le conteneur du crawler lui-même.

Pourquoi c’est important

Par conception, les crawlers se trouvent à la lisière non fiable d’un pipeline LLM — leur rôle même est de manipuler du contenu que personne ne contrôle. Une API de crawler non authentifiée et accessible par le réseau devient dès lors une cible particulièrement attrayante : elle tourne souvent avec un accès réseau sortant, des identifiants cloud et une file d’URL à récupérer, exactement la position recherchée par un attaquant pour du vol de données, du déplacement latéral ou du minage. La posture par défaut aggravait le tout. La distribution Docker exposait l’API sans authentification ; les exploitants qui rendaient le port par défaut (11235) accessible sur un réseau partagé ou sur Internet étaient donc exploitables sans aucun accès préalable. C’est un schéma récurrent dans l’infrastructure IA : des valeurs par défaut commodes qui présument un réseau de confiance, enroulées autour d’un composant qui traite des entrées hostiles. Des sociétés de sécurité ont indiqué suivre des tentatives d’exploitation peu après la divulgation.

Défenses

Passez à Crawl4AI 0.9.0 ou une version ultérieure. Dans cette version, le champ browser_config.extra_args fourni par la requête est rejeté à la frontière réseau par un HTTP 400, l’authentification est activée par défaut, et le serveur écoute sur la boucle locale (127.0.0.1) tant qu’aucun jeton n’est défini via CRAWL4AI_API_TOKEN. Si vous ne pouvez pas corriger immédiatement, n’exposez pas le port de l’API à des réseaux non fiables : restreignez-le par des règles de pare-feu ou des ACL réseau, et placez tout accès distant derrière un reverse proxy à terminaison TLS qui impose l’authentification. Au-delà de ce bug précis, les leçons d’architecture valent pour tout outil qui lance des sous-processus pour le compte d’appelants : ne laissez jamais des données contrôlées par la requête atteindre la ligne de commande ou les options de lancement d’un processus ; si des options doivent être configurables, autorisez explicitement (allowlist) les seules options permises plutôt que d’interdire les mauvaises connues ; exécutez les charges de crawler et de navigateur sous un utilisateur non privilégié, dans un bac à sable segmenté du réseau et sans identifiants cloud ambiants ; et traitez chaque objet de configuration de crawler ou d’agent comme une entrée non fiable, validée côté serveur. La surveillance peut aider dans l’intervalle : inspectez le trafic API à la recherche de valeurs extra_args portant des options de lancement de processus Chromium, et examinez les lignes de commande chromium en cours pour repérer des arguments de lanceur inattendus.

Statut

Élément	Détail
Composant	Serveur d’API Docker de Crawl4AI (crawler web pour LLM)
Nature	Injection d’arguments dans browser_config.extra_args → exécution de commande
Affectés	Toutes les versions antérieures à 0.9.0
Corrigé dans	0.9.0 (rejet du champ, authentification par défaut, écoute sur la boucle locale)
Sévérité	CVSS 10.0 — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Divulgation	6 juillet 2026 (avis GHSA-r253-r9jw-qg44)
Référence	CVE-2026-57572 ; correctifs Crawl4AI liés de juillet 2026 : CVE-2026-57571 (traversée de chemin → écriture de fichier), CVE-2026-53753 (évasion de bac à sable sur champ calculé)
Exploitation	Tentatives signalées peu après la divulgation