Avec l’aide de l’IA Claude Mythos Preview, les chercheurs de Calif sont parvenus à débusquer une faille vieille de 29 ans dans le proxy Squid. Cette faille présente depuis 1997 et baptisée Squidbleed (CVE-2026-47729) permet à un simple utilisateur du proxy de récupérer en clair les requêtes HTTP des autres utilisateurs. Voici ce que l’on sait.

CVE-2026-47729 : une fuite de mémoire

Squid est un proxy web très répandu (y compris parce qu’il est embarqué dans certaines solutions), souvent déployé pour mettre en cache, filtrer ou inspecter le trafic dans des environnements partagés : écoles, entreprises, réseaux Wi-Fi publics. C’est d’ailleurs dans le contexte d’un environnement multi-utilisateurs que la faille Squidbleed devient intéressante pour un attaquant.

Cette vulnérabilité associée à la référence CVE-2026-47729 correspond à une lecture hors limites en mémoire (heap over-read). Ainsi, lorsque le proxy renvoie à l’attaquant des octets situés au-delà de la zone mémoire prévue, ils peuvent appartenir à la requête d’un autre utilisateur. Cette fuite de données liées à la mémoire peut permettre d’accéder à des informations d’autres utilisateurs, dont des identifiants et des sessions.

Le bug ne se loge pas dans le code HTTP, mais dans l’analyseur de listings de répertoires FTP. D’après le rapport publié par Calif.io, l’origine de cette faille de sécurité remonte à un commit de janvier 1997 destiné à gérer les anciens serveurs FTP NetWare, qui inséraient quatre espaces entre l’horodatage et le nom de fichier. En effet, cette vulnérabilité se situe au niveau de l’analyseur de listing de répertoires FTP.

Pour absorber ces espaces, le code saute les blancs avec une boucle reposant sur . Le souci : si une ligne de listing se termine juste après l’horodatage, sans nom de fichier, le pointeur tombe sur le caractère de fin de chaîne (). Cependant, lors de l’exécution, considère ce final comme faisant partie de la chaîne et renvoie un pointeur au lieu de . La boucle ne s’arrête donc jamais et déborde du tampon.

D’après les chercheurs de Calif.io, c’est ce détail que l’IA Claude Mythos aurait relevé lors de son analyse sur le code source de Squid.

“Les dangers liés à l’accès direct à la mémoire en C sont bien connus, mais les subtilités des fonctions de la bibliothèque standard, telles que strchr, passent plus facilement inaperçues. Peu de développeurs auraient deviné que la recherche de « » aboutissait, ce qui pourrait expliquer comment un bug d’une seule ligne a pu échapper à près de 30 ans de révision du code.”, peut-on lire.

La question que l’on peut se poser, c’est : pourquoi des identifiants se retrouvent-ils dans cette mémoire ? Parce que Squid recycle ses tampons de 4 Ko sans les remettre à zéro. Un tampon qui vient de contenir la requête HTTP d’une victime garde l’essentiel de son contenu : la courte ligne FTP n’en écrase que les premiers octets, et la lecture hors limites renvoie le reste.

D’ailleurs, une démonstration de Calif.io montre qu’il est possible de récupérer un en-tête d’un utilisateur utilisant le même proxy vulnérable. Ainsi, il est possible d’usurper l’identité de cet utilisateur sur le service cible lorsque la connexion passe par le proxy.

Un risque réel, mais avec des conditions

Plusieurs conditions limitent fortement la portée de l’attaque. En effet, il y a un ensemble de conditions à respecter pour que l’attaque soit possible :

• L’attaquant doit déjà avoir accès au proxy. Squid décrit Squidbleed comme une attaque menée par un client de confiance, donc un utilisateur ayant accès au proxy (il peut s’agir d’une simple machine connectée à un réseau local).
• Seul le trafic en clair est exposé. Le HTTPS classique transite par un tunnel que Squid ne déchiffre pas. Restent concernés le HTTP en clair et les configurations où Squid termine le pour inspecter le trafic (SSL inspection).
• Le proxy doit pouvoir joindre un serveur FTP contrôlé par l’attaquant sur le port 21. Toutefois, mauvaise nouvelle : le support FTP et ce port figurent dans la configuration par défaut.

À ce stade, aucune exploitation dans la nature n’aurait été rapportée, mais le code d’exploitation est disponible sur GitHub.

Comment se protéger : corriger ou couper le FTP

D’après le calendrier de divulgation de Calif.io, le correctif a été fusionné dans la branche de développement le 19 avril, puis dans la branche v7 le 17 mai, et Squid 7.6 est sorti le 8 juin 2026. Ce patch tiendrait en une ligne : via la présence du terminateur avant l’appel à .

Attention toutefois : selon The Hacker News, il y aurait une incohérence quant à la version exacte qui intègre le correctif de sécurité pour la faille SquidBleed. Du coup, au-delà de vérifier uniquement le numéro de version, vérifiez la présence du correctif dans le fichier . Un point d’autant plus important que les distributions embarquent leurs propres builds. Debian, par exemple, distribue encore Squid 5.7.

Les chercheurs de Calif.io, quant à eux, recommandent de désactiver le FTP. “À titre de mesure de prévention, vous devriez vraiment désactiver le protocole FTP à ce stade, à moins d’en avoir un besoin spécifique et inhabituel. Chrome, et par extension tous les navigateurs basés sur Chromium, ont cessé de prendre en charge le protocole FTP il y a plusieurs années ; par conséquent, la plupart des organisations utilisant Squid enregistrent désormais un trafic FTP légitime quasi nul.”

Ce signalement s’inscrit dans une tendance de fond que nous suivons depuis plusieurs mois : la découverte massive de failles assistée par l’IA. Ici, c’est bien le modèle Claude Mythos Preview qui a aidé les chercheurs. L’occasion de rappeler qu’il avait découvert plus de 10 000 failles de sécurité en un mois. Le même phénomène avait déjà provoqué un véritable raz-de-marée de CVE sur des projets majeurs en 2026.

Pour celles et ceux qui découvrent Squid, IT-Connect propose un rappel des bases avec les serveurs proxy et reverse proxy pour les débutants ainsi qu’un guide pour mettre en place un proxy transparent Squid sur PfSense.