Archiwa: NIST - Strona 26 z 38 - Security Bez Tabu

Tag: NIST

Ni8mare (CVE-2026-21858): krytyczna luka w n8n pozwala przejąć samodzielnie hostowane serwery automatyzacji

Wprowadzenie do problemu / definicja luki

Na początku stycznia 2026 r. ujawniono podatność „Ni8mare” w n8n — popularnej platformie do automatyzacji workflow (często wykorzystywanej też do orkiestracji integracji AI/LLM). Luka otrzymała maksymalny wynik CVSS 10.0 i została zarejestrowana jako CVE-2026-21858. W praktyce problem dotyczy głównie self-hosted instalacji n8n oraz scenariuszy, w których organizacje wystawiają na zewnątrz formularze/webhooki obsługujące pliki.

Klucz: to nie jest „kolejna drobna wpadka w parserze”. n8n bywa centralnym węzłem automatyzacji (API keys, tokeny OAuth, dostępy do baz, chmury, CI/CD), więc nawet pozornie „tylko” odczyt plików z hosta może kaskadowo skończyć się pełnym przejęciem środowiska.

W skrócie

  • Identyfikator: CVE-2026-21858 (Ni8mare), krytyczna podatność (CVSS 10.0).
  • Dotyczy: wersji n8n poniżej 1.121.0.
  • Istota problemu: „Content-Type confusion” w obsłudze webhooków/formularzy — brak właściwej walidacji typu żądania umożliwia kontrolę struktur opisujących pliki i w konsekwencji odczyt dowolnych plików z hosta w ramach podatnego workflow opartego o formularze.
  • Naprawa: aktualizacja do n8n 1.121.0+; oficjalnych obejść brak (tymczasowo: ograniczyć/wyłączyć publicznie dostępne webhooki/formy).

Kontekst / historia / powiązania

Z analizy Cyera wynika, że podatność została zgłoszona do n8n 9 listopada 2025, a wersja z poprawką została opublikowana 18 listopada 2025. CVE przypisano 6 stycznia 2026, a opis techniczny upubliczniono 7 stycznia 2026.

BleepingComputer zwraca uwagę na skalę potencjalnej ekspozycji (szacunki rzędu dziesiątek tysięcy instancji) oraz fakt, że n8n jest bardzo popularny w automatyzacjach związanych z AI (RAG, agenci, integracje).

Analiza techniczna / szczegóły luki

1) Gdzie zaczyna się problem: webhooki i parsowanie requestów

n8n przyjmuje dane wejściowe do workflow m.in. przez webhooki (w tym formularze). W uproszczeniu: to, jak n8n sparsuje body żądania, zależy od nagłówka Content-Type — inne ścieżki dla multipart/form-data (upload plików), inne dla pozostałych typów (np. JSON).

2) „Content-Type confusion”: kontrola req.body.files

Cyera opisuje scenariusz, w którym przy nieodpowiednim Content-Type uruchamia się „zwykły” parser body, a nie parser uploadu. Ponieważ wynik parsowania trafia do obiektu żądania, możliwe staje się nadpisanie struktur, które później są traktowane jak lista przesłanych plików (req.body.files). Jeśli w danym workflow logika obsługi formularza nie weryfikuje, że faktycznie przyszło multipart/form-data, to kolejne funkcje plikowe mogą zaufać tym danym.

3) Skutek techniczny: prymityw „arbitrary file read”

W opisie Cyera kluczowy jest moment, w którym komponent formularza wywołuje funkcje kopiujące pliki do magazynu (dysk/S3) na podstawie metadanych pliku — w tym ścieżki źródłowej. Jeśli atakujący kontroluje ten parametr, zamiast „prawdziwego uploadu” może zostać przetworzony lokalny plik z hosta, a jego treść trafia dalej do workflow (np. do bazy wiedzy/RAG, czatu, integracji).

W praktyce oznacza to, że podatne workflow oparte o formularze mogą stać się kanałem do wyciągania wrażliwych plików (konfiguracje, sekrety, pliki aplikacji). To dokładnie ten typ „małego błędu wejścia”, który w platformie automatyzacji często kończy się dużym incydentem.

Praktyczne konsekwencje / ryzyko

GitHub Advisory i NVD opisują CVE-2026-21858 jako możliwość nieautoryzowanego dostępu do plików w ramach określonych, form-based workflow, z ryzykiem dalszego kompromitowania zależnie od konfiguracji i sposobu użycia.

Z perspektywy obrony warto rozbić ryzyko na warstwy:

  • Wycieki sekretów i danych: jeżeli na hoście/volumenach są pliki konfiguracyjne, tokeny, klucze, dane integracji — odczyt plików może stać się wstępem do pivotu na inne systemy.
  • Przejęcie aplikacji n8n: BleepingComputer (na bazie ustaleń Cyera) wskazuje, że konsekwencje mogą obejmować także elementy eskalacji (np. nadużycia sesji) zależnie od środowiska i workflow.
  • Ryzyko downstream: n8n często ma „uprzywilejowane” integracje (CRM/ERP, chmura, CI/CD, bazy, narzędzia developerskie). Po przejęciu kontekstu automatyzacji atakujący może uderzyć dalej, już poza samą instancją n8n.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które realnie obniżają ryzyko — od „gaśnicy” po twarde zabezpieczenia:

  1. Natychmiastowa aktualizacja
  • Zaktualizuj do n8n 1.121.0 lub nowszej (to wersja wskazana jako zawierająca poprawkę).
  1. Tymczasowa redukcja powierzchni ataku (jeśli nie możesz patchować od razu)
  • Ogranicz lub wyłącz publicznie dostępne webhooki i endpointy formularzy do czasu aktualizacji.
  1. Przegląd workflow i ekspozycji
  • Zidentyfikuj workflow wykorzystujące Form / form-based webhooks (zwłaszcza te z uploadem plików lub logiką, która przekazuje pliki dalej: RAG/LLM, storage, e-mail, ticketing).
  • Sprawdź, czy te endpointy są wystawione do Internetu bez dodatkowej warstwy kontroli (reverse proxy, allowlist, WAF, auth).
  1. Rotacja sekretów i audyt dostępu
  • Jeśli instancja była publicznie dostępna i/lub podejrzewasz ekspozycję: rozważ rotację kluczy/tokenu integracji trzymanych w n8n, bo skutkiem CVE może być ich ujawnienie przez odczyt plików lub dane workflow.
  1. Długofalowo: zasady „n8n jako system uprzywilejowany”
  • Traktuj n8n jak narzędzie klasy „automation hub”: segmentacja sieci, minimalne uprawnienia integracji, ograniczenie egress/ingress, monitorowanie wywołań webhooków i anomalii w uruchamianiu workflow.

Różnice / porównania z innymi przypadkami

CSO Online zwraca uwagę, że ekosystem n8n notował też inne krytyczne problemy (w tym RCE) w ostatnim okresie, dlatego kluczowe jest utrzymywanie „latest available version” oraz skracanie okna ekspozycji między poprawką a wdrożeniem.

