Squidbleed, référencée sous CVE-2026-47729, est une vulnérabilité de lecture hors limites dans le FTP gateway de Squid. Elle ne permet pas d’exécuter du code, mais elle peut exposer des données d’autres transactions mémoire, notamment des en-têtes HTTP comme Authorization ou des cookies de session.

Le sujet est intéressant pour les équipes infra parce qu’il combine plusieurs réalités : un bug très ancien, un impact conditionnel mais sérieux, et un risque de faux sentiment de sécurité si l’on se contente de lire “pas d’exploitation massive observée”. Dans un environnement multi-utilisateurs — entreprise, école, captive portal, proxy mutualisé — le niveau de risque mérite une vraie qualification.

Qu’est-ce que Squidbleed et pourquoi cette Squid CVE compte vraiment ?

Squid supporte historiquement plusieurs protocoles, dont HTTP et FTP. La faille CVE-2026-47729 se situe dans la logique qui parse certaines réponses de listing FTP. Un cas limite dans le traitement d’espaces et du caractère nul entraîne un dépassement de lecture hors du tampon attendu.

Dit autrement : dans une situation précise, Squid continue à lire de la mémoire après la fin normale de la chaîne. Comme les buffers recyclés ne sont pas forcément remis à zéro, l’attaquant peut récupérer des octets qui appartiennent à une autre transaction. Le résultat n’est pas un crash immédiat spectaculaire, mais une fuite discrète de données potentiellement sensibles.

Le correctif upstream est minuscule mais révélateur : il ajoute simplement un contrôle *copyFrom avant l’appel à strchr(). C’est typiquement le genre de bug C ancien, plausible en relecture, facile à laisser vivre longtemps, et dont l’impact dépend énormément du contexte d’exploitation.

Versions touchées : que sait-on vraiment ?

Les travaux publiés autour de Squidbleed présentent la faille comme héritée d’un code introduit à la fin des années 1990. En pratique, il faut considérer que les versions historiques de Squid sont concernées tant qu’elles n’ont pas reçu le backport du correctif.

Côté upstream, la correction a été publiée avec le correctif référencé par le commit 865a131c7d557e68c965043d98c2eccae26deef8. Côté distributions, la situation dépend du packaging et du backport.

Debian

Au moment de la vérification, le tracker Debian indiquait :

• bullseye : vulnérable
• bookworm : vulnérable
• trixie : corrigé en 6.13-2+deb13u2
• sid/forky : corrigé en 7.6-1

Pour une infra Debian 11 ou 12, la bonne posture est de vérifier immédiatement la disponibilité d’un backport de sécurité et, en attendant, d’envisager la mitigation côté FTP.

Ubuntu

• 22.04 LTS jammy : corrigé en 5.9-0ubuntu0.22.04.7
• 24.04 LTS noble : corrigé en 6.14-0ubuntu0.24.04.4
• 25.10 questing : corrigé en 6.14-0ubuntu0.25.10.4
• 26.04 resolute : corrigé en 7.2-2ubuntu2.2
• 20.04 focal : état à évaluer

Ubuntu a donc bougé vite sur les branches maintenues courantes. Si ton parc est en LTS, la correction doit passer par le canal normal des updates sécurité.

RHEL, AlmaLinux, Rocky Linux

Au moment de ce pointage, l’information Red Hat n’était pas encore aussi claire et directe que chez Ubuntu ou Debian. La bonne posture opérationnelle reste prudente : considérer les paquets Squid comme potentiellement vulnérables jusqu’à confirmation de l’errata ou du backport.

Sur les rebuilds compatibles RHEL, même logique : on suit l’éditeur de référence et on vérifie la version exacte du paquet livré par le dépôt de sécurité.

SUSE / openSUSE

Le suivi SUSE signalait de nombreux produits comme Affected avec un statut global encore en cours d’évaluation. Là aussi, l’approche recommandée est claire : si Squid sert un rôle partagé, traiter le sujet comme exploitable jusqu’à disponibilité d’un correctif distro ou mise en place d’une mitigation.

Comment la faille peut être exploitée en pratique ?

L’exploitation décrite n’est pas celle d’un attaquant anonyme sur Internet envoyant une simple requête à ton proxy. Elle suppose d’abord que l’attaquant soit un utilisateur autorisé du proxy ou qu’il dispose d’un chemin équivalent via l’infrastructure.

Ensuite, Squid doit pouvoir atteindre un serveur FTP contrôlé par l’attaquant. C’est ce serveur qui renvoie une réponse de listing spécialement conçue pour déclencher le comportement de lecture hors limites. Enfin, pour que la fuite soit utile, les buffers mémoire recyclés doivent contenir des données d’intérêt : morceaux de requêtes HTTP, en-têtes d’authentification, cookies ou autres artefacts d’une transaction récente.

Ce point change la lecture du risque. Sur un proxy ne transportant presque que du HTTPS en tunnel opaque, l’impact réel peut être plus limité. En revanche, sur un environnement avec interception TLS, avec HTTP clair ou avec des services internes bavards, la fuite peut devenir beaucoup plus intéressante pour un attaquant.

