L'API Docker de Crawl4AI : des champs de requête qui exfiltrent vos clés LLM

De quoi s’agit-il ?

Crawl4AI est un crawler open source très répandu qui transforme des pages web en texte prêt pour les LLM, souvent déployé comme « serveur API » Docker en amont des pipelines de RAG et d’agents. Une vulnérabilité divulguée en juillet 2026 (advisory publié le 12 juillet, mis à jour le 14 juillet) a montré que ce serveur laissait une requête ordinaire contrôler deux choses qu’elle n’aurait jamais dû maîtriser : la destination d’un appel à l’API LLM et la variable d’environnement serveur depuis laquelle un jeton est résolu. Ce sont deux leviers pour extraire directement des secrets de l’hôte.

Cette divulgation compte parce que le serveur API Docker s’exécute sans authentification par défaut, et que les points d’accès concernés (/md, /llm et l’asynchrone /llm/job) sont précisément les routes qui résument une page ou exécutent un LLM sur le contenu crawlé. Un client distant sans identifiants pouvait donc atteindre ces leviers directement. La faille est classée de gravité élevée (CVSS 8.2) et s’inscrit dans une série plus large de problèmes de falsification de requête survenus sur la même surface entre juin et juillet 2026. Ceci est une analyse défensive d’advisories publiés — aucun exploit fonctionnel n’est fourni.

Comment ça marche

Le défaut central est une frontière de confiance jamais tracée. Le serveur acceptait deux champs influencés par l’attaquant et les utilisait sans validation :

• Un champ base_url qui décide la destination de l’appel LLM sortant. Pointez-le vers un point d’accès contrôlé par l’attaquant et le serveur envoie docilement la requête — y compris le jeton API qu’il y attache — vers cette adresse.
• Un champ api_token qui accepte une forme env:NOM_DE_VARIABLE, indiquant au serveur de résoudre le jeton depuis l’une de ses propres variables d’environnement. Le nom de variable étant fourni par l’appelant, une requête pouvait désigner n’importe quelle variable de l’environnement du processus, pas seulement la clé LLM prévue.

Combinez les deux et le résultat est une exfiltration directe : nommez un secret avec env:, dirigez base_url vers un serveur d’écoute que vous contrôlez, et le serveur vous remet la valeur résolue. Les advisories notent que cela dépasse les clés API fournisseurs et atteint des secrets serveur comme la SECRET_KEY JWT servant à l’authentification — qui, une fois fuitée, permet de forger des jetons valides et de contourner entièrement l’authentification.

# Forme conceptuelle uniquement — pas une requête fonctionnelle
request --> base_url = <point d'accès attaquant>     # redirige l'appel LLM sortant
request --> api_token = env:<variable serveur>        # résout un secret hôte arbitraire
server  --> envoie le secret résolu au point d'accès attaquant

Le même serveur portait aussi une falsification de requête côté serveur (SSRF) classique sur ses routes de crawl. Un problème connexe laissait des appelants non authentifiés atteindre des adresses internes, privées et de lien-local — dont les points d’accès aux métadonnées d’instance cloud — en fournissant une telle URL comme cible de crawl ; la route de crawl en streaming, en particulier, sautait le contrôle de destination appliqué ailleurs. Une variante distincte contournait la liste de blocage d’adresses internes à l’aide d’adresses IPv4 mappées en IPv6. Des bugs différents, une même cause racine : une donnée contrôlée par la requête atteint une opération sensible sans validation côté serveur.

Pourquoi c’est important

L’outillage LLM concentre exactement les secrets convoités par les attaquants. Une machine « crawler-pour-LLM » détient typiquement des clés API fournisseurs (OpenAI, Anthropic et d’autres), des identifiants cloud et son propre secret de signature ; elle est souvent déployée à la hâte, joignable depuis Internet et sans authentification parce qu’« elle ne fait que récupérer des pages web ». Cette combinaison — pas d’auth par défaut, secrets de grande valeur dans l’environnement, et champs de requête qui adressent à la fois la destination réseau et les variables de l’hôte — est ce qui transforme un point d’accès de résumé en primitive d’exfiltration de credentials. Des clés fournisseurs fuitées, c’est de l’inférence frauduleuse facturée à la victime ; un secret de signature fuité, c’est un contournement d’authentification ; une SSRF vers les métadonnées, c’est du vol d’identifiants cloud et du déplacement latéral. Comme l’exploitation ne nécessite aucun privilège ni interaction utilisateur, ce sont des cibles de choix pour le balayage automatisé et opportuniste.

Défenses

• Corrigez et restez à jour. Le problème d’exfiltration de credentials est corrigé dans Crawl4AI 0.8.8 ; la brèche de falsification de requête sur la route de streaming est colmatée en 0.9.0, qui active aussi l’authentification de l’API par défaut. Suivez les advisories de sécurité de l’éditeur, car ces problèmes sont arrivés en série, pas en correctif unique.
• N’exposez jamais le serveur API Docker sans authentification. Liez-le à la boucle locale, placez-le derrière un reverse proxy qui impose l’authentification, et définissez un jeton d’API. Considérez « il ne fait que crawler » comme faux.
• Segmentez le réseau et contrôlez le trafic sortant. Bloquez les connexions sortantes vers les plages RFC-1918, lien-local (169.254.0.0/16) et boucle locale, afin qu’un appel LLM redirigé ou une SSRF ne puisse atteindre ni les services de métadonnées ni les hôtes internes.
• Refusez l’indirection contrôlée par la requête. La configuration applicative ne doit pas laisser un appelant choisir une URL de base sortante ni désigner une variable d’environnement à lire. Résolvez les secrets côté serveur depuis une configuration fixe, et mettez en liste blanche tout point d’accès que le service a le droit d’appeler.
• Minimisez les secrets ambiants. Exécutez les charges de crawl sous un utilisateur non privilégié sans identifiants d’instance cloud à portée, et restreignez la portée des clés API pour qu’une fuite ait un faible rayon d’impact.
• Renouvelez au moindre doute. Si un serveur vulnérable a été un jour joignable depuis Internet, renouvelez les clés fournisseurs et le secret de signature JWT qu’il détenait — une atteinte à la confidentialité y est silencieuse.

Statut

Élément	Détail
Affecté	Serveur API Docker de Crawl4AI, versions antérieures aux correctifs
Classe	Exfiltration de credentials via base_url contrôlé + résolution de jeton env: ; plus SSRF connexe sur les routes de crawl
Faiblesse	CWE-200 / CWE-522 (exposition de secrets), CWE-918 (SSRF)
Faille d’exfiltration de credentials	CVE-2026-56259 — CVSS 8.2 (élevé) ; corrigée en 0.8.8
SSRF (route streaming)	CVE-2026-57573 — CVSS 8.6 (élevé) ; corrigée en 0.9.0
SSRF (contournement de blocklist)	CVE-2026-56266 — CVSS 9.2 (élevé) ; corrigée en 0.8.7
Posture par défaut	Serveur API Docker non authentifié par défaut avant 0.9.0

Dates clés : advisory d’exfiltration de credentials publié le 12 juillet 2026 (mis à jour le 14 juillet 2026) ; falsification de requête sur la route streaming signalée le 6 juillet 2026 ; advisory de contournement de blocklist daté du 22 juin 2026. Toutes les mesures ci-dessus sont architecturales — mettez à jour, authentifiez, segmentez, et supprimez l’indirection contrôlée par la requête.