Na tym tle Ni8mare wyróżnia się tym, że startuje od wejścia zewnętrznego (formularze/webhook) i wykorzystuje błąd klasy „input validation / content-type handling”, który w aplikacjach integracyjnych bywa szczególnie groźny, bo łączy świat zewnętrzny z wewnętrznymi zasobami (pliki/sekrety/integracje).

Podsumowanie / kluczowe wnioski

  • CVE-2026-21858 (Ni8mare) to krytyczna podatność w n8n, która w podatnych workflow opartych o formularze może prowadzić do nieautoryzowanego dostępu do plików na hoście, a w praktyce — do poważniejszej kompromitacji zależnie od konfiguracji i tego, jak n8n jest używany w organizacji.
  • Najważniejsze działanie obronne jest proste: aktualizacja do 1.121.0+ oraz czasowe ograniczenie publicznej ekspozycji webhooków/form, jeśli patch nie jest natychmiast możliwy.
  • Warto potraktować tę lukę jako sygnał do „utwardzenia” n8n: minimalizacja ekspozycji, przegląd workflow, rotacja sekretów i monitoring, bo automatyzacja jest dziś jednym z najbardziej uprzywilejowanych punktów w środowiskach IT.

Źródła / bibliografia

  1. Cyera Research Labs — analiza „Ni8mare” i tło techniczne. (cyera.com)
  2. GitHub Security Advisory (n8n) — opis wpływu, wersje, mitigacje. (GitHub)
  3. NVD (NIST) — rekord CVE-2026-21858 i opis podatnych wersji. (NVD)
  4. BleepingComputer — kontekst, skala, streszczenie mechanizmu. (BleepingComputer)
  5. CSO Online — opis „Content-Type confusion” i mechaniki odczytu plików. (CSO Online)

Krytyczna luka w jsPDF (CVE-2025-68428): kradzież plików z serwera przez generowane PDF-y

Wprowadzenie do problemu / definicja luki

W bibliotece jsPDF wykryto krytyczną podatność typu Local File Inclusion / Path Traversal, oznaczoną jako CVE-2025-68428. Problem dotyczy wyłącznie buildów Node.js i pozwala atakującemu odczytywać dowolne pliki dostępne dla procesu Node, a następnie „przemycać” ich zawartość wygenerowanym PDF-em (czyli w legalnym artefakcie wyjściowym aplikacji).

W skrócie

  • Co jest podatne: jsPDF w wersjach < 4.0.0, tylko artefakty dist/jspdf.node.js i dist/jspdf.node.min.js.
  • Warunek ataku: użytkownik/atakujący musi mieć możliwość sterowania argumentem-ścieżką pliku przekazywanym do podatnych metod (bez twardego allowlistu/sanitizacji).
  • Skutek: wyciek tajnych danych (np. pliki konfiguracyjne, sekrety, klucze, pliki .env) do PDF, który aplikacja normalnie zwraca/zapisuje.
  • Poprawka: aktualizacja do jsPDF 4.0.0, gdzie domyślnie ograniczono dostęp do systemu plików i oparto egzekwowanie na Node.js Permission Model.

Kontekst / historia / powiązania

Podatność została zgłoszona w procesie GitHub Security Advisories (GHSA) i oceniona jako krytyczna (CNA score 9.2 w CVSS v4).
BleepingComputer zwraca uwagę, że ryzyko realnej eksploatacji zależy od tego, czy ścieżki plików są kontrolowane przez użytkownika, a także że w praktyce wdrożenie mitigacji przez Permission Model może wymagać nowszych wersji Node.

Analiza techniczna / szczegóły luki

Co dokładnie nie działa

Sednem problemu jest metoda loadFile w buildzie Node.js: jeśli atakujący kontroluje pierwszy argument (ścieżkę), biblioteka potrafi odczytać wskazany plik z dysku i dołączyć jego zawartość do PDF.

Metody podatne (wektory wejścia)

Oprócz loadFile, podatne są też metody, które pośrednio z niej korzystają:

  • addImage
  • html
  • addFont

Przykładowy wektor ataku (model)

Jeśli aplikacja pozwala użytkownikowi wskazać „obrazek” lub zasób do osadzenia w PDF (np. parametr imagePath), atakujący może zamiast tego podać ścieżkę do pliku z sekretami. Zawartość trafi do PDF „jakby nigdy nic”, a następnie wycieknie kanałem dystrybucji dokumentu (download, email, storage, S3 itp.).

Dlaczego poprawka jest „nietypowa”

W jsPDF 4.0.0 ograniczenie dostępu do systemu plików jest domyślne, a rekomendowana ochrona opiera się na Node.js Permission Model (uruchomienie procesu z flagą --permission i precyzyjnymi allowlistami zasobów).

Praktyczne konsekwencje / ryzyko

Największe ryzyko dotyczy usług, które:

  • generują PDF-y po stronie serwera (Node.js),
  • przyjmują od użytkownika parametry wpływające na to, jakie pliki/zasoby są osadzane (np. „logo”, „załącznik”, „szablon”, „font”, „HTML do renderu”),
  • działają z szerokimi uprawnieniami do systemu plików lub z dostępnymi sekretami na dysku (np. .env, klucze prywatne, konfiguracje).

Warto też zauważyć „cichy” charakter eksfiltracji: to nie musi być osobny kanał C2 – dane mogą wyciec w legalnym pliku PDF, który system i monitoring traktują jako normalny rezultat pracy aplikacji.

Rekomendacje operacyjne / co zrobić teraz

1) Aktualizacja zależności (priorytet)

  • Zaktualizuj do jspdf@4.0.0 (lub nowszej).

2) Wymuś Permission Model w Node.js (jeśli generujesz PDF-y na serwerze)

Uruchamiaj proces z ograniczeniami i minimalnym zakresem odczytu:

node --permission --allow-fs-read=/app/assets,/app/templates ./server.js

Flagi --allow-fs-read i --permission są elementem Permission Model (zwróć uwagę: zbyt szerokie reguły, np. --allow-fs-read=*, de facto kasują ochronę).

Uwaga operacyjna: te flagi dotyczą całego procesu Node, nie tylko jsPDF — mogą ujawnić ukryte zależności od dostępu do FS i wywołać regresje.

3) Jeśli nie możesz zaktualizować natychmiast

  • Wprowadź twardy allowlist (mapowanie identyfikator → bezpieczna ścieżka) zamiast przepuszczać ścieżki od użytkownika.
  • Zablokuj sekwencje path traversal (../, ..\\) i używaj normalizacji (path.resolve) + sprawdzania prefiksu katalogu bazowego.
  • Rozdziel role: osobny serwis do generowania PDF z minimalnymi uprawnieniami i bez sekretów na dysku.

4) Szybkie „triage” ekspozycji w kodzie

Szukaj wywołań:

  • addImage(...), html(...), addFont(...), loadFile(...)
    gdzie pierwszy argument może pochodzić z: request params, body, query string, upload metadata, bazy danych modyfikowalnej przez userów.

