CVE-2026-111754

Angular w wersjach przed 20.3.30, 21.2.22 i 22.1.4 ma podatność w renderowaniu po stronie serwera (SSR) w @angular/platform-server. Funkcje resolveUrl i parseUrl wywołują String.prototype.trim(), co usuwa wiodące białe znaki Unicode po sprawdzeniu same-origin, przekształcając ścieżkę względną w kontrolowany przez atakującego URL protokołu względnego, prowadząc do SSRF i ujawnienia danych uwierzytelniających.

Angular przed wersjami 20.3.34 i 21.0.3 ma funkcję xsrfInterceptorFn w @angular/common HttpClient, która używa wyrażenia regularnego nienormalizującego adresów URL żądań w taki sam sposób jak parser WHATWG w przeglądarce. Przy włączonej ochronie XSRF mutujące żądanie HTTP do adresu URL kontrolowanego przez atakującego, zawierającego odwrotne ukośniki, usunięte znaki kontrolne lub spacje albo usuwalne białe znaki ASCII, może zostać błędnie zaklasyfikowane jako względne i tego samego pochodzenia, co powoduje dołączenie nagłówka X-XSRF-TOKEN przed wysłaniem żądania do hosta cross-origin.

Podatność w @angular/router podczas renderowania po stronie serwera w Node.js pozwala nieuwierzytelnionemu atakującemu wysyłać spreparowane żądania z wieloma nieskonfigurowanymi grupami outletów o pustej ścieżce. Powoduje to wielokrotne przetwarzanie konfiguracji tras, tworzenie zduplikowanych drzew ActivatedRouteSnapshot oraz wykonywanie strażników canMatch i resolverów, co może wyczerpać stertę lub CPU i zakończyć proces roboczy SSR. Problem naprawiono w wersjach 20.3.33, 21.2.25 i 22.2.1.

W wersjach Angular od 21.2.0 do 21.2.25 i 22.2.1 dyrektywy RouterLink renderowane podczas SSR w Node.js zachowują obliczone instancje UrlTree przez cały czas trwania żądania. Gdy queryParamsHandling ustawiono na merge lub preserve, każdy wyrenderowany link może przechowywać kopię kontrolowanych przez atakującego parametrów zapytania, co przy dużych ciągach zapytań może wyczerpać stertę old-space i zakończyć proces roboczy SSR. Problem naprawiono w wersjach 21.2.25 i 22.2.1.

W Angular przed wersjami 20.3.32, 21.2.24 i 22.2.0 parser URL @angular/router przechowuje numeryczne nazwy parametrów macierzy i numeryczne nazwy outletów jako właściwości na początkowo pustych obiektach JavaScript podczas renderowania po stronie serwera w Node.js. V8 może interpretować te klucze pochodzące z URL jako indeksy tablicy i alokować gęste magazyny o rozmiarze odpowiadającym wysokim wartościom numerycznym, więc powtarzające się małe segmenty ścieżki powodują nieproporcjonalne zużycie sterty na segment. Nieuwierzytelniony atakujący może wysyłać nakładające się żądania zawierające powtarzające się numeryczne parametry macierzy, gdy SSR jest włączone, router bezpośrednio parsuje URL żądania, a proxy nadrzędne zezwalają na średniki i wiele segmentów ścieżki, ostatecznie wyczerpując stertę old-space Node.js i kończąc proces roboczy SSR. Czysto klienckie aplikacje Angular nie są dotknięte.

Angular to platforma do budowania aplikacji webowych; w wersjach przed 20.3.31, 21.2.23 i 22.1.6 parser emulacji DOM w @angular/platform-server może wejść w nieskończoną pętlę synchroniczną, gdy renderowanie po stronie serwera przetwarza kontrolowany przez atakującego HTML zawierający niekompletny DOCTYPE kończący się białym znakiem na końcu danych. W Domino lib/HTMLParser.js stan after_doctype_name_state emituje tokeny doctype i EOF bez przesuwania nextchar, przez co skaner wielokrotnie przetwarza ten sam znacznik EOF. Zdalny nieuwierzytelniony atakujący może wykorzystać ten warunek przez ścieżki parsowania HTML po stronie serwera, takie jak wiązanie innerHTML, aby zużyć pełne CPU workera SSR Node.js, zagłodzić pętlę zdarzeń i zatrzymać równoczesne oraz kolejne żądania. Problem naprawiono w wersjach 20.3.31, 21.2.23 i 22.1.6.

Angular w wersjach przed 20.3.30, 21.2.22 i 22.1.4 ma podatność w renderowaniu po stronie serwera (SSR) w @angular/platform-server. Serializacja niezaufanych danych wewnątrz elementów fallback raw-content (noscript, iframe, noembed, noframes) nie escapuje pasujących tagów zamykających, co umożliwia wykonanie dowolnego kodu JavaScript.

W Angularze w wersjach przed 20.3.28, 21.2.20 i 22.1.1 mechanizm @angular/common HttpTransferCache może zapisać w pamięci podręcznej uwierzytelnioną odpowiedź, gdy renderowanie po stronie serwera (SSR) i hydratacja używają hierarchicznego HttpClient skonfigurowanego z withRequestsMadeViaParent. Podrzędny TransferCache ocenia początkowo anonimowe żądanie przed delegacją, a następnie nadrzędny łańcuch withInterceptors dodaje nagłówek Authorization, cookie lub token API; mimo że nadrzędny cache pomija uwierzytelnione żądanie, podrzędny nadal zapisuje prywatną odpowiedź w TransferState serializowaną jako JSON w skrypcie ng-state. Późniejszy nieuwierzytelniony lub nieuprawniony odwiedzający może otrzymać buforowany HTML zawierający dane wrażliwe wcześniejszego uwierzytelnionego użytkownika.

Angular w wersjach przed 20.3.30, 21.2.22 i 22.1.4 ma podatność w renderowaniu po stronie serwera (SSR) w @angular/platform-server. Serializacja węzłów ProcessingInstruction wewnątrz elementów fallback raw-content nie escapuje pasujących tagów zamykających, co pozwala na przedwczesne zamknięcie kontenera i wykonanie dowolnego kodu JavaScript.

W Angularze w wersjach przed 20.3.28, 21.2.20 i 22.1.0 kompilator i środowisko uruchomieniowe w @angular/core i @angular/compiler mogły pominąć lub wybrać nieprawidłowy sanitizer dla wrażliwych na bezpieczeństwo powiązań host bindings dyrektyw, ponieważ SecurityContext był wyznaczany na podstawie selektora deklarującej dyrektywy lub komponentu, a nie konkretnego elementu hosta. Niezgodność jest osiągalna przez kompozycję hostDirectives, dziedziczone deklaracje HostBinding, createComponent z niestandardowym hostElement lub dynamicznymi dyrektywami, elementy przestrzeni nazw SVG/MathML oraz selektory neutralne dla tagów, takie jak :not(...). Kontrolowane przez atakującego wartości href, src, action, xlink:href lub data mogą w ten sposób trafić do atrybutów DOM bez wbudowanego sanitizera Angulara i wykonać dowolny JavaScript w kontekście przeglądarki użytkownika.