Archiwa: NIST - Strona 56 z 69 - Security Bez Tabu

Tag: NIST

Eksploit na „ESXicape”: dlaczego to, że powstał ponad rok przed ujawnieniem, powinno martwić każdego admina VMware

Wprowadzenie do problemu / definicja luki

W marcu 2025 r. VMware (Broadcom) opublikował poprawki na trzy podatności w ESXi/Workstation/Fusion (CVE-2025-22224, CVE-2025-22225, CVE-2025-22226), które były wykorzystywane „in the wild”.

W styczniu 2026 r. analiza incydentu opisana przez Huntress dorzuciła bardzo niepokojący szczegół: narzędzia użyte do ucieczki z maszyny wirtualnej (VM escape) wyglądały na przygotowane ponad rok przed publicznym ujawnieniem tych CVE (na podstawie ścieżek PDB i znaczników czasowych w binariach).

Mówimy więc nie tylko o „kolejnych CVE”, ale o praktycznym scenariuszu: atakujący, po zdobyciu dostępu do jednej VM z uprawnieniami admina, potrafi przejść na poziom hypervisora ESXi i zagrozić wszystkim workloadom na hoście.

W skrócie

  • Podatności: CVE-2025-22224 (TOCTOU/OOB write), CVE-2025-22225 (arbitrary write → escape do kernela), CVE-2025-22226 (OOB read → leak).
  • Warunek: atak wymaga lokalnych uprawnień administracyjnych w VM (czyli najpierw trzeba skompromitować środowisko).
  • Huntress: w obserwowanym łańcuchu wejście miało nastąpić przez skompro-mitowany SonicWall VPN, potem nadużycie konta Domain Admin i dopiero wdrożenie toolkitu do ucieczki z VM.
  • Największy „red flag”: komponenty toolkitu wskazywały na prace rozwojowe co najmniej od listopada 2023 i „deliverable” z lutego 2024.

Kontekst / historia / powiązania

Oficjalne advisory Broadcom (VMSA-2025-0004) jasno mówi, że VMware ma informacje sugerujące aktywną eksploatację wszystkich trzech CVE oraz że nie ma obejść (workarounds) — kluczowe są aktualizacje do wersji naprawionych.

Co istotne, rządowe instytucje ostrzegawcze też potraktowały temat poważnie — np. kanadyjskie Cyber Centre wprost wskazało, że „exploit exists in the wild” dla tej trójki CVE.

Z perspektywy obrony oznacza to jedno: nawet jeśli te luki nie są zdalnym RCE „z internetu”, to w realnych kampaniach są używane jako eskalacja na poziom hypervisora po wcześniejszym przełamaniu perymetru.

Analiza techniczna / szczegóły luki

1) Co dokładnie łata VMSA-2025-0004?

Broadcom opisuje:

  • CVE-2025-22224: TOCTOU prowadzące do out-of-bounds write (krytyczne; maks. CVSS 9.3).
  • CVE-2025-22225: arbitrary write w ESXi; zapis w jądrze przez VMX prowadzący do escape z sandboxa.
  • CVE-2025-22226: out-of-bounds read w HGFS skutkujące wyciekiem pamięci z procesu VMX.

NVD podkreśla kluczowy element modelu ataku dla CVE-2025-22224: wykonanie kodu jako proces VMX na hoście, przy założeniu lokalnych uprawnień admina w VM.

2) Jak wyglądał łańcuch ataku według Huntress?

Huntress opisał wieloetapową operację, w której:

  • atakujący wdraża narzędzia na Windowsowej VM,
  • używa komponentów do obejścia/wyłączenia wybranych mechanizmów (m.in. techniki związane z ładowaniem sterowników),
  • uruchamia „orchestrator” (opisywany jako MAESTRO) do VM escape,
  • a następnie instaluje backdoora na ESXi komunikującego się przez VSOCK (Virtual Sockets), z nasłuchem na porcie 10000 i kanałem trudnym do obserwacji przez klasyczne narzędzia sieciowe.

To ostatnie jest szczególnie ważne operacyjnie: VSOCK omija typowe punkty kontroli (firewall/IDS w sieci), więc detekcja przesuwa się z „patrzmy na pakiety” na „patrzmy na procesy i sockety na hoście ESXi”. Huntress sugeruje m.in. obserwację nietypowych procesów i użycie poleceń typu lsof -a na hostach ESXi do wypatrywania śladów VMCI/VSOCK.

3) Skąd wniosek o „ponad rok przed ujawnieniem”?