Różnice / porównania z innymi przypadkami

  • Klasyczne LFI/Path Traversal często kończy się odpowiedzią HTTP z treścią pliku lub błędem. Tutaj wyciek jest „opakowany” w PDF, który bywa logowany, archiwizowany i wysyłany dalej — co utrudnia wykrycie i zwiększa promień rażenia (retencja, kopie, systemy DLP).
  • Nietypowe jest też oparcie remediacji na mechanizmie runtime (Permission Model) zamiast wyłącznie na walidacji wejścia w bibliotece — co zwiększa znaczenie poprawnej konfiguracji środowiska uruchomieniowego.

Podsumowanie / kluczowe wnioski

  • CVE-2025-68428 to krytyczna podatność w jsPDF (Node build) umożliwiająca odczyt lokalnych plików i ich eksfiltrację przez generowane PDF-y.
  • Jeżeli w Twojej aplikacji użytkownik może wpływać na ścieżki/zasoby przekazywane do addImage/html/addFont/loadFile, traktuj temat jako pilny.
  • Najlepsza ścieżka: upgrade do 4.0.0 + uruchamianie Node z --permission i wąskimi allowlistami FS.

Źródła / bibliografia

  1. GitHub Security Advisory (jsPDF) – GHSA-f8cm-6447-x5h2 (GitHub)
  2. NVD (NIST) – CVE-2025-68428 (NVD)
  3. Endor Labs – analiza i rekomendacje dla CVE-2025-68428 (endorlabs.com)
  4. Node.js Documentation – Permission Model / flags --permission, --allow-fs-read (Node.js)
  5. BleepingComputer – kontekst i ryzyka wdrożeniowe mitigacji (BleepingComputer)

CVE-2025-37164: aktywnie wykorzystywana luka RCE (CVSS 10) w HPE OneView trafia do KEV CISA

Wprowadzenie do problemu / definicja luki

CVE-2025-37164 to krytyczna podatność typu code injection prowadząca do zdalnego wykonania kodu (RCE) w HPE OneView – platformie do centralnego zarządzania infrastrukturą (serwery, storage, sieć). Kluczowy problem: atak może być przeprowadzony bez uwierzytelnienia, a więc z perspektywy obrony jest to scenariusz „high impact / low effort”.

Na początku stycznia 2026 r. luka została oznaczona jako aktywnie wykorzystywana w atakach oraz powiązana z wymaganiami „Known Exploited Vulnerabilities” (KEV).

W skrócie

  • Co? Niezautoryzowane RCE w HPE OneView (CVE-2025-37164) przez mechanizm code injection.
  • Kogo dotyczy? W praktyce wszystkie wydania przed 11.00 (w danych NVD: zakres wersji 5.20–10.20).
  • Status zagrożenia: CISA/KEV wskazuje na dowody aktywnej eksploatacji; termin działań (dla FCEB) wskazano na 28 stycznia 2026.
  • Co robić? Priorytetowo upgrade do 11.0+ albo zastosowanie dostarczonych hotfixów/łatek; brak sensownych obejść „konfiguracyjnych” zastępujących aktualizację.

Kontekst / historia / powiązania

HPE OneView działa jak uprzywilejowana warstwa zarządzania (control plane) – często głęboko w sieci, z szerokimi uprawnieniami do zarządzania firmware, profilami serwerów i automatyzacją. Dlatego pojedyncze RCE w takim komponencie ma „promień rażenia” większy niż typowa podatność w aplikacji biznesowej.

W połowie grudnia 2025 r. pojawiły się poprawki i komunikacja producenta, a 7 stycznia 2026 r. luka została odnotowana jako KEV (z oznaczeniem „exploited in the wild” w praktyce operacyjnej CISA).

Analiza techniczna / szczegóły luki

Z perspektywy technicznej jest to problem sklasyfikowany jako CWE-94 (Improper Control of Generation of Code – Code Injection).

Istotny detal dla obrońców: według analizy Rapid7, wektor ataku wiąże się z osiągalnym bez uwierzytelnienia endpointem REST:

  • /rest/id-pools/executeCommand – potencjalny punkt wejścia umożliwiający wykonanie poleceń i finalnie RCE.

Rapid7 wskazuje też, że vendorowy hotfix wygląda jak reguła na warstwie HTTP, która blokuje dostęp do konkretnego endpointu – co jest ważne w ocenie ryzyka (jeśli ktoś polega wyłącznie na „filtrach” na brzegu, a nie aktualizuje appliance).

Ocena CVSS: w NVD widać rozjazd między oceną CNA (HPE) i NVD: 10.0 (HPE) vs 9.8 (NVD), ale w praktyce oba wyniki oznaczają „patch natychmiast”.

Praktyczne konsekwencje / ryzyko

Jeśli OneView zostanie przejęty, konsekwencje wykraczają poza „zwykłe RCE na serwerze”:

  • Przejęcie płaszczyzny zarządzania: atakujący może uzyskać wpływ na konfiguracje i cykl życia infrastruktury (w tym elementy trudne do wykrycia na poziomie OS).
  • Ryzyko masowej eskalacji: OneView bywa „centralnym mózgiem” dla wielu zasobów – kompromitacja jednego komponentu może oznaczać kompromitację wielu.
  • Realne wykorzystanie w atakach: CISA/KEV + doniesienia branżowe wskazują, że to nie jest już ryzyko teoretyczne.

Rekomendacje operacyjne / co zrobić teraz

Priorytet potraktuj jak P0 / incident-prep (zwłaszcza jeśli OneView jest osiągalny z sieci o niższym poziomie zaufania).

1) Patch/upgrade (najważniejsze)

  • Zaktualizuj OneView do 11.0 lub nowszej lub zastosuj dostarczone hotfixy zgodnie z zaleceniami.
  • Załóż, że „wkrótce” ≠ „wystarczająco szybko” – luka jest oznaczona jako aktywnie eksploatowana.

2) Ogranicz powierzchnię ataku (równolegle, nie zamiast patcha)

  • Zablokuj dostęp do OneView z Internetu (jeśli kiedykolwiek był wystawiony).
  • Wymuś dostęp wyłącznie przez sieć administracyjną/VPN, z allowlistą źródeł.
  • Dodaj reguły detekcyjne na ruch do /rest/id-pools/executeCommand (WAF/proxy/IDS) – to nie jest „remedium”, ale może pomóc w wykryciu prób.

3) Threat hunting i kontrola zmian

  • Przejrzyj logi reverse proxy / load balancer / firewall pod kątem nietypowych żądań do OneView, szczególnie do ww. endpointu.
  • Skontroluj ostatnie zmiany w OneView: nowe konta, tokeny/API, modyfikacje profili serwerów, zadania automatyzacji.
  • Rotuj wrażliwe poświadczenia, jeśli istnieje podejrzenie dostępu (hasła serwisowe, integracje, konta uprzywilejowane powiązane z zarządzaniem).

