Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 418 z 487

Autor: Wojciech Ciemski

React2Shell (CVE-2025-55182): krytyczne RCE w React Server Components już wykorzystywane. Jak się bronić?

Wprowadzenie do problemu / definicja luki

React2Shell (CVE-2025-55182) to nieautoryzowane zdalne wykonanie kodu (RCE) w React Server Components (RSC), wynikające z błędnej deserializacji ładunków trafiających do endpointów Server Functions. Podatność dotyczy m.in. paczek react-server-dom-webpack, react-server-dom-parcel i react-server-dom-turbopack w gałęziach React 19.0.x/19.1.x/19.2.x i otrzymała CVSS 10.0. Zespół React zaleca natychmiastową aktualizację do wersji naprawionych: 19.0.1, 19.1.2 oraz 19.2.1.

W skrócie

  • Co to jest: RCE w RSC przez niebezpieczną deserializację danych dostarczonych w żądaniu HTTP do Server Functions.
  • Status: CISA dodała CVE-2025-55182 do katalogu KEV (Known Exploited Vulnerabilities) 5 grudnia 2025 r.; termin dla agencji federalnych USA: 26 grudnia 2025 r.
  • Eksploatacja: AWS raportuje szybkie próby i ataki grup „China-nexus” (m.in. Earth Lamia, Jackpot Panda) w ciągu godzin od ujawnienia.
  • Skala: Wiz ocenia, że 39% środowisk chmurowych zawiera instancje React/Next.js w wersjach podatnych.
  • Naprawa: React 19.0.1/19.1.2/19.2.1 oraz Next.js 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 (canary 15.6.0 częściowo) i downgrade z błędnych kanarków 14.x.

Kontekst / historia / powiązania

Lukę zgłosił 29 listopada 2025 r. badacz Lachlan Davidson w programie Meta; 3 grudnia opublikowano poprawki i poradnik aktualizacji. Następnie Vercel wydał własne zalecenia dla Next.js i wdrożył reguły WAF jako czasową ochronę. 5 grudnia CISA oficjalnie oznaczyła CVE w katalogu KEV, potwierdzając obserwowaną eksploatację w środowiskach produkcyjnych.

Analiza techniczna / szczegóły luki

Istota problemu to deserializacja nieufnych danych (CWE-502) w implementacji protokołu „Flight” dla RSC. Atakujący może przygotować specjalnie sformatowane żądanie HTTP do endpointu Server Function; podczas dekodowania ładunku dochodzi do wykonania kodu po stronie serwera. Podatne są standardowe konfiguracje RSC – nawet jeśli aplikacja nie definiuje własnych Server Functions, ale wspiera RSC, może być do trafienia.

W wektorze detekcji AWS zwraca uwagę m.in. na charakterystyczne nagłówki i wzorce w treści żądań (np. next-action, rsc-action-id, ciągi $@ oraz "status":"resolved_model"), co pomaga korelować logi i IOC.

Praktyczne konsekwencje / ryzyko

  • Pełne RCE na hostach z podatnymi wersjami React/Next.js (RSC).
  • Masowe skanowanie i szybka weaponizacja PoC po publikacji – potwierdzone telemetrią AWS i obserwacjami wielu zespołów.
  • Ryzyko łańcucha dostaw front-/back-endu: liczne frameworki/bundlery reużywają implementację RSC (Next.js, React Router RSC preview, Waku, wtyczki Vite/Parcel, Redwood SDK).
  • Ekspozycja w chmurze: duże rozpowszechnienie Next.js/React w środowiskach produkcyjnych zwiększa powierzchnię ataku.

Rekomendacje operacyjne / co zrobić teraz

  1. Aktualizacje krytyczne (priorytet najwyższy).
    • React RSC: 19.0.1 / 19.1.2 / 19.2.1.
    • Next.js (App Router): 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7; jeśli używasz kanarków 14.3.0-canary.77+, zjedź do stabilnej 14.x.
  2. Higiena ekspozycji. Ogranicz publiczny dostęp do endpointów RSC/Server Functions (WAF, geofencing, rate limiting), ale nie traktuj WAF jako zastępstwa patcha.
  3. Detekcja i monitoring.
    • Przeglądaj logi pod kątem żądań POST z nagłówkami next-action / rsc-action-id i wzorcami $@, "resolved_model".
    • Szukaj nietypowych procesów potomnych Node/React, prób odczytu /etc/passwd, poleceń rozpoznawczych (whoami, id).
  4. IR i hunting. Jeśli środowisko było narażone, sprawdź: kradzież poświadczeń chmurowych (np. AWS), koparki kryptowalut, web-shelle/sideloadery. Wiz raportuje takie aktywności po udanych exploitach.
  5. Zgodność/KEV. Organizacje objęte politykami zgodności powiązanymi z CISA KEV powinny odnotować daty Added: 2025-12-05 i Due: 2025-12-26 oraz wykazać działania naprawcze.

Różnice / porównania z innymi przypadkami

  • Źródło błędu: logiczna deserializacja w protokole RSC „Flight”, a nie klasyczna injekcja kodu w warstwie aplikacji.
  • Dziedziczenie podatności: wiele frameworków/bundlerów jest podatnych wtórnie, bo reużywa implementację RSC – zbliżone do znanych scenariuszy „upstream vuln → downstream frameworks”.
  • PoC i eksploatacja: bardzo krótka droga od publikacji poradnika do masowych skanów i faktycznych ataków (telemetria AWS/Wiz), co przypomina tempo weaponizacji znane z luk w popularnych komponentach web.

Podsumowanie / kluczowe wnioski

  • To maksymalnie krytyczna luka (CVSS 10.0) w szeroko stosowanym komponencie serwerowym React; patchuj dziś, a nie „w następnym sprincie”.
  • Sama osłona WAF nie wystarczy – aktualizacja jest jedynym trwałym remedium.
  • Zaktywizowały się grupy powiązane z Chinami, a skala użycia Next.js/React w chmurze zwiększa ryzyko incydentów i wtórnych nadużyć (kradzież kluczy, kryptomining, web-shelle).