Tu nie chodzi o spekulację „ktoś mógł mieć 0-day”, tylko o artefakty w binariach:

  • ścieżki PDB i nazewnictwo katalogów sugerujące „deliverable” dla „all version escape” oraz datę luty 2024,
  • komponent VSOCK związany z pracami z listopada 2023.

W praktyce oznacza to, że exploit (albo przynajmniej platforma eksploatacyjna + post-exploitation) mógł być gotowy, zanim vendor opublikował advisory.

Praktyczne konsekwencje / ryzyko

  1. „VM isolation is not absolute” przestaje być hasłem z prezentacji, a staje się realnym scenariuszem incydentu: kompromitacja jednej VM może przełożyć się na przejęcie hosta ESXi i wszystkich maszyn na nim.
  2. Atak nie musi zaczynać się „od VMware”. W opisywanym przypadku wejście miało być przez urządzenie VPN, a VMware było „drugim krokiem” do osiągnięcia dominacji w środowisku wirtualizacji.
  3. Ryzyko rośnie, gdy:
  • trzymasz wiele krytycznych workloadów na jednym hoście (duży „blast radius”),
  • masz słabą separację ról (admin VM ≈ admin wszystkiego),
  • używasz end-of-life wersji ESXi — Huntress zwraca uwagę, że toolkit obejmował bardzo szeroki przekrój buildów, a EOL oznacza brak poprawek.

Rekomendacje operacyjne / co zrobić teraz

Priorytet 1: poprawki i inwentaryzacja

  • Zweryfikuj podatność względem VMSA-2025-0004 i wgraj wersje naprawione wskazane w „Response Matrix” (dla ESXi/Workstation/Fusion/Cloud Foundation/Telco).
  • Jeśli masz ESXi w wersjach EOL: potraktuj to jako ryzyko nieakceptowalne (brak fixów) i planuj migrację/upgrade.

Priorytet 2: zmniejsz szanse na „local admin w VM”

Ponieważ warunkiem jest admin w VM, w praktyce bronisz się tak samo jak przed ransomware:

  • MFA i hardening na VPN/edge, szybkie łatanie urządzeń brzegowych,
  • redukcja uprawnień Domain Admin, segmentacja, ograniczenie RDP/WinRM,
  • monitorowanie nietypowych zmian zasad zapory w VM i prób „odcięcia” ruchu na zewnątrz (w opisywanym ataku modyfikowano firewall).

Priorytet 3: detekcja na ESXi (nie tylko w sieci)

  • Włącz i centralizuj logi ESXi, monitoruj procesy i nietypowe binaria na datastore.
  • Uwzględnij w playbookach, że kanały typu VSOCK mogą być niewidoczne dla klasycznych sensorów NDR — potrzebujesz telemetrii hostowej.

Różnice / porównania z innymi przypadkami

  • W przeciwieństwie do typowych podatności „remote RCE w vCenter/ESXi”, tutaj punkt ciężkości to escape z gościa do hosta: nie wystarczy „patchuj wystawione na internet”, bo atak może przyjść z wnętrza (po phishingu/VPN/AD).
  • To także przykład, że informacja „exploited in the wild” w advisory bez detali (co często się zdarza) może oznaczać znacznie więcej niż skanowanie — Huntress pokazał dopracowany łańcuch i zaplecze narzędziowe.

Podsumowanie / kluczowe wnioski

  • CVE-2025-22224/22225/22226 to nie „kolejne CVE do backlogu”, tylko zestaw luk, które umożliwiają realny VM escape i przejęcie hypervisora w scenariuszu po naruszeniu perymetru.
  • Najbardziej niepokojący sygnał z analizy Huntress: exploit/toolkit mógł istnieć jako 0-day ponad rok przed publicznym ujawnieniem.
  • Obrona wymaga dwóch równoległych działań: agresywnego patchowania ESXi oraz ograniczania prawdopodobieństwa, że atakujący kiedykolwiek uzyska „admin w VM” (VPN/AD/endpoint).

Źródła / bibliografia

CISA zamyka 10 Emergency Directives: co oznacza „sunset” i dlaczego wygrywa model KEV + BOD 22-01

Wprowadzenie do problemu / definicja luki

8 stycznia 2026 r. CISA (amerykańska agencja ds. cyberbezpieczeństwa) zamknęła jednorazowo aż 10 Emergency Directives (ED) wydanych w latach 2019–2024. W praktyce to „sunset” oznacza, że dyrektywy zostały oznaczone jako zamknięte, bo spełniły swój cel, a wymagane działania są już zrealizowane albo zostały „wchłonięte” przez stały mechanizm zarządzania ryzykiem podatności: KEV (Known Exploited Vulnerabilities) + BOD 22-01.