On reste donc sur une faille moins “grand public” qu’un RCE préauth, mais tout à fait pertinente pour un audit de sécurité d’exploitation.

Comment évaluer l’exposition rapidement

La bonne question n’est pas seulement “ai-je Squid ?”. Il faut dérouler une petite qualification technique :

1. Squid est-il installé et en service ?
2. Le proxy est-il partagé entre plusieurs utilisateurs ou équipes ?
3. Le trafic FTP via Squid est-il encore possible ?
4. Le proxy traite-t-il du HTTP clair ou de l’interception TLS ?
5. Des utilisateurs non totalement fiables peuvent-ils l’utiliser ?

Si la réponse est oui à plusieurs de ces questions, l’exposition est sérieuse. À l’inverse, un Squid mono-usage, sans FTP, sans utilisateurs tiers et sans contenu sensible lisible est mécaniquement moins risqué.

squid -v
systemctl status squid --no-pager
grep -n "Safe_ports" /etc/squid/squid.conf /etc/squid/conf.d/*.conf 2>/dev/null
grep -Rin "proto FTP\|ftp_port\|acl FTP" /etc/squid 2>/dev/null
ss -tulpn | grep squid

Ce mini-lab ne casse rien : il sert uniquement à confirmer la présence du service, la version, et les indices de configuration autour du protocole FTP. Si ton équipe utilise Ansible, tu peux intégrer ces vérifications dans un audit de parc plus large, au même titre qu’un inventaire des versions Nginx ou OpenSSL.

Sur ce point, l’article corriger des vulnérabilités Nginx avec Ansible illustre bien la logique : on ne se contente pas de patcher, on industrialise la vérification, le déploiement et la preuve.

Comment patcher selon la distribution

Le principe est simple : mettre à jour le paquet Squid depuis les dépôts sécurité officiels, puis contrôler la version livrée et la reprise correcte du service.

Debian / Ubuntu

sudo apt update
sudo apt install --only-upgrade squid
apt-cache policy squid
squid -v
sudo squid -k parse
sudo systemctl restart squid
sudo systemctl status squid --no-pager

Sur Debian, si le tracker indique encore vulnérable pour ta branche, le correctif peut ne pas être encore poussé. Dans ce cas, ne t’arrête pas à “aucune mise à jour disponible” : applique aussi une mitigation côté configuration.

RHEL / AlmaLinux / Rocky Linux

sudo dnf update squid
rpm -q squid
squid -v
sudo squid -k parse
sudo systemctl restart squid
sudo systemctl status squid --no-pager

Sur cet écosystème, il faut lire l’errata de sécurité correspondant. Le numéro de package distribué primera sur la version upstream affichée dans les publications techniques.

SUSE / openSUSE

sudo zypper refresh
sudo zypper update squid
rpm -q squid
squid -v
sudo squid -k parse
sudo systemctl restart squid
sudo systemctl status squid --no-pager

Si l’éditeur n’a pas encore publié de package corrigé, mieux vaut réduire la surface d’attaque immédiatement plutôt que d’attendre une hypothétique vague d’exploitation.

Que faire si le correctif n’est pas encore disponible ?

La mitigation la plus rationnelle consiste à désactiver l’usage FTP via Squid si cette fonction n’est pas réellement utile. Dans beaucoup d’environnements modernes, c’est un reliquat historique plus qu’un besoin métier.

Selon la configuration, cela peut passer par le retrait du port 21 de Safe_ports, l’ajout d’une ACL explicite pour refuser proto FTP, ou un blocage egress au firewall pour empêcher Squid d’atteindre des serveurs FTP externes.

acl FTP proto FTP
http_access deny FTP

Tu peux aussi durcir côté réseau :

# Exemple conceptuel : bloquer les sorties du proxy vers TCP/21
# à adapter à nftables, iptables ou au firewall cloud utilisé.

Dans un contexte sensible, l’autre mitigation consiste à segmenter davantage les usages du proxy. Un proxy mutualisé entre utilisateurs de confiance différente est plus délicat à défendre qu’un proxy dédié par usage ou par périmètre.

Checklist opérationnelle Squidbleed

Erreurs courantes à éviter

Aller plus loin

Pour approfondir, tu peux consulter notre guide sur la correction industrialisée de CVE Nginx avec Ansible ainsi que l’article sur le durcissement d’images Docker et le scan de vulnérabilités. Le principe reste le même : transformer un advisory en procédure de remédiation vérifiable.

FAQ Squidbleed / Squid CVE

Conclusion

Squidbleed est le genre de CVE qui ne doit ni être minimisée, ni dramatisée. Ce n’est pas une RCE universelle, mais c’est une vraie faille de confidentialité dans un composant souvent oublié, avec un scénario crédible en environnement multi-utilisateurs.

La bonne réponse consiste à faire trois choses vite : vérifier les versions distribuées, qualifier l’exposition FTP réelle, puis patcher ou couper FTP selon la maturité des dépôts. Si tu gères plusieurs proxys, profite de ce sujet pour industrialiser l’inventaire et la preuve de remédiation.