Źródła / bibliografia

  • React Team: „Critical Security Vulnerability in React Server Components” (03.12.2025) – opis, wersje naprawione, instrukcje aktualizacji. (React)
  • NVD: wpis dla CVE-2025-55182 (aktualizacje 05.12.2025) – opis, CVSS, status w CISA KEV (Added/Due). (NVD)
  • AWS Security Blog: „China-nexus cyber threat groups rapidly exploit React2Shell (CVE-2025-55182)” – telemetria ataków, IOC, zalecenia operacyjne. (Amazon Web Services, Inc.)
  • Wiz Research: „Critical Vulnerabilities in React and Next.js: everything you need to know” – skala ekspozycji (39%), techniczne tło, obserwacje eksploatacji. (wiz.io)
  • Vercel: „Summary of CVE-2025-55182” – lista wersji Next.js z poprawkami i uwagi dot. WAF. (Vercel)

Barts Health NHS ujawnia naruszenie danych po ataku z wykorzystaniem zero-day w Oracle E-Business Suite

Wprowadzenie do problemu / definicja luki

Barts Health NHS Trust (jeden z największych operatorów szpitali w Anglii) poinformował o kradzieży plików z bazy danych po ataku grupy Cl0p, która wykorzystała podatność typu zero-day w Oracle E-Business Suite (EBS). Skasowane dane dotyczą m.in. faktur z wieloletniego okresu i ujawniają imiona, nazwiska oraz adresy osób, które płaciły za leczenie lub usługi. Incydent nie dotknął elektronicznej dokumentacji medycznej ani systemów klinicznych. Zdarzenie miało miejsce w sierpniu 2025 r., a pliki pojawiły się w serwisie wyciekowym Cl0p w listopadzie 2025 r.. 5 grudnia 2025 r. Barts potwierdził sprawę publicznie.

W skrócie

  • Wektor wejścia: zero-day w Oracle E-Business Suite, CVE-2025-61882 (RCE bez uwierzytelnienia przez HTTP).
  • Skutek: kradzież plików z bazy (faktury, dane osób płacących, część byłych pracowników i dostawców).
  • Zakres: dotyczy także plików księgowych usług świadczonych od kwietnia 2024 r. dla Barking, Havering and Redbridge University Hospitals NHS Trust (BHRUT), który opublikował osobny komunikat.
  • Status techniczny: Oracle wydał pilny alert bezpieczeństwa i poprawki dla EBS 12.2.3–12.2.14.
  • Atrybucja i kampania: skoordynowana fala kradzieży i wymuszeń na organizacjach z EBS, analizowana przez Google/Mandiant.

Kontekst / historia / powiązania

Według BleepingComputer, kampania Cl0p celowała globalnie w środowiska Oracle EBS, a lista potwierdzonych ofiar obejmuje m.in. instytucje akademickie i przedsiębiorstwa. W przypadku Barts Health atak wykryto dopiero po publikacji na „leak site” Cl0p; organizacja zapowiedziała uzyskanie sądowego zakazu dalszego rozpowszechniania danych.

Równolegle BHRUT potwierdził, że incydent obejmuje również jego dane, ponieważ kontrakt na system finansowy i Oracle obsługuje dla niego Barts Health. BHRUT podkreśla, że systemy kliniczne i nowy EPR nie zostały naruszone.

Analiza techniczna / szczegóły luki

Oracle opisał CVE-2025-61882 jako zdalnie wykorzystywaną RCE bez uwierzytelnienia w komponencie Oracle Concurrent Processing / BI Publisher Integration, możliwą do wyzwolenia przez HTTP. Luka dotyczy wersji 12.2.3–12.2.14 i posiada bazowy wynik CVSS 9.8. Oracle opublikował wskaźniki kompromitacji (IOCs) oraz zalecił niezwłoczne łatanie.

Analiza Google Threat Intelligence/Mandiant wskazuje, że aktor powiązany z marką CL0P eksploatował łańcuch(y) podatności w EBS co najmniej od 9 sierpnia 2025 r., a wcześniej (lipiec) obserwowano podejrzane próby. Opisano m.in. wektory obejmujące UiServlet i SyncServlet oraz nadużycie XDO Template Manager do osadzenia złośliwych szablonów XSL w bazie EBS, prowadzących do wykonania kodu (implanty Java: GOLDVEIN.JAVA / SAGEGIFT / SAGELEAF / SAGEWAVE).

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla osób: dane adresowe i rozliczeniowe mogą zostać użyte do ataków socjotechnicznych (phishing, vishing, próby wyłudzeń), mimo że same pliki nie dają bezpośredniego dostępu do kont. Barts podkreśla ostrożność wobec niezamówionych próśb o płatność/dane.
  • Ryzyko dla organizacji: masowa eksploatacja publicznie dostępnych aplikacji ERP redukuje konieczność poruszania się po sieci ofiary—sprzyja cichej eksfiltracji danych i falowym kampaniom wymuszeń.
  • Ryzyko prawne/regulacyjne: incydent zgłoszono do ICO; Barts i BHRUT współpracują z NCSC oraz organami ścigania.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów IT/bezpieczeństwa korzystających z Oracle EBS:

  1. Natychmiast zastosuj poprawki Oracle (Alert dla CVE-2025-61882 i późniejsze poprawki dla EBS), w tym wymagane pre-rekwizyty CPU.
  2. Zapoluj na artefakty w bazie EBS: przeszukaj tabele XDO_TEMPLATES_B oraz XDO_LOBS pod kątem nieznanych/malicious szablonów (prefiks TMP/DEF, typ XSL-TEXT/XML) i anomalii w TemplatePreviewPG.
  3. Ogranicz ruch wychodzący z serwerów EBS — zablokuj niepotrzebne połączenia do Internetu (utrudnia to pobieranie 2. etapu i eksfiltrację).
  4. Monitoruj wzorce HTTP do UiServlet / SyncServlet oraz IOC z alertu Oracle (adresy IP, ciągi poleceń, sumy SHA256).
  5. Twarde segmentowanie i kopie zapasowe aplikacji ERP; osobne konta serwisowe i rotacja haseł/kluczy używanych przez EBS. (zalecenie ogólne)

Dla działów ryzyka/zgodności:

  • Ocena DPIA/ryzyka RODO dla procesów finansowych powiązanych z EBS; przygotowanie szablonów komunikacji do osób, których dane mogły zostać naruszone, i kanału wsparcia (FAQ, hotline). (zalecenie ogólne)

Dla osób, których dane mogły zostać ujawnione:

  • Weryfikuj żądania płatności/aktualizacji danych tylko przez znane kanały; zachowaj czujność wobec prób socjotechniki, zgodnie z komunikatami Barts/BHRUT.

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