Warto to czytać szerzej niż jako porządkowanie archiwum: to sygnał, że CISA coraz częściej preferuje ciągły model priorytetyzacji podatności (KEV), zamiast utrzymywania wielu osobnych, kryzysowych nakazów.

W skrócie

  • CISA zamknęła 10 Emergency Directives (2019–2024).
  • Powód: wymagania z dyrektyw są zrealizowane lub zastąpione przez obowiązki wynikające z BOD 22-01 i katalogu KEV.
  • Zamknięte ED dotyczyły m.in. głośnych incydentów/podatności: DNS tampering, SolarWinds Orion, Exchange on-prem, Pulse Connect Secure, Print Spooler, VMware, a także kompromitacji korporacyjnej poczty Microsoft.

Kontekst / historia / powiązania

Emergency Directive to tryb „awaryjny” — narzędzie do szybkiego wymuszenia działań w sytuacji pilnego ryzyka dla amerykańskich agencji federalnych (FCEB). Binding Operational Directive (BOD) jest natomiast mechanizmem „systemowym”: obowiązkową dyrektywą dla agencji federalnych, porządkującą działania w skali całego rządu USA.

Kluczowa zmiana ostatnich lat to przeniesienie ciężaru z reakcji „incydent → osobna dyrektywa” na model „ciągła lista realnie wykorzystywanych podatności + terminy remediacji”. Ten model spina BOD 22-01 i katalog KEV, gdzie priorytetem jest to, co jest faktycznie eksploatowane.

4. Analiza techniczna / szczegóły luki

Jakie 10 ED zostało zamkniętych?

Lista zamkniętych Emergency Directives (wg publikacji podsumowującej zamknięcie):

  1. ED 19-01: Mitigate DNS Infrastructure Tampering
  2. ED 20-02: Mitigate Windows Vulnerabilities from January 2020 Patch Tuesday
  3. ED 20-03: Mitigate Windows DNS Server Vulnerability from July 2020 Patch Tuesday
  4. ED 20-04: Mitigate Netlogon Elevation of Privilege Vulnerability from August 2020 Patch Tuesday
  5. ED 21-01: Mitigate SolarWinds Orion Code Compromise
  6. ED 21-02: Mitigate Microsoft Exchange On-Premises Product Vulnerabilities
  7. ED 21-03: Mitigate Pulse Connect Secure Product Vulnerabilities
  8. ED 21-04: Mitigate Windows Print Spooler Service Vulnerability
  9. ED 22-03: Mitigate VMware Vulnerabilities
  10. ED 24-02: Mitigating the Significant Risk from Nation-State Compromise of Microsoft Corporate Email System

Co je łączy technicznie?

To zestaw dyrektyw skupionych na dwóch klasach ryzyka:

A) „Powszechna technologia + szybka eksploatacja”
Windows/AD (Netlogon), DNS, Print Spooler, Exchange, Pulse Secure, VMware — czyli komponenty, które są masowo wdrażane i często bywają „single point of failure” w środowiskach enterprise.

B) „Incydenty o charakterze kampanii / supply chain / APT”
SolarWinds Orion i kompromitacja systemów pocztowych to przykłady zdarzeń, które wymuszają nie tylko patchowanie, ale też: triage, hunting, segmentację i zmianę praktyk operacyjnych.

Rola KEV: przeniesienie „co robić” do katalogu eksploatowanych CVE

CISA wskazała, że część zamykanych dyrektyw stała się redundantna, bo podatności trafiły do KEV (a więc podlegają reżimowi BOD 22-01). W artykułach o zamknięciu ED wymieniono m.in.: CVE-2020-0601, CVE-2020-1350, CVE-2020-1472, CVE-2021-26855, CVE-2021-34527, CVE-2021-22893 oraz wątek podatności VMware.

W praktyce: zamiast utrzymywać osobną „akcję specjalną” dla każdej dużej podatności, CISA woli dziś dopinać ją do mechanizmu KEV, gdzie kluczowe są terminy remediacji i ciągłe raportowanie postępu.

Praktyczne konsekwencje / ryzyko

Dla agencji federalnych USA: zamknięcie ED nie oznacza „temat nieaktualny”, tylko że działania zostały wykonane albo przechodzą na trwalszy reżim BOD/KEV.

Dla organizacji spoza FCEB (w tym w Polsce): to mocny sygnał trendu:

  • priorytetem nie jest „najwyższy CVSS”, tylko podatność z realną eksploatacją (KEV jako heurystyka ryzyka),
  • procesy bezpieczeństwa powinny działać ciągle, a nie falami po medialnych incydentach.