4) Ramy zgodności i terminy

  • Jeśli podlegasz reżimowi podobnemu do KEV/BOD (lub mapujesz się na te priorytety), potraktuj 28 stycznia 2026 jako twardy deadline na usunięcie ryzyka.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

CVE-2025-37164 jest groźna z tego samego powodu, co krytyczne podatności w innych „platformach zarządzania” (np. systemy orkiestracji, panele kontrolne, control plane dla wirtualizacji):

  • uprzywilejowane pozycjonowanie w sieci,
  • duża koncentracja uprawnień,
  • oraz częsta praktyka traktowania tych systemów jako „zaufanych” i słabiej monitorowanych.

Różnica praktyczna: tu mówimy o komponencie, który może wpływać także na warstwę infrastruktury (profile sprzętowe/zarządzanie), a nie tylko na pojedynczy host.

Podsumowanie / kluczowe wnioski

  • CVE-2025-37164 to krytyczne, niezautoryzowane RCE w HPE OneView, powiązane z code injection (CWE-94).
  • CISA/KEV sygnalizuje aktywną eksploatację i wymusza pilność działań (deadline 2026-01-28 w KEV).
  • Najskuteczniejsza obrona to natychmiastowy upgrade/hotfix oraz szybkie ograniczenie ekspozycji OneView i monitoring prób dostępu do podejrzanych endpointów.

Źródła / bibliografia

  1. BleepingComputer – informacja o aktywnym wykorzystaniu i zaleceniach dot. aktualizacji (BleepingComputer)
  2. NVD (NIST) – wpis CVE, metryki, CWE, dane o KEV i termin 2026-01-28 (NVD)
  3. Rapid7 – analiza techniczna, wskazanie endpointu i charakter hotfixa (Rapid7)

CVE-2026-0625: krytyczna luka RCE w starych bramkach D-Link DSL jest aktywnie wykorzystywana

Wprowadzenie do problemu / definicja luki

Na przełomie końcówki 2025 i początku 2026 pojawiły się potwierdzone sygnały aktywnej eksploatacji krytycznej podatności typu OS Command Injection, która umożliwia zdalne wykonanie poleceń na wybranych, wycofanych z produkcji bramkach D-Link DSL. Podatność otrzymała identyfikator CVE-2026-0625 i dotyczy webowego komponentu konfiguracji DNS (dnscfg.cgi).

Najgorsza część? Mówimy o urządzeniach EOL/EOS (End of Life / End of Support), które nie dostaną poprawek — producent zaleca ich wycofanie i wymianę.

W skrócie

  • Co? Zdalne wykonanie poleceń (RCE) przez wstrzyknięcie komend w mechanizm konfiguracji DNS (dnscfg.cgi).
  • Kogo dotyczy? Potwierdzone modele i wersje firmware:
    • DSL-526B ≤ 2.01
    • DSL-2640B ≤ 1.07
    • DSL-2740R < 1.17
    • DSL-2780B ≤ 1.01.14
  • Jak poważne? CVSS v4.0: 9.3 (Critical), wektor wskazuje atak sieciowy bez uwierzytelnienia i bez interakcji użytkownika.
  • Czy jest patch? D-Link wskazuje, że to legacy DSL-e bez wsparcia; zalecenie to retire & replace.
  • Czy to jest w użyciu „w dziczy”? Tak — obserwacje exploitacji były widziane m.in. 27 listopada 2025 (UTC) wg informacji przypisywanych do danych Shadowserver.

Kontekst / historia / powiązania

Z punktu widzenia obrony warto zauważyć, że podatny endpoint (dnscfg.cgi) jest kojarzony z klasą nadużyć określaną jako DNSChanger: nieautoryzowana zmiana ustawień DNS w routerze w celu przechwytywania, przekierowywania lub blokowania ruchu użytkowników. D-Link w przeszłości dokumentował kampanie dotykające wariantów firmware tych modeli w latach 2016–2019.

Nowość w CVE-2026-0625 polega na tym, że nie chodzi wyłącznie o „podmianę DNS”, ale o pełnoprawne RCE poprzez wstrzyknięcie komend w ścieżce obsługi konfiguracji DNS, co otwiera drogę do trwałej kompromitacji urządzenia i dalszych działań w sieci.

Warto też odnotować oś czasu:

  • 2025-11-27 (UTC): zaobserwowane ślady eksploatacji (telemetria/honeypoty).
  • 2026-01-05: publikacja advisory przez VulnCheck (CNA dla CVE).
  • 2026-01-06: komunikat D-Link (SAP10488) o trwającym dochodzeniu i zaleceniu wymiany urządzeń.

Analiza techniczna / szczegóły luki

Gdzie jest problem?

Podatność dotyczy endpointu webowego dnscfg.cgi, który obsługuje parametry związane z konfiguracją DNS. Wg opisu VulnCheck i NVD, wejście użytkownika (parametry konfiguracji DNS) nie jest poprawnie sanityzowane, co umożliwia wstrzyknięcie elementów powłoki i uruchomienie dowolnych komend systemowych.

Co umożliwia atakującemu?

  • Brak uwierzytelnienia: scenariusz ataku zakłada, że zdalny napastnik może wywołać podatną funkcję bez loginu.
  • RCE: wykonanie dowolnych poleceń shell na urządzeniu, a więc praktycznie pełna kontrola w granicach uprawnień procesu/środowiska systemu routera.

Dlaczego „aktywnie wykorzystywana”, skoro zwykle panel jest tylko z LAN?

BleepingComputer zwraca uwagę, że wiele domowych konfiguracji ogranicza CGI panelu administracyjnego do LAN, więc realna eksploatacja może zachodzić m.in. wtedy, gdy:

  • włączono zdalne zarządzanie (remote administration) od strony WAN,
  • urządzenie jest wystawione przez błędną konfigurację/NAT/port forwarding,
  • albo atak ma charakter „przeglądarkowy” (np. ofiara w LAN odwiedza złośliwą stronę, która próbuje sięgnąć do panelu routera – sam mechanizm bywa utrudniony przez różne kontrolki przeglądarek, ale koncepcyjnie jest to rozważany wektor).

Praktyczne konsekwencje / ryzyko

Jeśli atakujący uzyska RCE na bramce DSL, konsekwencje rzadko kończą się na „jednym urządzeniu”:

  1. Cicha manipulacja DNS
    Przekierowanie użytkowników na fałszywe strony logowania, podmiana aktualizacji, wstrzykiwanie reklam/malware — i to dla każdego hosta za routerem.
  2. Trwała kompromitacja i nadużycia infrastrukturalne
    Router może stać się elementem botnetu, węzłem proxy, punktem przechwytywania/routingu ruchu lub przyczółkiem do ruchu bocznego (lateral movement).
  3. Brak łatwej ścieżki naprawy
    D-Link podkreśla, że potwierdzone ustalenia dotyczą produktów legacy bez bieżącego wsparcia, a zaleceniem jest ich wycofanie. To oznacza, że „patch management” nie rozwiąże problemu — zostają działania kompensacyjne i wymiana.

Rekomendacje operacyjne / co zrobić teraz