Kampania wokół Oracle EBS wpisuje się w taktykę znaną z wcześniejszych akcji Cl0p/FIN11 przeciwko MFT (Accellion FTA, GoAnywhere, MOVEit): masowa eksploatacja zero-day aplikacji brzegowych, szybka eksfiltracja, a ekspozycja ofiar i wymuszenia następują po tygodniach. W porównaniu z incydentami MFT, komponenty EBS (np. BI Publisher/XDO) dają inny zestaw wektorów RCE (XSL, servlet’y) i wymagają specyficznych polowań na artefakty w bazie.

Podsumowanie / kluczowe wnioski

  • Incydent w Barts Health NHS i BHRUT to element szerszej fali wymuszeń na użytkownikach Oracle EBS; wektorem był CVE-2025-61882 (RCE, CVSS 9.8). Szybkie łatanie i detekcja artefaktów XDO w bazie są krytyczne.
  • Dane kliniczne nie zostały dotknięte, lecz ryzyko socjotechniki wobec pacjentów/pracowników jest realne.
  • Organizacje z EBS powinny przyjąć model „assume breach” i przeprowadzić threat hunting wg wskazówek Oracle/Mandiant.

Źródła / bibliografia

  1. BleepingComputer — Barts Health NHS discloses data breach after Oracle zero-day hack (05.12.2025). (BleepingComputer)
  2. Barts Health NHS — Cl0p cyberattack update (05.12.2025). (Barts Health NHS Trust)
  3. BHR University Hospitals NHS Trust — Data incident (05.12.2025). (BHR Hospitals)
  4. Oracle — Security Alert Advisory – CVE-2025-61882 (Oracle E-Business Suite) (10.2025). (Oracle)
  5. Google Cloud / Mandiant — Oracle E-Business Suite Zero-Day Exploited in Widespread Extortion Campaign (09–10.2025). (Google Cloud)

Krytyczna podatność XXE w Apache Tika (CVE-2025-66516, CVSS 10.0) – co musisz załatać już teraz

Wprowadzenie do problemu / definicja luki

W Apache Tika ujawniono krytyczną lukę typu XML External Entity (XXE) oznaczoną jako CVE-2025-66516 z oceną CVSS 10.0. Błąd pozwala na XXE poprzez spreparowany plik XFA osadzony w PDF, co dotyka kluczowych modułów Tiki: tika-core, tika-pdf-module oraz tika-parsers. Projekt wskazuje, że usterka jest ściśle powiązana z wcześniejszym problemem (CVE-2025-54988), ale rozszerza zakres dotkniętych pakietów – dlatego wymaga pilnej aktualizacji nie tylko modułu PDF, lecz także rdzenia (tika-core).

W skrócie

  • Zakres podatnych pakietów:
    • org.apache.tika:tika-core 1.13 – 3.2.1 (naprawione w 3.2.2)
    • org.apache.tika:tika-parser-pdf-module 2.0.0 – 3.2.1 (naprawione w 3.2.2)
    • org.apache.tika:tika-parsers 1.13 – 1.28.5 (naprawione od 2.0.0 w górę)
  • Wektor ataku: XXE przez XFA w PDF, możliwy odczyt plików, SSRF, a w niektórych scenariuszach DoS.
  • Dlaczego nowe CVE? Poprzednie (CVE-2025-54988) skupiało się na module PDF; teraz potwierdzono, że problem i fix są w tika-core, a w gałęzi 1.x parser PDF znajdował się w tika-parsers. Użytkownicy, którzy zaktualizowali wyłącznie moduł PDF, wciąż mogli być podatni.
  • Pilne działanie: aktualizacja do Tika 3.2.2 (i odpowiednio do bezpiecznych wersji w gałęzi 2.x) oraz weryfikacja łańcuchów zależności.

Kontekst / historia / powiązania

W sierpniu 2025 ujawniono CVE-2025-54988 – XXE w parserze PDF Tiki. Część organizacji zaktualizowała jedynie moduł PDF, pozostawiając niezałatany tika-core, co utrzymywało okno podatności. Nowe CVE-2025-66516 formalizuje rozszerzony zakres i „zamyka” lukę poprzez wymaganie wersji tika-core ≥ 3.2.2. Dodatkowo w linii 1.x PDFParser był w pakiecie tika-parsers, więc także ten artefakt należy sprawdzić i zaktualizować.

Analiza techniczna / szczegóły luki