Ryzyko biznesowe pozostaje takie samo jak w latach, gdy wydawano ED: te klasy podatności (Exchange, VPN, AD/Netlogon, drukowanie, hypervisor/virtualization) regularnie wracają w kampaniach ransomware i APT, bo dają szybki efekt: dostęp, eskalację, lateral movement i trwałość.

Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczny zestaw działań, który „mapuje się” na logikę KEV/BOD, nawet jeśli nie podlegasz CISA:

  1. Zasada 1: KEV jako „fast lane” w VM
    Wprowadź osobny tor obsługi podatności „known exploited”: krótsze SLA, automatyczne eskalacje, raportowanie do właścicieli usług.
  2. Zasada 2: inwentaryzacja > skanowanie
    Większość ED dotyczyła technologii, które często żyją poza standardowym VM (appliance VPN, stare serwery Exchange, klastry vSphere). Upewnij się, że masz rzetelną listę: co mam, gdzie jest, kto jest właścicielem, jak patchuję.
  3. Zasada 3: kompensacje, gdy patch nie wchodzi
    Jeśli nie możesz patchować: odcięcie ekspozycji, segmentacja, WAF/IPS reguły, twarde ograniczenie adminów, monitoring anomalii (np. nietypowe logowania, nowe konta, eksport skrzynek, podejrzane usługi).
  4. Zasada 4: „security hygiene” dla tożsamości i zdalnego dostępu
    ED-y historycznie często dotykały wejść do sieci (VPN, poczta) — wymuś MFA, ogranicz dostęp administracyjny, wprowadź JIT/JEA, przegląd ról, alerty na niestandardowe tokeny/sesje.
  5. Zasada 5: ćwiczenia IR pod scenariusze z listy ED
    Zrób tabletop/blue-team exercise dla: kompromitacji poczty, łańcucha dostaw (SolarWinds), przejęcia AD (Netlogon), RCE w appliance VPN, eskalacji przez Print Spooler.

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

Model „ED” to reakcja punktowa: szybki nakaz na konkretny problem i konkretne wymagania. Model „KEV + BOD 22-01” to reakcja ciągła: stały katalog exploitable + terminy + raportowanie, które skaluje się lepiej niż utrzymywanie wielu równoległych dyrektyw.

To jest dojrzałościowo podobne do ewolucji SOC:

  • od „gaszenia pożarów po alertach”
  • do „zarządzania ryzykiem i ekspozycją w trybie ciągłym”.

Podsumowanie / kluczowe wnioski

  • 8 stycznia 2026 r. CISA zamknęła 10 Emergency Directives z lat 2019–2024.
  • Najważniejsza zmiana to przesunięcie ciężaru na KEV + BOD 22-01 jako stały mechanizm priorytetyzacji i egzekwowania remediacji.
  • Dla organizacji komercyjnych to czytelna wskazówka: w VM i patchingu warto formalnie wyróżniać „known exploited” jako kategorię o najwyższym priorytecie, niezależnie od samego CVSS.

Źródła / bibliografia

  1. The Record (Recorded Future News): informacje o zamknięciu 10 ED, kontekst KEV i lista przykładowych CVE.
  2. BleepingComputer: lista 10 zamkniętych ED oraz opis powiązania z BOD 22-01 i KEV.
  3. NIST (CSRC) – prezentacja dot. BOD 22-01: definicja BOD, obowiązkowość dla agencji federalnych i opis podejścia „katalog KEV + terminy”.

Trend Micro łata krytyczną lukę RCE w Apex Central (CVE-2025-69258) – pilna aktualizacja do Build 7190

Wprowadzenie do problemu / definicja luki

Trend Micro wydało krytyczną poprawkę dla Apex Central (on-premise) na Windows, usuwając podatność umożliwiającą zdalne wykonanie kodu (RCE) bez uwierzytelnienia – CVE-2025-69258. To szczególnie istotne, bo Apex Central jest centralną konsolą zarządzania (m.in. konfiguracją, dystrybucją polityk i aktualizacji) dla innych komponentów bezpieczeństwa Trend Micro, więc kompromitacja serwera zarządzającego często oznacza “dźwignię” do przejęcia większej części środowiska.

