Ce que Squidbleed fait réellement fuiter
Squidbleed, référencée CVE-2026-47729, est une sur-lecture de tampon dans le tas, au sein de l'analyseur des listes de répertoires FTP de Squid, l'un des proxys web les plus déployés d'internet. Quand Squid affiche une liste FTP à laquelle manque le nom de fichier, une boucle qui saute les espaces avance d'un pas de trop et lit la mémoire au-delà du tampon prévu. Comme Squid réutilise la mémoire libérée d'une requête à l'autre, ces octets égarés sont souvent des fragments du trafic d'autres utilisateurs: des requêtes HTTP en clair portant mots de passe, cookies, jetons de session et clés d'API.
L'exposition est plus étroite que celle de Heartbleed, mais bien réelle. L'attaquant doit être un utilisateur autorisé d'un proxy partagé et contrôler un serveur FTP que le proxy peut atteindre sur le port 21, ce qui oriente le risque vers les internes et vers toute installation où le proxy termine le TLS. Le trafic HTTPS relayé en tunnel opaque reste scellé, l'enjeu porte donc sur les flux HTTP en clair et sur les flux terminés en TLS qui traversent encore chaque jour les proxys d'entreprise.
Une ligne, vingt-neuf ans, et l'IA qui l'a trouvée
La cause est presque banale. Le code appelait strchr sur une chaîne qui pouvait être vide, et la norme C dit que strchr traite l'octet nul final comme faisant partie de la chaîne, si bien que le contrôle censé s'arrêter à la fin de l'entrée a continué en silence au-delà. Le motif fautif remonte à un commit de Squid de janvier 1997, ce qui veut dire que la faille a été livrée dans les configurations par défaut, le port 21 figure dans la liste par défaut Safe_ports, pendant vingt-neuf ans et à travers d'innombrables versions, réécritures et revues de sécurité. Le correctif tient à une seule condition ajoutée, un contrôle de nul avant strchr, ou bien à couper le FTP entièrement, ce que Chromium a fait il y a des années et sur quoi presque aucun réseau ne s'appuie plus.
Le détail qui devrait retenir l'attention d'un opérateur, c'est qui l'a trouvée. Deux chercheurs l'ont signalée de façon indépendante, Pavel Kohout d'Aisle Research en mars 2026 et Lam Jun Rong de Calif.io en avril, les mainteneurs ont fusionné le correctif en quelques jours et l'avis public a suivi le 23 juin. Mais la découverte initiale est venue d'un agent d'IA chargé de parcourir la machine à états FTP, et non d'un nouvel audit humain. L'hypothèse confortable selon laquelle un code ancien et très revu serait sûr du seul fait de son âge vient d'échouer à un test très public, et l'outil qui l'a mise à mal est désormais bon marché et à la portée de tous.
Ce qu'un opérateur devrait faire cette semaine
Le geste concret est modeste: recensez chaque instance de Squid que vous exploitez, mettez-la à jour vers une version corrigée, et si vous n'avez pas délibérément besoin du proxy FTP, désactivez-le et retirez le port 21 de Safe_ports. Priorisez tout proxy qui termine le TLS ou transporte du HTTP en clair pour plusieurs utilisateurs, car c'est là que les identifiants de collègues peuvent fuir les uns vers les autres. Au Royaume-Uni, le National Cyber Security Centre traite l'exposition d'identifiants sur une infrastructure partagée comme une catégorie d'incident à déclarer, et dans toute l'UE le régime NIS2 place la responsabilité d'une faille connue et non corrigée sur les dirigeants nommément désignés, et pas seulement sur l'équipe de sécurité.
Le mouvement de fond consiste à cesser de traiter l'âge d'une dépendance comme la preuve de sa sûreté. Une faille d'une seule ligne s'est cachée vingt-neuf ans dans un logiciel auquel des milliers d'organisations se fiaient justement parce qu'il était mûr, et un relecteur d'IA l'a trouvée en une seule passe. Attendez-vous à voir remonter d'autres failles dormantes de ce genre dans vos composants les plus anciens et les plus fiables, et budgétez un flux régulier de petits correctifs sans éclat plutôt qu'un seul correctif spectaculaire.
À lire ensuite: Un audit IA n'a pas vu la faille Linux qui donne root | Ce maliciel efface d'abord vos sauvegardes