Atakujący osadza formularz XFA w dokumencie PDF. Podczas parsowania Tika – zależnie od ścieżki kodu i konfiguracji – może przetworzyć zewnętrzne encje XML (XXE), co umożliwia:

  • odczyt lokalnych plików (np. /etc/passwd, klucze, tokeny),
  • SSRF – wykonywanie żądań HTTP z serwera aplikacji do zasobów wewnętrznych (np. http://169.254.169.254/ w chmurze),
  • w niektórych przypadkach wyciek metadanych i zasobów lub wyczerpywanie zasobów (DoS).
    Problem jest w tika-core, a wejściem bywa moduł PDF; w gałęzi 1.x wejściem mógł być tika-parsers. To tłumaczy, czemu sama aktualizacja modułu PDF nie wystarcza.

Praktyczne konsekwencje / ryzyko

Tika jest powszechnie osadzana w wyszukiwarkach treści, e-discovery, DLP, systemach ETL, serwerach indeksujących, portalach do uploadu plików czy narzędziach bezpieczeństwa. Każda usługa, która przyjmuje PDF od użytkownika i przekazuje do Tiki, może stać się wektorem wycieku danych lub ruchu SSRF do sieci wewnętrznej i usług chmurowych. Instytucje rządowe ostrzegają przed eksfiltracją danych i rekonesansem wewnętrznej sieci przez tę lukę.

Rekomendacje operacyjne / co zrobić teraz

  1. Patch teraz
    • Upewnij się, że tika-core = 3.2.2 (lub nowszy), tika-parser-pdf-module = 3.2.2 (lub nowszy) oraz brak artefaktów 1.x (tika-parsers ≤ 1.28.5) w drzewie zależności. W ekosystemach Maven/Gradle wymuś wersje przez dependencyManagement/constraints.
  2. Przegląd transytywności
    • Audytuj aplikacje, które pośrednio wciągają Tikę (np. przez narzędzia wyszukiwania, DLP, CMS-y, biblioteki importu). Zadbaj o lockfile i raporty mvn dependency:tree/gradle dependencies. (Wnioski z doradców i ekosystemu GitHub Advisory.)
  3. Tymczasowe twardnienie (gdy aktualizacja wymaga okna serwisowego):
    • Odrzuć/izoluj PDF z XFA (np. wstępny „content sniffer” przed Tiką).
    • Sandbox dla procesu parsowania: AppArmor/SELinux, kontenery z restrykcyjnymi profilami, brak dostępu do metadanych chmury, brak sieci lub wyłącznie wyjście przez proxy/egress filter.
    • Limit zasobów (timeouty, limity pamięci/CPU) na pipeline’ach parsowania.
  4. Detekcja i reagowanie
    • Szukaj anomalii: żądania do IMDS (169.254.169.254), nietypowe odczyty plików przez usługę parsującą, nadmiarowe błędy parsera PDF.
    • Dodaj reguły w WAF/IDS (sygnatury PDF z XFA, nietypowe nagłówki/URI).
  5. Testy bezpieczeństwa
    • Przeprowadź testy jednostkowe/integracyjne z próbkami PDF zawierającymi XFA, aby potwierdzić, że aplikacja nie przetwarza zewnętrznych encji po aktualizacji.

Różnice / porównania z innymi przypadkami

  • CVE-2025-54988 vs. CVE-2025-66516: w obu przypadkach wektorem jest XFA w PDF, ale 66516 formalnie poszerza listę podatnych pakietów i wskazuje, że rdzeń (tika-core) zawierał przyczynę – stąd wymóg jego aktualizacji do ≥ 3.2.2. Jeśli załatano tylko moduł PDF, system nadal mógł być podatny.

Podsumowanie / kluczowe wnioski

  • To krytyczna luka (CVSS 10.0) w popularnym komponencie przetwarzania dokumentów.
  • Aktualizacja tika-core do 3.2.2 (oraz modułów PDF) jest warunkiem koniecznym.
  • Przejrzyj wszystkie aplikacje z PDF upload/parsing oraz zależności transytywne – Tika bywa ukryta w wielu platformach.
  • Dodaj kontrole prewencyjne (filtrowanie XFA, sandbox, egress filtering) i monitoring pod kątem SSRF/wycieków.

Źródła / bibliografia

  • The Hacker News – pierwsza publikacja prasowa i zestawienie wersji dotkniętych/naprawionych. (The Hacker News)
  • NVD (NIST) – karta CVE-2025-66516 z oceną CVSS i opisem rozszerzenia zakresu względem CVE-2025-54988. (NVD)
  • GitHub Advisory (GHSA-f58c-gq56-vjjf) – szczegóły: przyczyna w tika-core, konsekwencje „partial patch”, wersje naprawione. (GitHub)
  • Belgian CCB (rządowe CERT) – ostrzeżenie o eksfiltracji danych/SSRF i szerokim użyciu Tiki. (ccb.belgium.be)
  • Strona projektu Apache Tika – ogólne info o wydaniach i bezpieczeństwie (w tym 3.2.2 jako najnowsza linia 3.x). (tika.apache.org)

CISA dodaje krytyczną lukę „React2Shell” (CVE-2025-55182) do katalogu KEV — co to oznacza dla zespołów bezpieczeństwa

Wprowadzenie do problemu / definicja luki

CISA dodała do katalogu Known Exploited Vulnerabilities (KEV) jedną nową, aktywnie wykorzystywaną podatność: CVE-2025-55182, znaną jako „React2Shell”. To nieuwierzytelniona RCE (remote code execution) w mechanizmie React Server Components (RSC), oceniona na CVSS 10.0. Dla agencji FCEB wyznaczono termin remediacji na 26 grudnia 2025 r. zgodnie z BOD 22-01.

W skrócie

  • Rodzaj luki: pre-auth RCE w protokole „Flight” dla RSC.
  • Dotyczy: ekosystemu React 19 i pakietów react-server-dom- (webpack/parcel/turbopack)* w określonych wersjach.
  • Skutki: zdalne wykonanie dowolnego kodu na serwerze przy użyciu spreparowanych żądań HTTP.
  • Status: CISA włączyła do KEV (aktywnie wykorzystywana), termin remediacji do 26.12.2025.
  • Łatki: dostępne aktualizacje dla pakietów RSC oraz wskazane wersje naprawcze w popularnych frameworkach (np. Next.js).

Kontekst / historia / powiązania

Zespół React ujawnił błąd 3 grudnia 2025 r. wraz z poradnikiem aktualizacji. Wkrótce potem liczne firmy i zespoły badawcze potwierdziły powagę podatności, a CISA dodała ją do KEV jako aktywnie wykorzystywaną w kampaniach wymierzonych w aplikacje używające RSC.

Analiza techniczna / szczegóły luki

Podstawą problemu jest niebezpieczna deserializacja ładunków przy obsłudze Server Function endpoints w RSC. Podatność występuje (co najmniej) w wersjach 19.0.0, 19.1.0, 19.1.1, 19.2.0 pakietów:

  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
    W efekcie nieuwierzytelnowany napastnik może dostarczyć specjalnie spreparowany payload i doprowadzić do wykonania własnego kodu po stronie serwera.

Wersje naprawcze i wpływ na frameworki

Dostępne są wydania naprawcze pakietów RSC (linie 19.0.1 / 19.1.2 / 19.2.1). Dodatkowo vendorzy frameworków z ekosystemu React publikują swoje aktualizacje i wskazówki — np. Next.js. Zestawienie wersji naprawczych i zaleceń znajdziesz w przeglądzie przygotowanym przez Tenable.

Praktyczne konsekwencje / ryzyko

  • Przejęcie serwera aplikacyjnego: wykonanie dowolnego kodu z uprawnieniami procesu serwera.
  • Ruch bez logowania użytkownika: atak nie wymaga uwierzytelnienia, co zwiększa powierzchnię ataku.
  • Łańcuchy ataków: RCE na warstwie aplikacji może służyć do instalacji web-shelli, pivotów do sieci wewnętrznej i eksfiltracji danych.
  • Presja czasu: wpis do KEV oznacza aktywną eksploatację i wymusza szybkie działania operacyjne (termin CISA dla FCEB: 26.12.2025).

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowe aktualizacje:
    • Zaktualizuj pakiety RSC do wersji naprawczych (19.0.1 / 19.1.2 / 19.2.1).
    • Zastosuj najnowsze wersje frameworków (np. Next.js) zgodnie z matrycą wersji naprawczych.
  2. Szybka weryfikacja ekspozycji:
    • Zidentyfikuj aplikacje używające React Server Components (w tym środowiska test/stage).
    • Przeglądnij reguły WAF i IDS/IPS pod kątem wzorców dla „React2Shell”; pamiętaj, że WAF nie zastąpi patcha.
  3. Higiena i monitoring:
    • Przejrzyj logi HTTP, wykryj nietypowe żądania do endpointów Server Functions.
    • Poszukaj artefaktów post-exploitation (web-shelle, nowe procesy, outbound C2).
  4. Tymczasowe ograniczenia ryzyka (jeśli patch ASAP niemożliwy):
    • Ogranicz lub wyłącz endpointy Server Functions / RSC w narażonych aplikacjach.
    • Zastosuj segmentację sieciową i ograniczenia egress.
  5. Zgodność z KEV/BOD 22-01 (agencje FCEB): zaplanuj remediację do 26.12.2025 i raportuj status zgodnie z procedurami.

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

W odróżnieniu od wielu błędów XSS/RCE w warstwie klienckiej, CVE-2025-55182 atakuje serwerową część stosu React (RSC/Flight), dzięki czemu omija typowe bariery jak CSRF czy autoryzacja użytkownika — to zwiększa prawdopodobieństwo pełnego przejęcia serwera. Wpis do KEV oraz raporty branżowe wskazują na prawdziwe nadużycia „in the wild”, a nie tylko teoretyczny wektor.

Podsumowanie / kluczowe wnioski

  • „React2Shell” (CVE-2025-55182) to krytyczna, aktywnie wykorzystywana pre-auth RCE w RSC.
  • Patchuj natychmiast: zaktualizuj pakiety RSC i frameworki; WAF traktuj jedynie jako wsparcie.
  • CISA KEV + BOD 22-01 wyznaczają twardy termin (dla FCEB: 26.12.2025), co powinno stać się również benchmarkiem dla prywatnych organizacji.

Źródła / bibliografia

  • React Team — „Critical Security Vulnerability in React Server Components” (pakiety i wektor RCE). (React)
  • NVD: CVE-2025-55182 — opis i zakres wersji. (NVD)
  • Tenable: przegląd techniczny + wersje naprawcze RSC/Next.js. (Rapid7)
  • CyberScoop: potwierdzenie dodania do CISA KEV i kontekst operacyjny. (CyberScoop)
  • CISA KEV Catalog: wpis i termin remediacji: 26.12.2025; BOD 22-01. (CISA)

Cloudflare: globalna awaria spowodowana „React2Shell” — co poszło nie tak i co robić teraz

Wprowadzenie do problemu / definicja luki

5 grudnia 2025 r. Cloudflare doświadczył globalnej degradacji usług po wdrożeniu awaryjnych reguł WAF mających zablokować krytyczną lukę w React Server Components, znaną jako React2Shell (CVE-2025-55182). Błąd umożliwia nieautoryzowane RCE i jest aktywnie wykorzystywany — m.in. przez grupy powiązane z Chinami — co zmusiło dostawców do szybkich (i ryzykownych) mitygacji.

W skrócie

  • Co się stało? Zmiana w sposobie parsowania żądań przez WAF Cloudflare (mitigacje na React2Shell) spowodowała krótki brak dostępności sieci i błędy HTTP 500 na wielu serwisach. Nie był to atak.
  • Kiedy? 5 grudnia 2025 r.; Reuters podaje okno od 08:47 do 09:13 GMT (09:47–10:13 czasu polskiego).
  • Dlaczego tak krytyczne? CVE-2025-55182 ma CVSS 10.0, dotyczy popularnych RSC i jest eksploatowane „w godzinach” od publikacji.
  • Czy są łatki? Tak — zaktualizowano linie React 19.x oraz frameworki korzystające z RSC; Cloudflare ogłosił automatyczne reguły WAF dla klientów.

Kontekst / historia / powiązania

Po ujawnieniu luki 3 grudnia, społeczność dostała zalew PoC-ów, a zespoły threat-intel (m.in. AWS) zaobserwowały szybkie kampanie skanowania i prób eksploatacji przez aktorów państwowych. W odpowiedzi duzi dostawcy (Cloudflare, AWS i inni) wprowadzali protekcje po stronie brzegowej. To wprost poprzedzało piątkową awarię Cloudflare, która — według doniesień głównych mediów — była efektem „twardych” mitygacji, a nie wrogiej akcji.

Analiza techniczna / szczegóły luki

CVE-2025-55182 dotyczy React Server Components (RSC) i błędów logiki w protokole wymiany danych („Flight”), co w pewnych domyślnych konfiguracjach pozwala napastnikowi na zdalne wykonanie kodu bez uwierzytelnienia. Zasięg jest duży, bo RSC są zaadoptowane w popularnych frameworkach (np. Next.js 15/16). Publiczne exploity pojawiły się szybko po disclosure.

Cloudflare 3 grudnia ogłosił, że automatycznie wdrożył reguły WAF chroniące przed atakami na tę klasę błędów — to te reguły, po doraźnych modyfikacjach 5 grudnia, doprowadziły do incydentu dostępności.

Praktyczne konsekwencje / ryzyko

  • Ryzyko natychmiastowe: masowe skanowanie i próby RCE, w tym przez aktorów „China-nexus” wskazanych przez AWS. Ryzyko dotyczy serwisów internetowych korzystających z RSC — nawet jeśli nie wystawiają świadomie endpointów funkcji serwerowych.
  • Ryzyko wtórne (operacyjne): szybkie, globalne mitygacje w WAF/CDN mogą wywołać regresję i niedostępność (jak u Cloudflare), jeśli nie są wdrażane etapowo i z canary/„safe rollout”.

Rekomendacje operacyjne / co zrobić teraz

  1. Patchuj natychmiast: zaktualizuj React 19.x do wersji z poprawką i frameworki wykorzystujące RSC (np. Next.js). Sprawdź noty wydawnicze własnej linii. Równolegle zaimplementuj back-porty, jeśli pełna aktualizacja jest chwilowo niemożliwa.
  2. Włącz/zweryfikuj reguły WAF: upewnij się, że Twoje WAF/CDN (Cloudflare i inne) mają aktywne reguły blokujące wektory React2Shell — oraz że wdrażasz je stopniowo (canary, staged rollout, region-by-region) z telemetrią błędów 4xx/5xx.
  3. Monitoring i detekcja: dodaj reguły wykrywające anomalie w ruchu RSC/Flight (nietypowe nagłówki/ładunki), skoki w odpowiedziach 500 oraz nowe procesy potomne w warstwie aplikacyjnej. Odwołuj się do IOC i wskazówek od vendorów (AWS/Tenable itd.).
  4. Segmentacja i zasada najmniejszych uprawnień: uruchamiaj komponenty serwerowe w izolacji, z minimalnymi uprawnieniami i egress-kontrolą, aby ograniczyć skutki ewentualnego RCE.
  5. Plan awaryjny dla WAF/CDN: procedury „break-glass”, szybki rollback konfiguracji i testy chaos-engineering dla zmian bezpieczeństwa wpływających na ścieżkę danych w produkcji.

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

W odróżnieniu od typowych „konfig-awarii” CDN, piątkowy incydent został bezpośrednio wywołany zmianami bezpieczeństwa w reakcji na aktywnie eksploatowaną lukę 0-day-like. Dla porównania, niedawne wcześniejsze awarie Cloudflare (i innych dostawców) wynikały z błędów konfiguracyjnych lub aktualizacji infrastruktury bez presji natychmiastowego zagrożenia. Tutaj presja czasu zwiększyła ryzyko regresji.

Podsumowanie / kluczowe wnioski

  • React2Shell to krytyczny RCE z szybkim „weaponization”; priorytetem są łatki i mitygacje brzegowe.
  • Zmiany bezpieczeństwa też psują — wprowadzaj je kontrolowanie (canary, automatyczny rollback, SLO-aware).
  • WAF ≠ panaceum: konieczne są aktualizacje kodu oraz telemetria wykrywania nadużyć specyficznych dla RSC/Flight.
  • Komunikacja i odporność: ćwicz scenariusze „hot-patch under fire”, aby nie powielać efektu domina z 5 grudnia.

Źródła / bibliografia

  • SecurityWeek: „Cloudflare Outage Caused by React2Shell Mitigations” (5 XII 2025) — potwierdza związek awarii z mitygacjami. (SecurityWeek)
  • Blog Cloudflare: „WAF proactively protects against React vulnerability” (3 XII 2025) — tło mitygacji WAF. (The Cloudflare Blog)
  • Reuters: czas trwania i przyczyna (zmiana firewall/WAF), brak oznak ataku. (Reuters)
  • BleepingComputer: opis błędów 500 i wyjaśnienie Cloudflare po incydencie. (BleepingComputer)
  • AWS Security Blog: obserwacje eksploatacji przez aktorów „China-nexus”. (Amazon Web Services, Inc.)

PRC „Brickstorm”: chińskie grupy APT z backdoorem na vSphere i Windows. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

4 grudnia 2025 r. CISA, NSA i kanadyjski Cyber Centre opublikowały raport analizy złośliwego oprogramowania (MAR) opisujący BRICKSTORM – niestandardowy backdoor (Go/ELF) używany przez państwowo wspieranych aktorów z ChRL do długotrwałej obecności w sieciach ofiar. Główne cele to sektor publiczny (Government Services & Facilities) oraz firmy IT. Malware obsługuje środowiska VMware vSphere (vCenter/ESXi) i ma również warianty dla Windows.

W skrócie

  • Wejście i trwałość: implant na hostach vCenter/ESXi, modyfikacja plików startowych, watchdog autorestartu/reinstalacji. Średnia „dwell time” w wykrytych operacjach liczona była w miesiącach, a w niektórych przypadkach przekraczała rok.
  • C2 i ukrywanie: wielowarstwowe szyfrowanie (HTTPS/WebSockets/nested TLS), DNS-over-HTTPS do rozwiązywania adresów C2, imitacja ruchu serwerów.
  • Cele i skala: rząd i IT w USA/Kanadzie; media i badacze informują o dziesiątkach organizacji i działaniach o charakterze szpiegowskim z potencjałem sabotażu.
  • Środowiska wirtualne: po przejęciu vCenter napastnicy klonują snapshoty VM (ekstrakcja poświadczeń) i mogą tworzyć ukryte, „rogue” VM.

Kontekst / historia / powiązania

Kampania wpisuje się w długofalową aktywność APT z Chin opisywaną wspólnie przez CISA/NSA (np. wcześniejsze CSA nt. kompromitacji sieci krytycznych), ale BRICKSTORM to świeży komponent zwiększający trwałość w warstwie wirtualizacji. Niezależnie, Google Threat Intelligence (GTIG) i Mandiant raportowały jesienią 2025 r. aktywność „Brickstorm”/pokrewnych narzędzi z długim czasem utrzymania dostępu (~393 dni), szczególnie w branżach prawnej, SaaS i BPO.

Analiza techniczna / szczegóły luki

Wejście i ruch boczny. W incydencie IR opisanym przez CISA napastnicy:

  • dostali się na serwer web w DMZ (poprzez web shell),
  • użyli kont usługowych do RDP na kontrolery domeny (kopie NTDS.dit),
  • zdobyli poświadczenia MSP i przeszli do vCenter,
  • eskalowali uprawnienia (sudo), zrzucili BRICKSTORM do /etc/sysconfig/ i zmodyfikowali plik init rozruchu vSphere, aby uruchamiać implant przy starcie,
  • uzyskali dostęp do dwóch DC oraz serwera ADFS (eksport kluczy kryptograficznych). Z persystencją co najmniej od kwietnia 2024 do 3 września 2025.

Funkcje BRICKSTORM.

  • Backdoor (Go/ELF): interaktywny shell, operacje na plikach (upload/download/list/create/delete), tryb SOCKS proxy do tunelowania i ruchu bocznego.
  • C2 i maskowanie: HTTPS/WebSockets + DoH do rozwiązywania C2, „web server mimicry” do wtapiania się w normalny ruch.
  • Trwałość: watchdog samonaprawy (restart/reinstalacja po zakłóceniu).
  • Warianty: próbki dla vSphere; istnieją raporty o wersjach Windows.
  • Reguły detekcji: pakiet YARA/Sigma do pobrania z MAR.

Cele specyficzne dla wirtualizacji. Po wejściu do vCenter aktorzy:

  • klonują snapshoty wrażliwych VM dla ekstrakcji haseł/kluczy,
  • tworzą ukryte VM, które bywają pomijane przez standardowe monitorowanie,
  • utrwalają obecność modyfikując ścieżki startowe usług vSphere.

Praktyczne konsekwencje / ryzyko

  • Ryzyko utraty integralności tożsamości (eksport kluczy ADFS, kradzież biletów/claims) i długotrwałe „życie w chmurze” atakującego w środowiskach wirtualnych.
  • Utrata widoczności SOC: DoH, WebSockets i „mimikra” HTTP utrudniają klasyczne IOCs/IDS.
  • Potencjał sabotażu: dostęp uprzywilejowany do warstwy wirtualizacji umożliwia szybkie, szerokie skutki (np. wyłączanie klastrów, manipulacja storage). Organy USA i Kanady ostrzegają, że operacje mają wymiar szpiegowski, ale niosą ryzyko zakłóceń.

Rekomendacje operacyjne / co zrobić teraz

Detekcja i polowanie

  1. Wdróż reguły z MAR (YARA/Sigma); przejrzyj wyniki retro (24+ m-ce) w SIEM/EDR/NDR.
  2. Analityka DoH: wyłapuj nietypowe zapytania DoH (destynacje niezwiązane z Twoim resolverem), koreluj z WebSockets i długimi połączeniami TLS.
  3. Telemetry vSphere:
    • zmiany w /etc/sysconfig/ i skryptach init na ESXi/vCenter,
    • nietypowe operacje clone/snapshot VM,
    • tworzenie nierejestrowanych/ukrytych VM,
    • użycie sudo na appliance’ach vCenter.
  4. AD/ADFS: hunting pod kątem kopiowania NTDS.dit, dostępu do ADFS i eksportu kluczy.

Hardening i kontrola powierzchni ataku

  1. Segmentacja i zasada „rzadkich rąk” do vCenter (MFA, PAM/JIT, brak stałych kont usługowych MSP w prod).
  2. Monitoring i kontrola DoH: preferuj własne, autoryzowane resolvery DoH/DNS; blokuj „dzikie” endpointy DoH na brzegu.
  3. Zasady snapshotów: ogranicz prawo do clone/snapshot, alertuj o masowych/pozaschematowych operacjach.
  4. Łatanie i konfiguracja vSphere/Windows, w tym aktualne appliance’y, rotacja certyfikatów i HSTS/TLS hardening na brzegach proxy. (Inference na bazie wytycznych CISA/NSA dot. krytycznej infrastruktury.)

Odpowiedź na incydent (IR) – minimalny playbook

  • Izolacja vCenter/ESXi (odseparowane sieci zarządzające, odcięcie dostępu z kont zewnętrznych/MSP).
  • Zrzuty i triage: pamięć + dysk vCenter/ESXi; weryfikacja plików init i ścieżek w /etc/sysconfig/.
  • AD/ADFS: natychmiastowa rotacja kluczy ADFS, przegląd trustów, audyt kont usługowych i SPN.
  • Korekta polityk DoH/HTTP proxy, wymuszanie resolwera korporacyjnego.
  • Zgłoszenie do CISA/Cyber Centre; użycie udostępnionych IOC/Sigma.

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

W porównaniu do wcześniejszych kampanii PRC opisywanych przez CISA/NSA (routery, urządzenia brzegowe), BRICKSTORM celuje w warstwę wirtualizacji i tożsamość (AD/ADFS), łącząc długą persystencję z trudnym do wykrycia C2 (DoH/WebSockets). To przesunięcie „w dół” stosu (hypervisor/zarządzanie) zwiększa wpływ i utrudnia odzyskanie środowiska.

Podsumowanie / kluczowe wnioski

  • BRICKSTORM to ukierunkowany backdoor na vSphere/Windows pozwalający APT z ChRL na wielo-miesięczną obecność.
  • Operacje na vCenter/ESXi (clone/snapshot, rogue VM) i kradzież kluczy ADFS podnoszą ryzyko eskalacji domenowej i łańcuchowych kompromitacji.
  • Widoczność na DoH/WebSockets i telemetria vSphere to teraz krytyczne obszary detekcji.
  • Wdrożenie reguł YARA/Sigma z MAR, hardening tożsamości i segmentacji vCenter to „must-do” dla SOC/IT.

Źródła / bibliografia

  1. CISA/NSA/Cyber Centre – Malware Analysis Report: BRICKSTORM Backdoor, 4 grudnia 2025 (TLP:CLEAR). Najpełniejszy opis próbek, TTP, IOC, reguły YARA/Sigma.
  2. CISA – komunikat: CISA, NSA and Cyber Centre Warn Critical Infrastructure of BRICKSTORM malware…, 4 grudnia 2025. (cisa.gov)
  3. Google Threat Intelligence – Brickstorm espionage campaign (analiza GTIG/Mandiant), 24 września 2025. (Google Cloud)
  4. CyberScoop – Expansive, ongoing China espionage threat riding on Brickstorm, 4 grudnia 2025. (CyberScoop)
  5. Reuters – Chinese-linked hackers use ‘Brickstorm’ back door…, 4 grudnia 2025 (kontekst medialny i skala). (Reuters)

Hakerzy wykorzystują nową lukę w ArrayOS AG VPN do podkładania webshelli — co muszą zrobić zespoły SOC

Wprowadzenie do problemu / definicja luki

JPCERT/CC ostrzega, że co najmniej od sierpnia 2025 r. aktywni napastnicy wykorzystują nienazwaną jeszcze (bez CVE) podatność typu command injection w Array AG Series (ArrayOS AG), aby instalować webshelle i zakładać fałszywe konta na bramach SSL VPN. Luka dotyczy instalacji z włączonym modułem DesktopDirect; producent wydał poprawkę w maju 2025 r. (ArrayOS AG 9.4.5.9), ale wiele urządzeń pozostaje niezałatanych.

W skrócie

  • Dotyczy: Array AG/vxAG z ArrayOS AG ≤ 9.4.5.8, gdy DesktopDirect jest włączony.
  • Wykorzystanie: wstrzyknięcie komend (command injection) prowadzące do webshelli w katalogu /ca/aproxy/webapp/ i tworzenia nowych użytkowników.
  • Eksploatacja obserwowana od: 08.2025; ostrzeżenie JPCERT/CC z 03.12.2025.
  • Poprawka: ArrayOS AG 9.4.5.9 (zalecana aktualizacja) + obejścia (wyłączenie DesktopDirect, filtr URL blokujący średnik ;).
  • IOC: ruch z 194.233.100[.]138.

Kontekst / historia / powiązania

Urządzenia Array AG już wcześniej padały ofiarą krytycznych luk RCE. W listopadzie 2024 CISA dodała do katalogu KEV błąd CVE-2023-28461 (brak uwierzytelniania dla funkcji krytycznych), nakazując pilne łatanie. Osobno, w grudniu 2023 ujawniono CVE-2023-51707 w komponencie MotionPro (RCE przed 9.4.0.505). Obie historyczne luki pokazują, że bramy AG są atrakcyjnym celem i wymagają rygorystycznego zarządzania wersjami. Nowy, bieżący wektor (DesktopDirect) nie ma jeszcze przypisanego CVE.

Analiza techniczna / szczegóły luki

  • Warunek: włączony DesktopDirect (zdalny dostęp do pulpitów).
  • Wektor: wysyłka złośliwych żądań HTTP, które skutkują wstrzyknięciem komend po stronie urządzenia.
  • Efekt:
    • zapis pliku PHP webshell w /ca/aproxy/webapp/,
    • tworzenie nowych kont administratora/użytkownika,
    • użycie bramy jako przyczółka do dalszego ruchu lateralnego.
  • Artefakty & IOC: ruch z 194.233.100[.]138 wskazany przez JPCERT; atakujący używają średnika ; w ścieżkach URL (dlatego zalecana reguła filtrująca).
  • Wersje narażone: ArrayOS AG 9.4.5.8 i starsze; naprawa w 9.4.5.9.

Uwaga: Producent opublikował również w 2025 r. osobne ostrzeżenie o RCE w MotionPro (inny komponent/ścieżka naprawy, fix w 9.4.0.519, tymczasowe obejście: vpn motionpro off). To inna podatność niż obecnie eksploatowana luka w DesktopDirect, ale podkreśla konieczność aktualizacji wszystkich gałęzi 9.x.

Praktyczne konsekwencje / ryzyko

  • Utrata poufności i integralności: webshell na bramie VPN daje trwały dostęp do ruchu i konfiguracji.
  • Ruch lateralny: brama SSL VPN często ma uprzywilejowaną pozycję w sieci.
  • Trudna detekcja: restart urządzenia może wyczyścić logi, co utrudnia pełne dochodzenie.
  • Ryzyko łańcuchowe: nielatane starsze błędy (np. CVE-2023-28461) mogą być łączone z nową luką.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa inwentaryzacja
    Zidentyfikuj wszystkie bramy AG/vxAG i sprawdź wersję ArrayOS AG oraz stan DesktopDirect.
  2. Aktualizacja oprogramowania
    • Jeśli używasz gałęzi 9.4.5.x — zaktualizuj do 9.4.5.9 (wersja z poprawką wskazana przez JPCERT/CC).
    • Zweryfikuj także starsze komponenty (np. MotionPro) i rozważ przejście na wydania z poprawkami (≥9.4.0.519 dla RCE w MotionPro; ≥9.4.0.505 wg NVD dla CVE-2023-51707).
  3. Obejścia (jeśli aktualizacja chwilowo niemożliwa)
    • Wyłącz DesktopDirect (jeśli nieużywany).
    • W URL filtering zablokuj dostęp do adresów zawierających ;.
  4. Hunting & IR (24–48h)
    • Sprawdź, czy w /ca/aproxy/webapp/ nie pojawiły się pliki .php.
    • Przejrzyj listę kont pod kątem nieautoryzowanych użytkowników.
    • Przeanalizuj logi sieciowe pod kątem ruchu z/do 194.233.100[.]138.
    • Jeśli musisz zrestartować urządzenie (np. po aktualizacji), zabezpiecz logi wcześniej (JPCERT ostrzega o możliwej utracie dzienników).
  5. Twardnienie dostępu do VPN
    • Ogranicz dostęp do panelu administracyjnego do zaufanych adresów IP.
    • Wymuś MFA dla użytkowników zdalnych.
    • Segmentuj sieć tak, aby brama nie była jedynym punktem wejścia do zasobów krytycznych. (Dobre praktyki uzupełniające do powyższych źródeł.)

Różnice / porównania z innymi przypadkami

  • Obecna luka (DesktopDirect, 2025, brak CVE): aktywnie wykorzystywana w Japonii, specyficzne IOCs (path webshella, IP, ; w URL), fix 9.4.5.9.
  • CVE-2023-28461 (KEV, 2024): brak uwierzytelnienia dla funkcji krytycznych, szeroko nagłaśniana przez CISA; ogólne RCE na AG/vxAG ≤ 9.4.0.481.
  • CVE-2023-51707 (MotionPro, 2023/2025): RCE w komponencie MotionPro; różne minimalne wersje naprawcze (NVD: ≥9.4.0.505; biuletyn Array: ≥9.4.0.519 dla konkretnego wydania), inny wektor niż DesktopDirect.

Podsumowanie / kluczowe wnioski

  • Jeżeli używasz ArrayOS AG ≤ 9.4.5.8 i DesktopDirect jest aktywny, traktuj to jako incydent bezpieczeństwa z wysokim prawdopodobieństwem kompromitacji.
  • Zaktualizuj do 9.4.5.9, wyłącz DesktopDirect jeśli nie jest wymagany i przeszukaj urządzenie pod kątem webshelli oraz fałszywych kont.
  • Zweryfikuj także, czy wcześniejsze luki (CVE-2023-28461, CVE-2023-51707) są zamknięte — część środowisk AG 9.x może wymagać kilku aktualizacji w różnych gałęziach.

Źródła / bibliografia

  1. JPCERT/CC (03.12.2025): ostrzeżenie o aktywnej eksploatacji luki w Array AG (DesktopDirect), wersje podatne, IOCs, zalecenia (update do 9.4.5.9, wyłączenie DesktopDirect, filtr ;). (jpcert.or.jp)
  2. BleepingComputer (04.12.2025): przegląd zdarzeń, potwierdzenie webshelli i kont rogue, streszczenie JPCERT. (BleepingComputer)
  3. CISA KEV (25.11.2024): wcześniejsza, niezależna luka CVE-2023-28461 na AG/vxAG — kontekst historyczny i wymóg łatania. (cisa.gov)
  4. NVD (CVE-2023-51707): RCE w MotionPro (inna luka), minimalne wersje naprawcze wg NVD. (NVD)
  5. Array Networks Security Advisory (09.2025): biuletyn producenta dla MotionPro RCE z fixem 9.4.0.519 i obejściem vpn motionpro off — ważne dla pełnego twardnienia gałęzi 9.x. (support.arraynetworks.net)