W skrócie

  • CVE-2025-69258: krytyczne RCE związane z mechanizmem LoadLibraryEx, pozwalające atakującemu załadować kontrolowaną DLL do kluczowego procesu i uruchomić kod z uprawnieniami SYSTEM.
  • Podatność jest pre-auth (brak wymaganego logowania) i ma CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
  • Poprawka: Critical Patch Build 7190 (i nowsze). Dotyczy instalacji poniżej Build 7190.
  • Wraz z RCE załatano też dwie luki DoS: CVE-2025-69259 i CVE-2025-69260 (obie CVSS 7.5, również możliwe bez uwierzytelnienia).
  • Tenable opublikowało szczegóły techniczne (oraz kontekst podatności), co zwykle zwiększa ryzyko szybkiego pojawienia się prób masowego skanowania i ataków na wystawione instancje.

Kontekst / historia / powiązania

Według informacji producenta, biuletyn bezpieczeństwa dla tej paczki poprawek został zaktualizowany 7 stycznia 2026, a sam wpis CVE w NVD pojawił się 8 stycznia 2026.
Tenable (jako podmiot, któremu Trend Micro dziękuje w biuletynie) przedstawiło też oś czasu odpowiedzialnego ujawnienia – ważne z perspektywy oceny dojrzałości procesu disclosure oraz tego, kiedy informacje techniczne mogły stać się szerzej dostępne.

Analiza techniczna / szczegóły luki

Na czym polega CVE-2025-69258?

W uproszczeniu: podatność dotyczy sytuacji, w której zdalny atakujący może doprowadzić do załadowania kontrolowanej biblioteki DLL do jednego z kluczowych komponentów Apex Central, a w konsekwencji do wykonania kodu w kontekście SYSTEM. Mechanizm jest powiązany z wykorzystaniem LoadLibraryEx.

Gdzie “siedzi” wektor ataku?

Z doniesień branżowych wynika, że istotną rolę odgrywa proces MsgReceiver.exe, który w typowej konfiguracji nasłuchuje na TCP/20001. To istotny szczegół z perspektywy obrony, bo w praktyce wiele organizacji nieświadomie wystawia usługi pomocnicze/agentskie albo pozostawia zbyt szerokie reguły między segmentami.

Co jeszcze załatano w Build 7190?

Trend Micro wskazuje, że Build 7190 usuwa również dwie podatności typu denial of service (CVE-2025-69259 oraz CVE-2025-69260), które także mogą być wyzwalane bez uwierzytelnienia. Choć DoS bywa postrzegany jako “mniej groźny” niż RCE, w systemach zarządzających bezpieczeństwem może prowadzić do realnych przestojów operacyjnych (np. brak dystrybucji polityk/aktualizacji, utrata telemetrii).

Praktyczne konsekwencje / ryzyko

  1. Pełne przejęcie serwera zarządzającego
    RCE wykonywane jako SYSTEM oznacza potencjalnie natychmiastowy “admin-level” na hoście Apex Central, a dalej możliwość kradzieży poświadczeń, lateral movement i manipulacji konfiguracją narzędzi ochronnych.
  2. Wysokie ryzyko dla instancji wystawionych (nawet pośrednio)
    Jeśli port/usługa związana z MsgReceiver.exe jest osiągalna z sieci mniej zaufanych (WAN, DMZ, szerokie VLAN-y, partnerzy), rośnie prawdopodobieństwo ataku “z marszu” – zwłaszcza po publikacji analiz technicznych.
  3. Ryzyko wtórne: sabotaż i “wyłączenie ochrony”
    Kompromitacja konsoli zarządzającej bywa wykorzystywana do: wyłączenia modułów ochronnych, dodania wyjątków, zmiany polityk, a nawet dystrybucji złośliwych artefaktów “zaufanym kanałem” w dół do endpointów (w zależności od architektury i uprawnień integracji).
  4. Sygnały ostrzegawcze dla SOC
    Nawet bez pełnych IOC warto traktować nietypowe: połączenia do TCP/20001, anomalie w zachowaniu procesu MsgReceiver.exe, nietypowe ładowanie DLL, oraz podejrzane połączenia SMB/UNC jako sygnały do triage (szczególnie w oknie tuż po ujawnieniu i publikacji szczegółów).

Rekomendacje operacyjne / co zrobić teraz

Poniżej “checklista”, która jest realistyczna dla zespołów IT/SecOps i pomaga szybko obniżyć ryzyko.

1) Patch management – absolutny priorytet

  • Zaktualizuj Apex Central (on-premise) do Critical Patch Build 7190 lub nowszego.
  • Zweryfikuj wersję po aktualizacji (nie tylko “zainstalowano paczkę”, ale faktyczny build).
  • Jeżeli masz środowiska rozproszone (oddziały/regiony), wymuś kontrolę zgodności (compliance) – ta luka jest wystarczająco poważna, by traktować ją jako “change emergency”.

