Introduction
Trente ans. C'est le temps qu'il a fallu pour qu'une ligne de code défectueuse, glissée dans Squid en janvier 1997, soit enfin repérée. La vulnérabilité baptisée Squidbleed — CVE-2026-47729 — touche toutes les versions de ce serveur proxy-cache open source dans sa configuration par défaut. Elle permet à un attaquant de faire fuiter des fragments de mémoire heap contenant des requêtes HTTP en clair, des en-têtes d'autorisation, des cookies de session ou des clés API.
Squid, un nœud central et souvent oublié
Squid est omniprésent dans les infrastructures réseau, qu'on l'y ait délibérément placé ou qu'il y soit arrivé sans qu'on y prête attention. FAI, établissements scolaires, grandes entreprises et organisations gouvernementales l'utilisent pour filtrer le trafic web, accélérer les accès par cache ou contrôler les sorties réseau. Ce rôle de pivot rend la faille particulièrement critique : une fuite mémoire à ce niveau n'affecte pas un seul utilisateur, mais potentiellement l'ensemble des requêtes transitant par un réseau.
Le fait que le code vulnérable date de janvier 1997 amplifie l'inquiétude. Trois décennies d'audits, de revues de code et de mises à jour majeures l'ont laissé intact, traversant des générations d'ingénieurs et de configurations sans jamais déclencher d'alerte.
La mécanique d'une fuite silencieuse
La vulnérabilité réside dans l'analyseur de listes FTP de Squid, un composant hérité conçu pour gérer des serveurs NetWare de l'époque. Le problème tient à une subtilité du standard C : la fonction strchr, lorsqu'elle recherche un caractère nul, retourne une valeur non nulle conformément à la norme C11 — un comportement contre-intuitif qui a échappé aux auditeurs humains pendant trente ans.
En pratique, si un serveur FTP malveillant ne fournit pas de nom de fichier dans sa réponse, un pointeur interne de Squid dépasse le terminateur null. La boucle de lecture ne s'arrête plus et traverse la mémoire heap, renvoyant au client des fragments bruts qui peuvent contenir des requêtes d'autres utilisateurs, des identifiants ou des tokens d'authentification. Les buffers HTTP de 4 Ko utilisés par Squid ne sont jamais réinitialisés entre les requêtes lors du recyclage mémoire : une fenêtre discrète mais exploitable pour exfiltrer des données sans déclencher la moindre alerte.
Un exploit accessible dans la configuration par défaut
Ce qui aggrave la situation : aucune configuration non standard n'est requise. Le support FTP est activé par défaut dans Squid, et le port 21 est inclus dans la liste des ports autorisés (Safe_ports ACL). Un attaquant n'a besoin que de contrôler un serveur FTP accessible depuis le proxy cible — une condition atteignable dans de nombreux environnements d'entreprise où les règles de filtrage sortant restent permissives.
La portée réelle reste toutefois conditionnée : seul le trafic HTTP non chiffré est exposé. Le trafic HTTPS transite via des tunnels CONNECT opaques que Squid ne déchiffre pas nativement. Exception notable : les déploiements qui pratiquent l'inspection TLS, où la surface d'attaque devient significativement plus large.
Appliquer le correctif sans attendre
Le correctif est disponible dans Squid 7.6, publié le 8 juin 2026. Il tient en une seule vérification : contrôler la présence du terminateur null avant d'appeler strchr. Pour les équipes qui ne peuvent pas migrer immédiatement, la désactivation du support FTP dans la configuration de Squid supprime entièrement la surface d'attaque. Les navigateurs modernes ont abandonné le protocole FTP depuis plusieurs années ; dans la plupart des environnements d'entreprise actuels, ce protocole n'a plus de raison d'être activé sur le proxy.
L'incident illustre un angle mort récurrent dans la gestion de la sécurité réseau : les composants jugés stables parce qu'ils fonctionnent sont précisément ceux où les failles persistent le plus longtemps. Proxys, relais DNS et équipements de filtrage méritent les mêmes cycles de revue que les systèmes directement exposés à Internet.