Vulnérabilités dans le projet Pingora permettant d'intercepter les requêtes externes

L'entreprise Cloudflare a annoncé avoir corrigé trois vulnérabilités dans le cadre de Pingora, dont deux ont été classées comme critiques (9,3 sur 10). Le cadre Pingora est écrit en Rust et est destiné à développer des services réseau sécurisés et hautes performances. Le proxy construit avec Pingora est utilisé dans le réseau de distribution de contenu de Cloudflare et traite plus de 40 millions de requêtes par seconde. Les vulnérabilités ont été corrigées dans la version Pingora 0.8.0.

Les deux vulnérabilités les plus préoccupantes permettent des attaques de type « HTTP Request Smuggling », qui contournent les systèmes de restriction d'accès et s'immiscent dans le contenu des requêtes d'autres utilisateurs qui sont traitées dans le même flux entre le front-end et le back-end (par exemple, pour insérer un code JavaScript malveillant dans la session d'un autre utilisateur sur le site). Ces problèmes ont été découverts par un participant au programme Bug Bounty, qui prévoit une récompense pour la découverte de vulnérabilités.

Dans un schéma où les appels au back-end passent par un proxy inverse, les requêtes des clients sont acceptées par un nœud supplémentaire, qui établit une connexion TCP persistante avec le back-end, qui traite directement les requêtes. C’est par cette connexion commune que sont généralement transmises les requêtes de différents utilisateurs, qui s’enchaînent les unes après les autres en utilisant des moyens du protocole HTTP. Les attaques de type HTTP Request Smuggling surviennent en raison d'interprétations différentes des en-têtes HTTP et des spécifications du protocole HTTP entre les front-ends et les back-ends, par exemple, lorsque le front-end utilise l'en-tête HTTP « Content-Length » pour déterminer la taille de la requête, tandis que le back-end utilise « Transfer-Encoding: chunked ».

La première vulnérabilité CVE-2026-2835 est présente dans le code d'analyse des requêtes HTTP/1.0 et est causée par un traitement incorrect de l'en-tête « Transfer-Encoding » avec plusieurs valeurs, ainsi que par l'utilisation de la fermeture de la connexion comme indication de la fin du corps de la requête (close-delimited). Pingora vérifiait uniquement la variante « Transfer-Encoding: chunked » et ignorait cet en-tête s'il contenait plusieurs valeurs. Dans cette situation, Pingora ne tenait pas compte de la taille dans l'en-tête « Content-Length », considérant comme corps de la requête toutes les données reçues avant la fermeture de la connexion.

En spécifiant plusieurs valeurs dans l'en-tête « Transfer-Encoding », l'attaquant pouvait créer des conditions dans lesquelles la demande était redirigée vers le backend, dont la taille réelle ne correspondait pas à la taille de la chaîne chunked, calculée sur la base de l'en-tête « Transfer-Encoding. Pingora redirigeait toutes les données reçues en une seule demande, tandis que le backend, comme Node.js, calculait la demande en fonction de « Transfer-Encoding: chunked » et traitait le reste comme le début d'une autre demande. GET / HTTP/1.0 Host: example.com Connection: keep-alive Transfer-Encoding: identity, chunked Content-Length: 29 0 GET /admin HTTP/1.1 X:

La seconde vulnérabilité CVE-2026-2833 est causée par un traitement incorrect de l'en-tête HTTP « Upgrade » dans les requêtes HTTP/1.1. Lorsqu'un en-tête « Upgrade » était présent dans la demande, le proxy le transmettait immédiatement au backend, ainsi que les autres données de la demande suivant l'en-tête « Upgrade », sans attendre de réponse du backend avec le code 101 (Switching Protocols). En raison de cela, la synchronisation du flux entre le proxy et le backend était perturbée et le backend considérait les données envoyées après l'en-tête « Upgrade » comme une demande distincte, renvoyant le résultat de l'exécution de cette demande en réponse à la demande suivante d'un autre utilisateur. GET / HTTP/1.1 Host: example.com Upgrade: foo GET /admin HTTP/1.1 Host: example.com

Les problèmes se manifestent lors de l'utilisation de Pingora sous la forme d'un proxy inverse (ingress proxy), transmettant les demandes des utilisateurs aux backends en utilisant les protocoles HTTP/1.0 ou HTTP/1.1. La configuration utilisée dans le réseau de distribution de contenu Cloudflare ne permettait pas d'exploiter les vulnérabilités, car Pingora dans le CDN n'est pas utilisé comme ingress proxy, redirigeant les demandes uniquement en utilisant le protocole HTTP/1.1, bloquant les demandes avec des valeurs Content-Length incorrectes, redirigeant uniquement une valeur de l'en-tête « Transfer-Encoding: chunked » et ajoutant dans les demandes avec l'en-tête « Upgrade: » un en-tête additionnel « Connection: close », empêchant l'envoi de demandes supplémentaires dans la même connexion.

La troisième vulnérabilité CVE-2026-2836 (niveau de danger 8.4 sur 10) conduit à une contamination du cache (cache poisoning) en raison de la génération de la clé de mise en cache (CacheKey) uniquement sur la base du chemin URI, en ignorant le contenu de l'en-tête « Host ». Un tel défaut entraîne la création de clés de mise en cache identiques pour des chemins HTTP identiques vers différents hôtes. Cette vulnérabilité peut être exploitée pour remplacer le contenu du cache lors de l'utilisation du mode de mise en cache pour plusieurs hôtes. Dans Pingora, la mise en cache est une fonctionnalité expérimentale, non recommandée pour les déploiements en production.

Source : opennet.ru