2) Ogranicz ekspozycję sieciową (szczególnie TCP/20001)

  • Zablokuj dostęp do TCP/20001 z sieci nieadministracyjnych, a najlepiej ogranicz do ściśle wyznaczonych segmentów/hostów (allow-list).
  • Jeśli to możliwe: dostęp administracyjny wyłącznie przez VPN + MFA, z jump hostów (PAW/SAW).

3) Hardening i segmentacja “konsoli zarządzającej”

  • Traktuj serwer Apex Central jak Tier-0 (analogicznie do kontrolerów domeny): osobny segment, minimalne reguły, ograniczony ruch wychodzący.
  • Zredukuj możliwość inicjowania połączeń SMB/UNC do nieznanych zasobów (w praktyce: ograniczenia egress, kontrola DNS, reguły firewall).

4) Monitoring / detekcja (SIR / SOC)

  • Dodaj w SIEM reguły na: nietypowe połączenia do hosta Apex Central (zwłaszcza do usług pomocniczych), nagłe restarty usług, błędy aplikacyjne, oraz anomalie w ładowaniu modułów przez procesy Apex Central.
  • Ustal punkt odniesienia (baseline) dla ruchu sieciowego serwera Apex Central i wykrywaj odchylenia.

5) Przygotuj plan reagowania

  • Jeśli konsola była wystawiona szerzej niż powinna: rozważ szybki przegląd potencjalnych oznak kompromitacji (konto SYSTEM, nowe usługi, scheduled tasks, podejrzane binaria, nietypowe połączenia wychodzące).
  • W razie podejrzeń: izolacja hosta, zrzuty pamięci/logów, i standardowy IR playbook.

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

  • Konsola zarządzająca ≠ zwykły serwer aplikacyjny: podatności w systemach klasy “central management” mają zwykle większy blast radius, bo konsola ma uprawnienia do zarządzania agentami, politykami i aktualizacjami.
  • Pre-auth + wysoki kontekst uprawnień (SYSTEM) to jeden z najbardziej niebezpiecznych duetów: nie wymaga kradzieży poświadczeń, a efekt końcowy bywa równoważny pełnemu przejęciu hosta.
  • Publikacja szczegółów technicznych przez zewnętrzny zespół badawczy (tu: Tenable) często powoduje “drugą falę ryzyka”: nawet jeśli wcześniej nie było informacji o aktywnym wykorzystaniu, to po ujawnieniu rośnie aktywność skanerów i oportunistycznych ataków.

Podsumowanie / kluczowe wnioski

  • CVE-2025-69258 to krytyczna podatność RCE w Trend Micro Apex Central (on-premise) na Windows, z możliwością wykonania kodu jako SYSTEM i bez logowania.
  • Aktualizacja do Build 7190 (lub nowszego) jest działaniem “na już” – zwłaszcza jeśli serwer ma szeroką łączność sieciową.
  • W pakiecie są też dwie podatności DoS, również pre-auth, co dodatkowo wzmacnia argument za szybką aktualizacją.
  • Oprócz patchowania, realną redukcję ryzyka daje segmentacja, ograniczenie ekspozycji usług i monitoring anomalii na serwerze konsoli.

Źródła / bibliografia

  1. Trend Micro – CRITICAL SECURITY BULLETIN: Apex Central (on-premise) January 2026 Multiple Vulnerabilities (KA-0022071)
  2. NIST NVD – CVE-2025-69258 (Źródło)
  3. Tenable Research Advisory – TRA-2026-01 (Apex Central Multiple Vulnerabilities)
  4. BleepingComputer – Trend Micro fixes critical RCE flaw in Apex Central console
  5. Help Net Security – PoC released for unauthenticated RCE in Trend Micro Apex Central (CVE-2025-69258)

Veeam Backup & Replication: poprawki na luki RCE w wersji 13 (CVE-2025-59470 i inne) — co oznaczają i jak się zabezpieczyć

Wprowadzenie do problemu / definicja luki

Veeam Backup & Replication (VBR) to jeden z kluczowych elementów „kręgosłupa” odporności organizacji: jeśli backup pada, ransomware ma łatwiej, a odtwarzanie po incydencie potrafi zamienić się w wielodniowy kryzys. Dlatego każda podatność prowadząca do wykonania kodu (RCE) w środowisku backupowym jest traktowana priorytetowo.

Na początku stycznia 2026 Veeam wydał aktualizację, która łata kilka błędów umożliwiających wykonanie kodu lub nadużycia uprawnień w Veeam Backup & Replication v13. Co ważne: w tym pakiecie mówimy głównie o scenariuszach wymagających wysokich uprawnień (role operatorskie/administracyjne w VBR), ale to wciąż realny problem — bo atakujący często najpierw kradną tożsamości i dopiero potem „dojeżdżają” systemy kopii zapasowych.

