SquidBleed CVE-2026-47729 : le proxy Squid fuite vos mots de passe depuis 1997
29 ans de bug silencieux, un PoC public, et vos credentials HTTP à portée de tout utilisateur du proxy
Analyse terrain 2LKATIME
Nos auditeurs OSCP ont analyse SquidBleed des sa divulgation le 24 juin 2026. Cet article détaille le vecteur d'attaque, les environnements exposés, et les actions concrètes a mener en priorité pour les PME utilisant Squid comme proxy d'entreprise.
Le risque métier pour le dirigeant
Imaginez que votre proxy d'entreprise - le "portail" par lequel tous vos salaries accedent au web - permette a n'importe quel employe malveillant de lire les mots de passe et sessions des autres en temps réel. C'est exactement ce que permet SquidBleed. Pas besoin d'etre admin, pas besoin d'etre hacker : juste un utilisateur ordinaire du reseau. Dans un contexte de menace interne croissante, c'est une faille critique a traiter immédiatement.
En janvier 1997, un developpeur de Squid introduisait un bug d'une seule ligne dans la gestion des listings FTP. Vingt-neuf ans, des dizaines de versions, et des milliers d'audits de sécurité plus tard, ce bug existe toujours dans les installations non patchees de l'un des proxys web les plus déployés au monde. Baptise SquidBleed (CVE-2026-47729), il permet a un utilisateur simplement autorisé d'un proxy partage de lire les fragments de mémoire contenant les requêtes HTTP de ses voisins : mots de passe, cookies, tokens d'API.
Ce qui rend SquidBleed particulierement dangereux en 2026 c'est la combinaison de trois facteurs : un PoC public fonctionnel disponible sur GitHub, des preconditions d'exploitation minimales (etre utilisateur du proxy et controler un serveur FTP), et le fait que Squid est déployé massivement dans les ecoles, collectivites, PME et reseaux Wi-Fi partages - exactement les environnements multi-utilisateurs ou la faille est exploitable. Voici ce que vous devez savoir et faire.
Écouter cet article en podcast
L'IA déterre SquidBleed après 29 ans • 10 min 37 sec • 2LKATIME
1. SquidBleed en chiffres
Le nom SquidBleed est une référence directe a HeartBleed (2014), l'autre faille emblematique de fuite mémoire. La comparaison est pertinente : même categorie (heap over-read), même impact (fuite de données sensibles en clair), même surprise de trouver quelque chose d'aussi critique dans un logiciel aussi audite. La difference : SquidBleed n'est exploitable que par un utilisateur interne du proxy, pas depuis l'internet.
29 ans
Bug présent depuis 1997
CWE-125
Out-of-Bounds Read
PoC
Exploit public disponible
7.7
Squid corrige (a vérifier)
Squid est déployé dans des dizaines de milliers d'entreprises françaises, principalement comme proxy de filtrage HTTP, passerelle de cache, ou proxy transparent dans les reseaux internes. Sa popularite est precisement ce qui rend SquidBleed significatif : une faille dans un logiciel marginal serait passee inapercue, mais Squid est partout.
La découverte de SquidBleed par les chercheurs de Calif.io illustre une tendance majeure de 2026 : l'utilisation de l'IA pour auditer des codebases C/C++ matures et trouver des bugs mémoire que les humains ont rates pendant des decennies. Voir aussi notre analyse du pentest IA sur les agents LLM.
2. Comment fonctionne l'attaque - schéma
Le mécanisme de SquidBleed exploite la passerelle FTP de Squid. Lorsque Squid recoit une requête pour une URL FTP, il se connecte au serveur FTP distant et parse le listing de repertoire. Un bug dans ce parseur - une vérification manquante du terminateur NUL avant les appels strchr - permet de lire au-dela du buffer alloue. Sur un proxy actif avec de nombreux utilisateurs, ce buffer adjacent contient les requêtes HTTP en cours des autres utilisateurs.
Schéma 1 - Flow d'exploitation de CVE-2026-47729 SquidBleed
Le flux d'exploitation se deroule en quatre étapes. L'attaquant (un simple utilisateur du proxy) envoie une requête pour une URL FTP pointant vers son serveur malveillant. Squid se connecte au serveur FTP et recoit un listing de repertoire intentionnellement tronqué, sans terminateur NUL. Le parseur FTP de Squid lit au-dela du buffer alloue et ingere de la mémoire adjacent du heap, qui contient les requêtes HTTP d'autres utilisateurs en cours de traitement. Ces données fuites sont renvoyees a l'attaquant dans la réponse rendue par Squid.
Le PoC public (GitHub 0xBlackash) automatise ce processus : il monte un mini-serveur FTP qui retourne systématiquement des listings tronqués, et reconstruit les credentials a partir des fragments de mémoire collectes sur de multiples requêtes.
3. Ce qui est exposé vs ce qui est protégé
La bonne nouvelle : le trafic HTTPS standard n'est pas exposé par SquidBleed. Le trafic HTTPS transite via un tunnel CONNECT opaque - Squid agit comme un simple relais TCP et ne voit pas le contenu. La mauvaise nouvelle : beaucoup de trafic d'entreprise transite encore en HTTP clair, et certaines configurations Squid brisent deliberement TLS pour l'inspection.
Schéma 2 - Trafic exposé vs protégé par SquidBleed
Le cas le plus dangereux est la configuration SSL Bump, ou Squid termine le TLS cote client pour inspecter le contenu (filtrage antivirus, DLP). Dans ce cas, même le trafic HTTPS passe par le heap de Squid et devient potentiellement lisible via SquidBleed. Si votre proxy inspecte le HTTPS, l'impact est maximal.
4. 29 ans de bug - la timeline
Ce qui stupefie les chercheurs, c'est la longevite du bug. SquidBleed n'est pas une regression recente introduite par un nouveau developpeur : il date du commit initial de la passerelle FTP en janvier 1997. Des dizaines de release managers, des centaines de commits de sécurité, et plusieurs audits formels ne l'ont pas détecté. C'est precisement l'outil d'analyse assiste par IA de Calif.io qui l'a finalement remonte en 2026.
Schéma 3 - Timeline de CVE-2026-47729 de 1997 a la divulgation 2026
Un detail important sur le fix : la version corrigee est annoncee en Squid 7.7, mais les mainteneurs ont d'abord indique 7.6 avant de se corriger. Les distributions Linux (Debian, Ubuntu, RHEL) packagent leurs propres versions avec backports. Ne vous fiez pas au numero de version seul : vérifiez la presence du guard NUL dans FtpGateway.cc de votre installation.
Piège additionnel : Squid 7.6 contenait bien un correctif de sécurité, mais pour une faille differente (CVE-2026-50012, heap buffer overflow dans cache_digest). Si vous avez mis a jour vers 7.6 en pensant corriger SquidBleed, vous etes peut-etre encore vulnérables.
5. Actions immédiates pour les PME
La priorité est d'eliminer le vecteur d'attaque, pas d'attendre le patch parfait. Voici les actions dans l'ordre de priorité, inspirees des recommandations de Calif.io et des chercheurs qui ont analyse le CVE.
Désactiver FTP dans Squid (priorité absolue)
Sauf besoin spécifique et documente, FTP via Squid est inutile dans 99% des entreprises. C'est la correction la plus rapide et la plus sure.
# Dans squid.conf :
acl FTP proto FTP
http_access deny FTP
Bloquer le port 21 sortant depuis le proxy
En complement de la règle Squid, bloquer au niveau pare-feu les connexions sortantes TCP:21 depuis l'IP du proxy. Cela empeche Squid d'atteindre un serveur FTP externe malveillant même si la règle Squid est contournee.
Mettre a jour et vérifier le fix dans le code source
Mettre a jour vers Squid 7.7 via votre gestionnaire de paquets, puis vérifier manuellement : grep -n "NUL\|null\|terminator" src/clients/FtpGateway.cc. Le guard corrige doit etre présent avant les appels strchr.
Rotation des secrets si le proxy etait actif
Si votre Squid etait en production avec FTP actif sur plusieurs mois, considerez les credentials et tokens qui ont transite en HTTP comme potentiellement compromis. Changez les mots de passe des applications critiques, invalidez les sessions actives et les tokens d'API.
Surveiller les logs proxy pour des tentatives
Rechercher dans les logs Squid des requêtes repetees vers des serveurs FTP inhabituels ou inconnus. Un attaquant qui exploite SquidBleed va generer de nombreuses requêtes FTP vers le même serveur.
6. Enjeux RGPD, NIS2 et responsabilite
SquidBleed n'est pas qu'un problème technique : c'est un risque juridique direct pour les entreprises françaises. Si votre proxy Squid est exploite et que des données personnelles de clients ou d'employes fuient via ce vecteur, vous etes en situation de violation de données au sens de l'article 33 du RGPD - avec obligation de notification a la CNIL dans les 72 heures.
| Cadre | Obligation | Risque si non respecte |
|---|---|---|
| RGPD Art. 32 | Mesures techniques appropriees (patch Squid) | Jusqu'a 4% du CA mondial |
| RGPD Art. 33 | Notification CNIL sous 72h si fuite avered | Sanction + image |
| NIS2 Art. 21 | Gestion de la vulnérabilité et patch management | 10M EUR ou 2% du CA |
| AI Act | Sécurité de l'infrastructure supportant l'IA | Interdiction de déploiement |
NIS2, transposee en droit français depuis octobre 2024, impose aux entites essentielles et importantes un patch management structure avec des delais de remediation documented. Une faille publiquement connue comme SquidBleed, non traitee 30 jours après divulgation, constitue un manquement caracterise. Les PME sous-traitantes de grandes entreprises sont directement concernees via la chaine de responsabilite. Pour vos besoins en conformité en region, nos équipes interviennent depuis Lyon et Lille notamment.
7. Comment 2LKATIME accompagne les PME face aux CVE critiques
Face a SquidBleed comme face aux autres CVE critiques, la difficulte des PME n'est pas de comprendre la faille - c'est de savoir si elles sont vraiment exposées, et de le corriger sans casser la production. C'est exactement ce que nos auditeurs OSCP font en intervention.
Notre intervention sur CVE actives
- - Audit de configuration Squid et identification de l'exposition réelle
- - Test d'exploitation en environnement isole pour confirmer le risque
- - Patch management et vérification du fix dans FtpGateway.cc
- - Revue des logs pour detecter une exploitation anterieure
- - Rapport de remediation pour la CNIL si nécessaire
Notre approche proactive
- - Veille CVE continue sur votre stack technique
- - Pentest infrastructure reseau et proxy
- - Audit NIS2 et RGPD de votre posture de sécurité
- - Formation des équipes IT sur le patch management
- - Dashboard de suivi des vulnérabilités ouvertes
Nos auditeurs certifies OSCP, OSEP et OSWE interviennent depuis Paris et Bordeaux sur ce type de mission en urgence. Voir aussi notre article sur la sécurité externalisee pour les PME et notre guide sur les CVE heap overflow Nginx.
FAQ - SquidBleed CVE-2026-47729
Qu'est-ce que SquidBleed exactement ?
SquidBleed est un heap buffer over-read dans la passerelle FTP du proxy Squid (CVE-2026-47729). Il permet a un utilisateur autorisé du proxy de lire des fragments de mémoire adjacente contenant les requêtes HTTP des autres utilisateurs en cours de traitement - mots de passe, cookies, tokens de session.
Mon HTTPS est-il vulnérable ?
Le trafic HTTPS standard via tunnel CONNECT n'est pas exposé - Squid ne voit pas le contenu. En revanche, si vous utilisez SSL Bump (inspection TLS), le trafic est déchiffre par Squid et passe par le heap, le rendant potentiellement visible par SquidBleed.
Comment savoir si mon Squid est vulnérable ?
Verifiez votre version (squid -v), mais ne vous fiez pas qu'au numero. Verifiez manuellement la presence du guard NUL dans FtpGateway.cc de votre installation. Les distributions comme Debian peuvent embarquer des backports qui modifient la correspondance version/fix.
Est-ce que SquidBleed est exploite en ce moment ?
Aucune exploitation in-the-wild confirmee au 26 juin 2026. Cependant, un PoC public fonctionnel est disponible sur GitHub depuis la divulgation du 24 juin. Les preconditions sont faibles et le vecteur attrayant : la fenetre de risque sans patch est courte.
Quelles données doivent etre changees après exposition ?
Si votre proxy Squid etait actif avec FTP en production, traitez comme potentiellement compromis : tous les mots de passe en Basic Auth HTTP, tous les cookies de session, tous les tokens d'API transmis en HTTP clair. Privilegiez la rotation des accès aux outils métier critiques (ERP, CRM, outils RH).
Votre proxy Squid est-il exposé a SquidBleed ?
Ne laissez pas un bug vieux de 29 ans compromettre les credentials de vos équipes. Nos auditeurs OSCP vérifient votre configuration Squid, testent l'exposition réelle et déploient le correctif en toute sécurité. Intervention possible sous 48h.