Ce que Squidbleed fait réellement fuiter
Squidbleed, référencée CVE-2026-47729, est une sur-lecture de tampon dans 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 entre les requêtes, 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 réelle. Un 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 ce sont donc les flux HTTP en clair et ceux 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, à travers d'innombrables versions, réécritures et revues de sécurité. Le correctif est une seule condition ajoutée, un contrôle de nul avant strchr, ou couper le FTP entièrement, que Chromium a abandonné il y a des années et sur lequel 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, et les mainteneurs ont fusionné le correctif en quelques jours, l'avis public suivant le 23 juin. Mais la découverte initiale est venue d'un agent d'IA chargé de parcourir la machine à états FTP, pas d'un nouvel audit humain. L'hypothèse confortable selon laquelle un code ancien et très revu est sûr du seul fait de son âge vient d'échouer à un test très public, et l'outil qui l'a brisée est désormais bon marché et largement disponible.
Ce qu'un opérateur devrait faire cette semaine
Le geste concret est modeste: recensez chaque instance de Squid que vous exploitez, corrigez-la vers une version publié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 de l'HTTP en clair pour plusieurs utilisateurs, car c'est là que les identifiants de collègues peuvent fuir les uns vers les autres. En France l'ANSSI traite l'exposition d'identifiants sur une infrastructure partagée comme un incident à déclarer, et dans toute l'UE la transposition de NIS2 place la responsabilité d'une faille connue et non corrigée sur la direction désignée, pas seulement sur l'équipe de sécurité.
Le mouvement plus large consiste à cesser de traiter l'âge d'une dépendance comme la preuve de sa sûreté. Une faille d'une 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 à ce que d'autres de ces failles dormantes remontent 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 spectaculaire.
À lire ensuite: Deux failles Cursor notées 9.8 livrent la machine du développeur aux attaquants | Une seule faille chez un fournisseur a causé la moitié des victimes de rançongiciel en Europe
