Dévoiler le cauchemar caché : HTTP Smuggling et Poisoning Pingora

Les vulnérabilités, désignées sous les identifiants CVE-2026-2833, CVE-2026-2835, et CVE-2026-2836, exposent les entreprises utilisant des déploiements Pingora auto-hébergés à des risques de sécurité graves, notamment le contournement des contrôles de sécurité, le vol d’identifiants et l’empoisonnement des caches web, selon un article du blog Cloudflare.

La vulnérabilité la plus critique concerne la gestion par Pingora des requêtes de mise à niveau HTTP. Lorsqu’il reçoit des requêtes avec l’en-tête Upgrade, le framework basculait prématurément en mode passthrough avant que le serveur en amont n’accepte le changement de protocole. Cela permettait aux attaquants d’introduire des requêtes malveillantes qui contournaient entièrement les contrôles de sécurité de Pingora.

Une seconde vulnérabilité provenait d’une analyse incorrecte des requêtes HTTP/1.0 contenant des en-têtes Transfer-Encoding, interdits par les normes RFC. Au lieu de rejeter ces requêtes, Pingora interprétait mal la longueur de la requête, créant une discordance avec les serveurs en amont conformes qui pouvait être exploitée pour des attaques de contrebande de requêtes.

Le troisième problème affectait la fonctionnalité de cache en phase alpha de Pingora, où les clés de cache étaient générées en utilisant uniquement le chemin URI sans tenir compte de l’en-tête Host ni du schéma HTTP. Cela signifiait qu’un attaquant pouvait empoisonner le cache pour un domaine et que ce contenu malveillant serait servi aux utilisateurs visitant un site complètement différent.

Infrastructure Cloudflare protégée

Cloudflare a confirmé que ses services CDN en production n’ont jamais été vulnérables en raison de son architecture de défense en profondeur. L’entreprise a expliqué que Pingora n’est pas utilisé comme le proxy internet principal exposé dans son CDN, et que les proxys en amont normalisent le trafic avant qu’il n’atteigne les instances Pingora internes. De plus, Cloudflare a toujours utilisé des clés de cache multi-facteurs robustes plutôt que l’implémentation par défaut non sécurisée.

Les vulnérabilités ont été entièrement corrigées dans Pingora version 0.8.0. La mise à jour corrige la logique Upgrade pour basculer de mode uniquement après réception d’une confirmation appropriée des serveurs en amont, renforce l’analyseur HTTP pour rejeter les requêtes non conformes et supprime complètement l’implémentation non sécurisée des clés de cache par défaut.

Les entreprises exécutant des déploiements Pingora auto-hébergés devraient effectuer une mise à jour immédiate vers la version 0.8.0 ou ultérieure. Lors de la mise en œuvre de la mise en cache via un proxy, les administrateurs doivent s’assurer que les clés de cache identifient de manière exhaustive les ressources en fonction de tous les paramètres pertinents, notamment le schéma, l’hôte, le chemin et les en-têtes qui varient.