Poniżej plan działań w kolejności, która zwykle minimalizuje ryzyko najszybciej.

1) Szybka identyfikacja ekspozycji

  • Sprawdź w inwentaryzacji, czy masz: DSL-526B, DSL-2640B, DSL-2740R, DSL-2780B i porównaj wersje firmware z listą „Affecting” VulnCheck / potwierdzoną przez D-Link.
  • Zmapuj, czy web panel/router management jest osiągalny z Internetu (skan z zewnątrz, reguły NAT, przekierowania portów).

2) Natychmiastowe ograniczenie powierzchni ataku (kompensacje)

Jeśli wymiana nie jest „na już”, to minimum:

  • Wyłącz remote administration od strony WAN.
  • Zablokuj dostęp do panelu zarządzania na firewallu od strony Internetu (ACL tylko z sieci administracyjnych/VPN).
  • Jeśli urządzenie musi działać: segmentacja (oddzielny VLAN), restrykcyjne reguły egress, monitoring DNS i ruchu wychodzącego.

3) Wymiana urządzeń (zalecenie docelowe)

D-Link wprost rekomenduje wycofanie legacy urządzeń i zastąpienie modelami wspieranymi. Dla środowisk produkcyjnych to najrozsądniejsza decyzja koszt/ryzyko.

4) Kontrola po incydencie (jeśli podejrzewasz kompromitację)

  • Sprawdź, czy DNS na routerze nie wskazuje na nieznane resolvery.
  • Wymuś zmianę haseł administracyjnych (oraz haseł Wi-Fi), rozważ factory reset (z ostrożnością: przywrócenie tej samej konfiguracji może odtworzyć problem ekspozycji).
  • Przejrzyj logi (o ile dostępne) pod kątem nietypowych żądań HTTP do dnscfg.cgi oraz anomalii w ruchu wychodzącym.
  • Jeśli router był bramą dla firmy: potraktuj to jako potencjalny „initial access” i wykonaj przegląd hostów wewnętrznych.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

DNS hijack / DNSChanger vs RCE przez dnscfg.cgi

  • DNS hijack (zmiana DNS) bywa „wystarczająca” do masowych nadużyć (phishing, malvertising).
  • RCE eskaluje sytuację: umożliwia doinstalowanie komponentów, modyfikację konfiguracji na poziomie systemu, utrzymanie dostępu i użycie urządzenia jako infrastruktury ataku. Opisy NVD i VulnCheck łączą oba światy: ten sam obszar funkcjonalny (DNS config), ale konsekwencje są znacznie szersze.

EOL jako czynnik ryzyka
W odróżnieniu od wielu współczesnych incydentów, tutaj kluczowy problem jest organizacyjny: nawet idealny SOC nie „załata” sprzętu, który nie dostaje aktualizacji. To klasyczny przykład, dlaczego polityka lifecycle (wymiana EOL) jest kontrolką bezpieczeństwa, a nie tylko „tematem zakupowym”.

Podsumowanie / kluczowe wnioski

  • CVE-2026-0625 to krytyczne unauthenticated RCE w legacy bramkach D-Link DSL, realizowane przez command injection w dnscfg.cgi.
  • Są przesłanki aktywnej eksploatacji co najmniej od końcówki listopada 2025 (UTC).
  • Potwierdzone podatne modele to m.in. DSL-526B, DSL-2640B, DSL-2740R, DSL-2780B w określonych zakresach firmware.
  • Ponieważ urządzenia są EOL/EOS, kluczową rekomendacją jest wymiana; do tego czasu — twarde ograniczenie ekspozycji panelu (zwłaszcza od WAN) i segmentacja.

Źródła / bibliografia

  • BleepingComputer: „New D-Link flaw in legacy DSL routers actively exploited in attacks” (2026-01-06). (BleepingComputer)
  • D-Link Security Announcement SAP10488 (2026-01-06). (supportannouncement.us.dlink.com)
  • VulnCheck Advisory: „D-Link DSL Command Injection via DNS Configuration Endpoint” (2026-01-05). (VulnCheck)
  • NIST NVD: CVE-2026-0625 record (published 2026-01-05). (nvd.nist.gov)
  • SecurityWeek: „Hackers Exploit Zero-Day in Discontinued D-Link Devices” (2026-01-07). (SecurityWeek)

Krytyczna luka w dekoderze Dolby załatana w Androidzie: CVE-2025-54957 (DD+ Unified Decoder)

Wprowadzenie do problemu / definicja luki

Styczniowy biuletyn bezpieczeństwa Androida (2026) załatał podatność w komponentach Dolby oznaczoną jako CVE-2025-54957 i sklasyfikował ją jako Critical dla Androida (DD+ Codec). To błąd w Dolby Digital Plus (DD+) Unified Decoder / UDC, czyli powszechnie używanym dekoderze audio obecnym na wielu platformach.

Sedno problemu: specjalnie spreparowany strumień/plik audio może doprowadzić do błędu pamięci (out-of-bounds write), a w pewnych warunkach — potencjalnie do wykonania kodu w procesie dekodującym.

W skrócie

  • CVE-2025-54957 dotyczy Dolby UDC (DD+) i wynika z przepełnienia liczb całkowitych, które prowadzi do zapisu poza buforem.
  • W Androidzie problem jest szczególnie groźny, bo dekodowanie części treści audio może zachodzić lokalnie bez interakcji użytkownika (scenariusze „0-click”).
  • Android Security Bulletin – styczeń 2026 wskazuje poprawkę i patch level 2026-01-05+ jako rozwiązujący problem.
  • Dolby w swoim advisory podaje CVSS 3.1 = 6.7 (Medium) i zaznacza, że najczęstszym skutkiem bywa crash/restart odtwarzacza, ale na Androidzie (m.in. Pixel) ryzyko może rosnąć przy łańcuchowaniu z innymi lukami.

Kontekst / historia / powiązania

Według opisu sprawy podatność została odkryta przez badaczy Google i zgłoszona do Dolby w czerwcu 2025, a poprawka po stronie Dolby miała być dostępna we wrześniu 2025. Temat stał się głośny jesienią 2025, gdy upubliczniono detale techniczne i pojawiły się informacje o wpływie na wiele ekosystemów.

Co ważne, luki w „multimedialnych” komponentach (kodeki/parsowanie) często mają szeroki zasięg, bo ten sam kod bywa licencjonowany i osadzany w wielu produktach. W tym przypadku CCB (belgijskie centrum ds. cyberbezpieczeństwa) wprost wskazuje „downstream impact” na różne systemy operacyjne, a na Androidzie podkreśla scenariusz 0-click.

Analiza techniczna / szczegóły luki

Z technicznego punktu widzenia mamy klasyczną sekwencję błędów:

  1. Wejście kontrolowane przez atakującego: spreparowany DD+ bitstream (np. osadzony w pliku/załączniku audio).
  2. Błąd obliczeń długości: podczas przetwarzania tzw. evolution data w pliku evo_priv.c następuje integer overflow / wraparound przy kalkulacji rozmiaru zapisu.
  3. Zbyt mała alokacja + nieskuteczna walidacja: bufor zostaje zaalokowany za mały, a późniejsza kontrola granic zapisu przestaje działać, co kończy się out-of-bounds write.