W skrócie

  • Dotyczy: Veeam Backup & Replication 13.0.1.180 i wcześniejsze buildy v13.
  • Naprawiono w: Veeam Backup & Replication 13.0.1.1071.
  • Najważniejsze CVE (v13):
    • CVE-2025-59470 — RCE jako postgres przez złośliwe parametry (CVSS 9.0; Veeam „koryguje” ocenę operacyjną ze względu na wymagane role).
    • CVE-2025-55125 — RCE jako root przez złośliwy plik konfiguracji backupu.
    • CVE-2025-59469 — możliwość zapisu plików jako root (nadużycie prowadzące do dalszej eskalacji/utrwalenia).
    • CVE-2025-59468 — RCE jako postgres przy uprawnieniach Backup Administrator (wejście przez parametr hasła).
  • Status exploitacji: brak publicznych informacji o wykorzystaniu tych konkretnych CVE „in the wild” w momencie publikacji komunikatów, ale VBR bywa regularnie celem kampanii ransomware.
  • Rekomendacja: patch ASAP, bo po ujawnieniu poprawek rośnie ryzyko „reverse engineering” i polowania na niezałatane instancje.

Kontekst / historia / powiązania

Backup infrastructure jest atrakcyjnym celem, bo:

  1. daje wgląd w kluczowe systemy i poświadczenia,
  2. pozwala niszczyć kopie lub utrudniać odtwarzanie,
  3. bywa „uprzywilejowana” sieciowo (dużo wyjątków firewall, szeroki dostęp do serwerów).

Nie jest to teoria. W przeszłości podatności w Veeam VBR były wiązane z incydentami ransomware, a media branżowe podkreślają, że atakujący często celują w serwery Veeam jako element „zamykania ofiary w klatce” przed uruchomieniem szyfrowania.

Dobrym przykładem jest CVE-2024-40711 (krytyczne RCE), które NVD opisuje jako podatność umożliwiającą nieautoryzowane wykonanie kodu i odnotowuje jej obecność w katalogu KEV (Known Exploited Vulnerabilities).

Analiza techniczna / szczegóły luki

1) CVE-2025-59470 (CVSS 9.0): RCE jako postgres przy roli Backup/Tape Operator

Veeam opisuje scenariusz jako wykonanie kodu poprzez przesłanie złośliwych parametrów (m.in. „interval”/„order”), co finalnie prowadzi do RCE w kontekście użytkownika postgres.
Istotny niuans: choć metryka CVSS wychodzi „krytyczna”, Veeam operacyjnie obniża „severity response”, bo wymagane role są traktowane jako wysoce uprzywilejowane i powinny być szczególnie chronione.

2) CVE-2025-55125: RCE jako root przez złośliwą konfigurację backupu

W tym przypadku wektorem jest możliwość przygotowania złośliwego pliku konfiguracji backupu, co — przy uprawnieniach Backup/Tape Operator — może dać wykonanie kodu jako root.

3) CVE-2025-59469: zapis plików jako root (nadużycie uprawnień)

Możliwość zapisu plików jako root bywa „półproduktem” do pełnego przejęcia hosta: pozwala np. podmienić skrypty/konfiguracje, dołożyć klucze, zmienić elementy startowe usług, przygotować persistence lub ułatwić późniejsze RCE. Veeam wskazuje, że to scenariusz dostępny dla Backup/Tape Operator.

4) CVE-2025-59468: RCE jako postgres przy roli Backup Administrator

Ten wektor opiera się o złośliwy parametr hasła i wymaga roli Backup Administrator.

Wspólny mianownik: to nie są typowe „pre-auth RCE z internetu”. To raczej podatności, które stają się krytyczne w praktyce, gdy atakujący ma już foothold (skradzione konta, nadużycia uprawnień, kompromitacja AD) i próbuje domknąć przejęcie środowiska.

Praktyczne konsekwencje / ryzyko

Nawet jeśli wymagane są role uprzywilejowane, ryzyko jest wysokie z trzech powodów:

  1. „Privileged access” to częsty etap ataku. W wielu incydentach ransomware napastnicy dochodzą do kont domenowych i ról administracyjnych zanim uderzą w backup.
  2. Kompromitacja VBR to dźwignia na całą organizację. Backup serwer ma zwykle szerokie uprawnienia do systemów produkcyjnych, repozytoriów, hypervisorów i kont serwisowych.
  3. Po publikacji poprawek rośnie presja czasu. Veeam wprost wskazuje, że po ujawnieniu podatności atakujący mogą próbować odtworzyć zmiany i szukać niezałatanych instalacji.

