CVE-2026-27739
Angular SSR est vulnérable aux attaques SSRF et à l'injection d'en-têtes via le pipeline de traitement des requêtes
- Publié
- 25 févr. 2026
- Mise à jour
- 27 févr. 2026
- Attribution de CNA
- GitHub_M
- Preuve observée
- 17 sept. 2026
CVSS primaire
nvd · CVSS 4.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XFaible · 30 prochains jours
- Percentile
- 41,6 %
- Date du modèle
- 21 sept. 2026
EPSS est une estimation statistique, et non une certitude ou une mesure d'impact. Combinez-le avec CVSS, le statut KEV, l'exposition et votre environnement.
Résumé
Angular SSR est un outil de rendu côté serveur pour les applications Angular. Les versions antérieures à 21.2.0-rc.1, 21.1.5, 20.3.17 et 19.2.21 présentent une vulnérabilité de type Server-Side Request Forgery (SSRF) dans le pipeline de traitement des requêtes d'Angular SSR. La vulnérabilité existe parce que la logique interne de reconstruction d'URL d'Angular fait directement confiance aux en-têtes HTTP contrôlés par l'utilisateur et les consomme, en particulier l'en-tête Host et la famille `X-Forwarded-*`, pour déterminer l'origine de base de l'application sans aucune validation du domaine de destination. Plus précisément, le framework ne disposait pas de contrôles sur le domaine hôte, la sanitisation du chemin et des caractères, ni la validation du port. Cette vulnérabilité se manifeste de deux manières principales : la résolution implicite d'URL relatives et la construction manuelle explicite. Lorsqu'elle est exploitée avec succès, cette vulnérabilité permet une redirection arbitraire de requêtes internes. Cela peut entraîner une exfiltration d'identifiants, une exploration du réseau interne et une violation de confidentialité. Pour être vulnérable, l'application victime doit utiliser Angular SSR (Server-Side Rendering), l'application doit effectuer des requêtes `HttpClient` en utilisant des URL relatives OU construire manuellement des URL à l'aide des en-têtes `Host` / `X-Forwarded-*` non validés via l'objet `REQUEST`, le serveur applicatif doit être accessible par un attaquant capable d'influencer ces en-têtes sans validation stricte de la part d'un proxy frontal, et l'infrastructure (Cloud, CDN ou Load Balancer) ne doit pas assainir ni valider les en-têtes entrants. Les versions 21.2.0-rc.1, 21.1.5, 20.3.17 et 19.2.21 contiennent un correctif. Certains contournements sont disponibles. Évitez d'utiliser `req.headers` pour la construction d'URL. Utilisez plutôt des variables de confiance pour les chemins d'API de base. Ceux qui ne peuvent pas mettre à jour immédiatement devraient implémenter un middleware dans leur `server.ts` pour imposer des ports numériques et des noms d'hôtes validés.
Sources
1Utilisation responsable
Utilisez les informations de vulnérabilité uniquement sur les systèmes que vous possédez ou que vous êtes autorisé à tester. Kitploit renvoie aux métadonnées de la recherche publique et ne stocke pas de code d'exploitation ni de charges utiles malveillantes.