CCB opisuje dodatkowo konsekwencję typową dla OOB write w strukturach: nadpisanie kolejnych pól (w tym potencjalnie wskaźników), co może otwierać drogę do bardziej deterministycznego przejęcia sterowania przepływem wykonania.

Praktyczne konsekwencje / ryzyko

Dlaczego Android oznaczył to jako „Critical”, skoro Dolby mówi „Medium”?
Różnica zwykle nie wynika z „innego błędu”, tylko z innego modelu zagrożeń i kontekstu użycia. Dolby w advisory wskazuje umiarkowaną ocenę (CVSS 6.7) i sugeruje, że często kończy się to crashem, ale równocześnie zaznacza większe ryzyko dla urządzeń z rodziny Pixel przy łączeniu z innymi podatnościami. Z kolei Android (i komentujący sprawę eksperci) akcentują, że na Androidzie dekodowanie niektórych treści audio może następować lokalnie po ich dostarczeniu — co umożliwia scenariusze bez kliknięcia.

Praktyczne skutki dla organizacji i użytkowników:

  • potencjalny RCE w procesie multimedialnym (zależnie od osiągalności ścieżki i twardości mitigacji),
  • DoS/crash usług multimedialnych (restarty procesów, spadek stabilności),
  • możliwość wykorzystania jako element łańcucha exploitów (np. RCE → eskalacja → trwałość).

Rekomendacje operacyjne / co zrobić teraz

1) Aktualizuj do patch level 2026-01-05 lub nowszego
To najważniejszy krok — Android wskazuje, że ten poziom łatek adresuje problem.

2) W organizacji: wymuś zgodność aktualizacji (MDM/UEM)

  • ustaw polityki „minimum security patch level” (blokada dostępu do zasobów dla urządzeń niespełniających wymogu),
  • włącz/egzekwuj automatyczne aktualizacje, tam gdzie to możliwe (zgodne też z rekomendacją Dolby dla konsumentów).

3) Redukuj powierzchnię ataku w kanałach wiadomości (tam, gdzie ma to sens)
CCB sugeruje rozważenie wyłączenia RCS na Androidzie, by ograniczyć ekspozycję na automatyczną obsługę treści multimedialnych w pewnych scenariuszach.
Dodatkowo (praktyka operacyjna): ogranicz auto-pobieranie multimediów w komunikatorach i edukuj użytkowników o ryzyku nieoczekiwanych plików audio.

4) Monitoring i detekcja
CCB zaleca podniesienie czujności monitoringu pod kątem podejrzanej aktywności.
W praktyce SOC/IR na Android Enterprise może szukać:

  • skoków crashy procesów multimedialnych,
  • anomalii powiązanych czasowo z odbiorem wiadomości/załączników audio,
  • korelacji z nietypowymi źródłami plików (MMS/RCS/aplikacje).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • „Media parser” vs „aplikacja”: luki w kodekach są groźne, bo atakują warstwę przetwarzania danych, często uruchamianą automatycznie przez system lub aplikacje (stąd realność „0-click”).
  • Ocena ryzyka zależna od integracji: ten sam błąd w bibliotece może mieć różny „ciężar” na platformach, zależnie od tego, czy wejście jest osiągalne bez UI, jakie są sandboxy, jakie mitigacje kompilatora/OS i czy istnieją znane łańcuchy.

Podsumowanie / kluczowe wnioski

CVE-2025-54957 to podatność w Dolby UDC (DD+), która technicznie sprowadza się do integer overflow → zbyt mała alokacja → out-of-bounds write w ścieżce przetwarzania „evolution data”. Android nadał jej rangę Critical i załatał w styczniowym biuletynie 2026 — jeśli zarządzasz flotą urządzeń, priorytetem jest doprowadzenie ich do patch level 2026-01-05+.

Źródła / bibliografia

  1. Android Open Source Project – Android Security Bulletin (January 2026) (Android Open Source Project)
  2. Dolby – Security Advisory CVE-2025-54957 (PDF, Oct 14 2025)
  3. NIST NVD – CVE-2025-54957 (nvd.nist.gov)
  4. SecurityWeek – Critical Dolby Vulnerability Patched in Android (SecurityWeek)
  5. Centre for Cybersecurity Belgium (CCB) – Advisory on Dolby Unified Decoder CVE-2025-54957 (ccb.belgium.be)

Katalog CISA KEV urósł o ~20% w 2025 i przekroczył 1 480 pozycji: co to oznacza dla zespołów bezpieczeństwa?

Wprowadzenie do problemu / definicja luki

CISA Known Exploited Vulnerabilities (KEV) to katalog podatności, co do których istnieją potwierdzone dowody, że są wykorzystywane „w dziczy” (in-the-wild). Dla praktyki bezpieczeństwa to ważny filtr: nie „co może być groźne”, tylko „co realnie jest używane przez atakujących”.

Na początku stycznia 2026 r. podsumowania za 2025 r. wskazały, że katalog KEV wyraźnie przyspieszył wzrost i przekroczył próg 1 480 wpisów.

W skrócie

  • 1 484: tyle podatności (software + hardware) znajdowało się w KEV po dopisaniach z 2025 r.
  • +245: o tyle pozycji rozszerzono katalog w samym 2025 r.
  • 24: tyle dopisanych w 2025 r. podatności zostało oznaczonych jako wykorzystywane w kampaniach ransomware.
  • Wśród głośniejszych przykładów: CitrixBleed 2 (CVE-2025-5777) oraz podatności w Oracle E-Business Suite (CVE-2025-61882, CVE-2025-61884).

Kontekst / historia / powiązania

KEV jest powiązany z amerykańskim podejściem regulacyjnym do priorytetyzacji łatania — w szczególności z Binding Operational Directive (BOD) 22-01, która opisuje model „ciągłego priorytetyzowania” poprzez katalog podatności znanych z realnego wykorzystania.

W praktyce rynkowej KEV stał się też punktem odniesienia poza administracją: dostarcza stabilnego, kuratorowanego sygnału „exploited”, który można wpiąć do procesów VM (Vulnerability Management), patch management i risk management.

Warto dodać kontekst operacyjny: CISA utrzymuje też publiczne mirrorowanie danych KEV na GitHubie (repo cisagov/kev-data), co ułatwia integracje automatyczne i śledzenie zmian w czasie.

Analiza techniczna / szczegóły (jak wygląda KEV „od środka”)

Z perspektywy automatyzacji najważniejsze jest to, że KEV da się konsumować jako dane. W repozytorium cisagov/kev-data publikowane są pliki m.in. w formacie CSV/JSON, aktualizowane wkrótce po zmianach w źródle kanonicznym.