W efekcie: to klasyczna sytuacja „nie ma exploitów teraz” → „ale może się szybko pojawić”, szczególnie w ekosystemie, w którym presja finansowa (ransomware) jest duża.

Rekomendacje operacyjne / co zrobić teraz

Poniżej checklista w stylu „incident-ready” — do wdrożenia nawet bez pełnego programu hardeningu.

1) Patch management (priorytet #1)

  • Zaktualizuj Veeam Backup & Replication v13 do 13.0.1.1071.
  • Zweryfikuj build po aktualizacji (nie zakładaj, że „Windows Update/installer zrobił swoje”).

2) Natychmiastowy przegląd ról i uprawnień w VBR

  • Sprawdź, kto ma Backup Operator / Tape Operator / Backup Administrator. Te role w tym kontekście są „near-admin”.
  • Zmniejsz liczbę kont z tymi rolami (least privilege), wprowadź zasadę „czasowego dostępu” (JIT/JEA) tam, gdzie to możliwe.

3) Kontrola dostępu i segmentacja

  • Ogranicz dostęp sieciowy do serwera VBR (panel/komponenty zarządzające) do stacji administracyjnych i segmentu admin.
  • Wdróż reguły typu „deny by default” z wyjątkami, zamiast szerokich dopuszczeń.

4) Monitoring i detekcja nadużyć

  • Alerty na: dodawanie/zmiany ról w VBR, nietypowe operacje na konfiguracjach backupów, anomalie w usługach i procesach na serwerze Veeam.
  • Korelacja z AD: logowania uprzywilejowane do VBR, zmiany członkostwa grup, nowe konta/klucze.

5) Odporność na ransomware (nie tylko „patch”)

  • Przetestuj odtwarzanie (restore) i scenariusz „backup server compromised”.
  • Upewnij się, że masz kopie „nie do ruszenia” (immutability / offline / air-gap) oraz że proces odtwarzania nie zależy od jednego kompromitowalnego komponentu.

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

Warto zestawić styczniowe CVE (v13) z wcześniejszymi głośnymi podatnościami:

  • Teraz (CVE-2025-59470 i spółka): głównie scenariusze „post-auth” wymagające ról operatorskich/administracyjnych w VBR. To podnosi poprzeczkę, ale nie eliminuje ryzyka, bo przejęcie takich ról jest częstym etapem kampanii ransomware.
  • Wcześniej (np. CVE-2024-40711): NVD opisuje podatność jako umożliwiającą nieautoryzowane RCE i wskazuje jej obecność w KEV, co w praktyce oznacza udokumentowane wykorzystanie w rzeczywistych atakach.
  • CVE-2023-27532: Veeam opisywał ją jako błąd pozwalający nieautoryzowanemu użytkownikowi w obrębie „perymetru infrastruktury backupowej” uzyskać zaszyfrowane poświadczenia z bazy konfiguracyjnej (co bywa krokiem do przejęcia dalszych elementów).

Wniosek praktyczny: nawet jeśli nowe luki nie są „internet-facing pre-auth”, to organizacje nadal powinny traktować je jako wysokopilne, bo konsekwencje kompromitacji backupu są nieproporcjonalnie duże.

Podsumowanie / kluczowe wnioski

  • Veeam załatał cztery podatności w VBR v13, w tym scenariusze prowadzące do RCE (m.in. CVE-2025-59470) oraz nadużyć uprawnień.
  • Poprawka to Veeam Backup & Replication 13.0.1.1071 — jeśli masz v13, to jest update „na już”.
  • Wymagane role są uprzywilejowane, ale to nie „zmniejsza problemu do zera” — w realnych kampaniach atakujący często i tak dochodzą do takich uprawnień, a backup jest jednym z głównych celów.
  • Dodatkowo historia Veeam pokazuje, że podatności bywały wykorzystywane w praktyce (np. CVE-2024-40711).

Źródła / bibliografia

  • Veeam KB: Vulnerabilities Resolved in Veeam Backup & Replication 13.0.1.1071 (Veeam Software)
  • SecurityWeek: Several Code Execution Flaws Patched in Veeam Backup & Replication (SecurityWeek)
  • BleepingComputer: New Veeam vulnerabilities expose backup servers to RCE attacks (BleepingComputer)
  • NVD (NIST): CVE-2024-40711 Detail (NVD)
  • Veeam KB: CVE-2023-27532 (Veeam Software)

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)