CVE-2026-101909

Podatność w bibliotece axios pozwala na wysyłanie żądań do absolutnych URL-i zamiast względnych, co może prowadzić do ataków SSRF i wycieku poświadczeń. Nawet przy ustawionym baseURL, axios ignoruje to i wysyła żądanie do podanego absolutnego adresu URL.

Axios w wersjach 0.28.0 i późniejszych zawiera niekontrolowaną rekurencję w formDataToJSON, pomocniku stojącym za publicznym API axios.formToJSON() / nazwanym formToJSON oraz domyślnym przekształceniu żądania używanym, gdy FormData jest wysyłane z typem treści application/json.

Axios jest podatny na gadżety zanieczyszczenia prototypu po stronie odczytu, gdy Object.prototype został już zanieczyszczony przez inną podatność lub zależność. Najbardziej dostępny problem dotyczy aliasów metod bez ciała: axios.get(), axios.delete(), axios.head() i axios.options().

Axios może konsumować dziedziczone właściwości z zagnieżdżonych obiektów opcji żądania, gdy proces JavaScript ma już zanieczyszczony Object.prototype. Główna połączona konfiguracja jest chroniona prototypem null, ale zagnieżdżone zwykłe obiekty, takie jak auth i paramsSerializer, są klonowane do obiektów z prototypem.

W Axios 1.5.1 wykryto problem, który nieumyślnie ujawnia poufny token XSRF-TOKEN przechowywany w ciasteczkach. Token ten jest dołączany do nagłówka HTTP X-XSRF-TOKEN w każdym żądaniu wysyłanym do dowolnego hosta, co pozwala atakującym na podejrzenie wrażliwych informacji.

Axios w wersjach od 0.28.0 zawiera niekontrolowaną rekurencję w formDataToJSON, która jest udostępniana jako axios.formToJSON() i używana wewnętrznie, gdy axios serializuje FormData z Content-Type: application/json. Jeśli aplikacja przekaże kontrolowane przez atakującego nazwy pól FormData, może to prowadzić do wyczerpania stosu.

Podatność w bibliotece Axios przed wersjami 1.15.0 i 0.31.0 nieprawidłowo normalizuje nazwy hostów podczas sprawdzania reguł NO_PROXY. Żądania do adresów pętli zwrotnej, takich jak localhost. (z kropką na końcu) lub [::1] (adres IPv6), omijają dopasowanie NO_PROXY i są kierowane przez skonfigurowany serwer proxy.

W Axios od wersji 1.7.0 do 1.20.0 adapter fetch konstruuje Request z oczyszczonymi resolvedOptions, ale następnie wywołuje fetch z oryginalnymi fetchOptions. Osobna wada zanieczyszczenia prototypu w tym samym procesie wypełnia Object.prototype.headers, więc fetchOptions.headers rozwiązuje się przez dziedziczenie. Odziedziczona wartość fetchOptions.headers nadpisuje oczyszczone nagłówki Request przez drugi argument do fetch po konstrukcji Request. Nagłówki kontrolowane przez atakującego mogą zmienić autoryzację, buforowanie, dostęp do usług metadanych lub zachowanie specyficzne dla aplikacji.

Axios od wersji 1.17.0 do 1.20.0 w adapterze fetch omija politykę przekierowań maxRedirects: 0. Żądanie Axios używające adaptera fetch z maxRedirects ustawionym na zero otrzymuje odpowiedź przekierowania, ale bazowa implementacja fetch podąża za przekierowaniem zamiast zwrócić odpowiedź bez zmian. Przekierowane żądanie może uzyskać dostęp do wewnętrznych odpowiedzi lub osiągnąć wewnętrzne punkty końcowe zmieniające stan, mimo że przekierowania są wyłączone.

Axios od wersji 1.15.0 do 1.20.0 w funkcji shouldBypassProxy stosuje kwadratowe wyrażenie regularne z kropkami na końcu do nazw hostów przekierowań. Gdy skonfigurowano HTTP_PROXY lub HTTPS_PROXY, NO_PROXY lub no_proxy nie jest puste, przekierowania są śledzone, a spreparowane przekierowanie Location zawiera wiele kropek po których następuje znak niebędący kropką, wyrażenie regularne może powodować kwadratowe cofanie się, blokując pętlę zdarzeń Node.js i powodując odmowę usługi.