Przykładowy rekord (CSV) zawiera m.in. pola (nazwy kolumn), które są bezpośrednio użyteczne w priorytetyzacji i raportowaniu:

  • cveID, vendorProject, product, vulnerabilityName
  • dateAdded (kiedy dodano do KEV)
  • shortDescription, requiredAction
  • dueDate (termin wykonania)
  • knownRansomwareCampaignUse (czy wiązane z ransomware)
  • notes, cwes

To jest istotna różnica względem „samego CVE w NVD”: KEV daje nie tylko identyfikator i opis, ale też operacyjny kontekst (termin, wymagane działanie, sygnał ransomware).

Co mówi trend 2025?

Podsumowania pokazują, że wzrost KEV w 2025 r. był większy niż w dwóch poprzednich latach: w 2023 r. dopisano 187 pozycji, w 2024 r. 185, a w 2025 r. 245.

Co ważne, do katalogu trafiały nie tylko nowe CVE — dopisywano również starsze podatności (np. wskazywano CVE-2007-0671 jako najstarszą dodaną w 2025 r.), a najstarsza pozycja w katalogu ma pochodzić z 2002 r.

Praktyczne konsekwencje / ryzyko

Jeśli KEV rośnie szybciej, rośnie też presja na trzy obszary:

  1. Priorytetyzacja i „patch capacity”
    245 nowych wpisów rocznie (i trend przyspieszenia) oznacza, że „łatamy wszystko krytyczne” przestaje być wykonalne — potrzebujesz twardego filtra, a exploited-in-the-wild jest jednym z najsilniejszych.
  2. Ryzyko ransomware i incydentów masowych
    Oznaczenie „knownRansomwareCampaignUse” (tam, gdzie występuje) to gotowy sygnał do osobnej ścieżki eskalacji. Wśród przykładów z 2025 r. pojawiają się m.in. CitrixBleed 2 oraz wybrane podatności Oracle E-Business Suite.
  3. Dług techniczny i „stare CVE, nowe ataki”
    Dopisywanie starszych CVE do KEV przypomina, że exploitacja nie jest funkcją „świeżości” podatności. To argument za twardą inwentaryzacją i kontrolą EOL/EOS.

Rekomendacje operacyjne / co zrobić teraz

  1. Wepnij KEV jako obowiązkowy sygnał w VM
    Minimum: codzienny import danych KEV i korelacja z asset inventory + wynikami skanerów.
  2. Zbuduj 2–3 tory priorytetyzacji
    • Tor A (natychmiast): KEV + internet-facing + (jeśli masz) telemetry/exploit-attempts
    • Tor B (szybko): KEV (pozostałe) wg dueDate
    • Tor C (ciągłe): reszta CVE wg CVSS/EPSS/krytyczności usługi
  3. Traktuj „dueDate” jako SLO, nie „ładną metrykę”
    Skoro KEV publikuje termin oraz wymagane działanie, to możesz budować KPI typu: % KEV w terminie oraz średni czas do remediacji od dateAdded.
  4. Wydziel ścieżkę „ransomware-labeled”
    Tam, gdzie pole knownRansomwareCampaignUse jest ustawione, automatycznie:
    • eskaluj do właściciela usługi,
    • uruchom szybkie skanowanie ekspozycji,
    • sprawdź logi pod kątem exploit patternów.
  5. Zautomatyzuj monitoring zmian (diff)
    GitHubowe mirrorowanie KEV ułatwia śledzenie: co doszło, co zmieniono, co usunięto — przydatne do alertingu i audytu.
    (W 2025 r. raportowano też przypadek usunięcia podatności z KEV po ocenie „insufficient evidence of exploitation”, co pokazuje, że katalog jest kuratorowany, a nie „tylko rośnie”.)

Różnice / porównania z innymi przypadkami

KEV vs CVSS:
CVSS to głównie potencjalny wpływ, KEV to potwierdzona exploitacja + komponent operacyjny (termin, wymagane działanie).

KEV vs NVD (i ogólnie „wszystkie CVE”):
NVD obejmuje ogromny zbiór podatności; KEV jest węższy i nastawiony na „risk that is being realized”. To dobry filtr do sytuacji, gdy backlog CVE jest większy niż realna przepustowość zespołów.

KEV vs „vendor advisories / hype w mediach”:
KEV jest zwykle mniej podatny na szum: jeśli coś jest „głośne”, ale brak dowodów wykorzystania, nie musi trafić do KEV — a jeśli dowody się pojawią, KEV jest jednym z najważniejszych sygnałów, że temat przestał być teoretyczny.

Podsumowanie / kluczowe wnioski

  • W 2025 r. KEV urósł do ok. 1 484 wpisów, a tempo wzrostu (+245) było wyższe niż w 2023–2024.
  • Wpisy KEV są operacyjnie użyteczne, bo zawierają m.in. termin (dueDate), wymagane działanie i oznaczenia (np. ransomware).
  • Jeżeli dziś nie masz procesu „KEV-first”, to przy takim trendzie backlog i ryzyko będą rosnąć szybciej niż zdolność do łatania.

Źródła / bibliografia

  1. SecurityWeek – podsumowanie wzrostu KEV w 2025 r. (1 484 wpisy, +245, 24 ransomware). (SecurityWeek)
  2. Cyble – analiza trendów KEV w 2025 r., przykłady CVE wykorzystywanych przez ransomware, dynamika wzrostu. (Cyble)
  3. GitHub cisagov/kev-data – oficjalne repo-mirror danych KEV i informacje o synchronizacji/aktualizacjach. (GitHub)
  4. known_exploited_vulnerabilities.csv – struktura danych (kolumny m.in. dueDate, requiredAction, knownRansomwareCampaignUse). (GitHub)
  5. NIST (prezentacja) – kontekst BOD 22-01 i rola katalogu KEV w priorytetyzacji remediacji. (NIST Computer Security Resource Center)

Krytyczna luka w @adonisjs/bodyparser (CVE-2026-21440, CVSS 9.2): path traversal umożliwia dowolny zapis plików na serwerze

Wprowadzenie do problemu / definicja luki

Na początku stycznia 2026 ujawniono krytyczną podatność w ekosystemie AdonisJS, dotyczącą pakietu npm @adonisjs/bodyparser. Luka została zarejestrowana jako CVE-2026-21440 i oceniona przez CNA (GitHub) na CVSS 4.0: 9.2 (Critical).

To klasyczny przypadek path traversal (CWE-22) w mechanizmie obsługi uploadu multipart/form-data, który w określonych warunkach umożliwia zdalnemu atakującemu zapis plików w dowolnej lokalizacji w systemie plików serwera (a w konsekwencji — czasem także eskalację do RCE).

W skrócie

  • Co jest podatne: @adonisjs/bodyparser (mechanizm MultipartFile.move(...)).
  • Wektor ataku: upload przez endpoint, który przyjmuje multipart/form-data.
  • Sedno problemu: domyślne użycie niesanitowanej nazwy pliku pochodzącej od klienta oraz ryzykowne domyślne ustawienia w move() (m.in. domyślne nadpisywanie).
  • Skutek: arbitrary file write (dowolny zapis/nadpisanie pliku); potencjalnie RCE, jeśli uda się nadpisać pliki ładowane/wykonywane przez aplikację.
  • Naprawa: aktualizacja do @adonisjs/bodyparser 10.1.2 (stable) lub 11.0.0-next.6 (pre-release).

Kontekst / historia / powiązania

Informacja o luce pojawiła się publicznie w formie GitHub Security Advisory opublikowanego 2 stycznia 2026, a następnie została szerzej opisana m.in. w mediach branżowych 6 stycznia 2026.

Istotny kontekst z perspektywy ryzyka: advisory wskazuje, że dokumentacja pokazywała wcześniej przykłady prowadzące do użycia podatnej ścieżki (czyli „secure-by-default” nie zadziałało, a dodatkowo wzorce z docs mogły utrwalić ryzykowną praktykę).

Analiza techniczna / szczegóły luki

Gdzie jest błąd?

AdonisJS parsuje multipart/form-data przez BodyParser i udostępnia uploady jako obiekty MultipartFile. Problem dotyczy zachowania metody:

  • MultipartFile.move(location, options)

Jeżeli aplikacja wywołuje move() bez przekazania options.name, framework (w podatnych wersjach) domyślnie podstawiał nazwę pliku przesłaną przez klienta (client filename) i budował ścieżkę docelową w stylu path.join(location, name). Przy odpowiednio spreparowanej nazwie (np. z sekwencjami ../) atakujący może „wyjść” poza katalog uploadu i wskazać inną lokalizację zapisu.

Dodatkowo advisory podkreśla drugi element ryzyka: jeśli options.overwrite nie jest przekazane, domyślnie ustawione było na true, co ułatwia nadpisywanie istniejących plików.

Kiedy to działa w praktyce?

Wprost: potrzebny jest osiągalny endpoint uploadu, który:

  • przyjmuje multipart/form-data, oraz
  • używa MultipartFile.move() w sposób podatny (bez options lub bez sanitacji nazwy pliku).

Co zmienia poprawka?

W wydaniu 10.1.2 (analogicznie w 11.0.0-next.6) wprowadzono zmianę: MultipartFile.move(location) nie używa już domyślnie nazwy pliku od klienta. Zamiast tego generowana jest losowa, unikalna nazwa oparta o uuid. To jest świadomie opisane jako breaking change, ale dostarczone w patchu, aby szybko „zamknąć” klasę ataków wynikającą z niebezpiecznego domyślnego zachowania.

Praktyczne konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem jest arbitrary file write: atakujący może doprowadzić do zapisu pliku w ścieżce, której programista nie przewidział — łącznie z nadpisaniem krytycznych plików, jeżeli proces ma odpowiednie uprawnienia.

RCE nie jest „gwarantowane”, ale scenariusz jest realistyczny, jeśli możliwe jest nadpisanie:

  • kodu aplikacji,
  • skryptów uruchomieniowych,
  • konfiguracji ładowanej w runtime,
  • plików, które zostaną później wykonane lub zinterpretowane przez aplikację/środowisko.

W praktyce poziom ryzyka zależy od:

  • topologii wdrożenia (kontenery vs VM vs bare metal),
  • praw dostępu użytkownika systemowego uruchamiającego node,
  • tego, gdzie trzymane są uploady (czy katalog uploadu ma sensowne izolacje),
  • czy endpoint uploadu jest publiczny oraz jak wygląda autoryzacja/limity.

Rekomendacje operacyjne / co zrobić teraz

1) Aktualizacja (najważniejsze)

  • Zaktualizuj @adonisjs/bodyparser do 10.1.2 (lub nowszej) w gałęzi stabilnej.
  • Jeśli używasz pre-release 11.x: zaktualizuj do 11.0.0-next.6 (lub nowszej).

2) Szybki audyt kodu pod kątem podatnego wzorca

Priorytetowo przejrzyj miejsca, gdzie:

  • przyjmujesz upload multipart/form-data,
  • wywołujesz MultipartFile.move(...) bez jawnego options.name,
  • dopuszczasz overwrite: true (albo nie ustawiasz tego parametru).

3) Twarde zasady dla uploadów (defense-in-depth)

Nawet po aktualizacji:

  • Przechowuj uploady poza webrootem (aby nie dało się ich od razu wykonywać/serwować jako kod).
  • Stosuj allowlistę typów (MIME i/lub sniffing), limity rozmiaru, limity liczby plików.
  • Używaj least privilege dla procesu Node.js (konto systemowe bez praw do katalogów aplikacji/konfiguracji).
  • Rozważ read-only filesystem dla kontenera i osobny, izolowany wolumen tylko na uploady.

4) Monitoring i detekcja (co sprawdzić po stronie SOC/ops)

  • Nietypowe zapisy plików poza katalogiem uploadu (auditd/EDR/file integrity monitoring).
  • Zmiany w plikach konfiguracyjnych, startup scriptach, plikach .env, artefaktach buildu.
  • Logi aplikacji i reverse proxy pod kątem podejrzanych nazw plików w multipart (sekwencje ../, %2e%2e%2f, mieszane separatory).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Ten incydent dobrze pokazuje różnicę między:

  • „podatnością w samej walidacji ścieżki” a
  • „podatnością wynikającą z niebezpiecznych domyślnych ustawień API”.

Tutaj kluczowe było to, że bezpieczne zachowanie wymagało od programisty dodatkowej pracy (podania options.name lub sanitacji), a brak tej pracy prowadził do ryzykownego defaultu. Advisory dodatkowo wskazuje, że dokumentacja wcześniej mogła kierować w stronę tej podatnej ścieżki.

To częsty wzorzec w lukach uploadowych: nawet jeśli programista „zapisuje do katalogu uploadów”, wystarczy jedna nieprzemyślana decyzja o budowaniu ścieżki z danych od klienta, aby pojawił się path traversal.

Podsumowanie / kluczowe wnioski

  • CVE-2026-21440 (CVSS 9.2) to krytyczna luka typu path traversal w obsłudze uploadów w @adonisjs/bodyparser, umożliwiająca dowolny zapis/nadpisanie plików na serwerze.
  • Eksploatacja wymaga osiągalnego endpointu uploadu i podatnego użycia MultipartFile.move() bez bezpiecznych opcji.
  • Najlepsza reakcja to natychmiastowa aktualizacja do 10.1.2 (lub 11.0.0-next.6) oraz szybki przegląd miejsc, gdzie aplikacja zapisuje uploady na dysk.

Źródła / bibliografia

  • GitHub Security Advisory: AdonisJS Path Traversal in Multipart File Handling (GHSA-gvq6-hvvp-h34h). (GitHub)
  • NVD / NIST: CVE-2026-21440. (NVD)
  • GitHub Releases: adonisjs/bodyparser v10.1.2 (opis zmiany domyślnej nazwy pliku na uuid). (GitHub)
  • The Hacker News: omówienie podatności i warunków eksploatacji (06 stycznia 2026). (The Hacker News)