Archiwa: Admin - Strona 18 z 33

Fortinet łata krytyczne luki „FortiCloud SSO login auth bypass” (CVE-2025-59718, CVE-2025-59719). Co musisz zrobić teraz

Wprowadzenie do problemu / definicja luki

Fortinet opublikował poprawki dla dwóch krytycznych podatności, które umożliwiają ominięcie uwierzytelniania FortiCloud SSO w wielu produktach: FortiOS, FortiProxy, FortiSwitchManager (CVE-2025-59718) oraz FortiWeb (CVE-2025-59719). Atak możliwy jest z sieci (bez uwierzytelnienia) poprzez spreparowany komunikat SAML, który zostaje błędnie uznany za prawidłowo podpisany kryptograficznie.

W skrócie

Wektor: sieć / brak uwierzytelnienia; ominięcie logowania SSO FortiCloud przez fałszywe odpowiedzi SAML.
Produkty: FortiOS, FortiProxy, FortiSwitchManager (CVE-2025-59718) oraz FortiWeb (CVE-2025-59719).
Ciężar: CVSS v3.1 9.8 (Critical) (dla CVE-2025-59719 wg NVD).
Domyślna ekspozycja: funkcja FortiCloud SSO nie jest domyślnie włączona; może się aktywować w procesie rejestracji do FortiCare, jeśli administrator nie wyłączy przełącznika.
Mitigacja natychmiastowa: wyłącz FortiCloud SSO do czasu aktualizacji do wersji niepodatnych.

Kontekst / historia / powiązania

Urządzenia Fortinet są regularnie wykorzystywane w kampaniach APT i ransomware (często jako zero-day). W 2025 r. głośne były m.in. masowe nadużycia błędów FortiWeb (CVE-2025-64446/58034). Dzisiejsze luki w SSO wpisują się w ten trend – funkcje tożsamości i zdalnego zarządzania to atrakcyjny cel dla napastników.

Analiza techniczna / szczegóły luki

Sednem obu CVE jest „improper verification of cryptographic signature” (CWE-347) w ścieżce przetwarzania SAML. Odpowiedź SAML, która powinna być podpisana przez zaufanego IdP, może zostać zaakceptowana mimo fałszerstwa – to prowadzi do ominięcia FortiCloud SSO i uzyskania dostępu administracyjnego.
Zakres wersji podatnych (wybór najważniejszych gałęzi wg NVD / agregatorów):

CVE-2025-59718 (FortiOS/FortiProxy/FortiSwitchManager):
FortiOS 7.6.0–7.6.3, 7.4.0–7.4.8, 7.2.0–7.2.11, 7.0.0–7.0.17;
FortiProxy 7.6.0–7.6.3, 7.4.0–7.4.10, 7.2.0–7.2.14, 7.0.0–7.0.21;
FortiSwitchManager 7.2.0–7.2.6, 7.0.0–7.0.5.
CVE-2025-59719 (FortiWeb):
FortiWeb 8.0.0; 7.6.0–7.6.4; 7.4.0–7.4.9.

Fortinet podkreśla, że FortiCloud SSO nie jest włączone w ustawieniach fabrycznych. Włącza się podczas rejestracji do FortiCare, o ile administrator nie odznaczy przełącznika „Allow administrative login using FortiCloud SSO”. To krytyczna informacja dla oceny ekspozycji.

Praktyczne konsekwencje / ryzyko

Jeśli FortiCloud SSO jest aktywne, dowolny z Internetu atakujący może ominąć logowanie i uzyskać pełne uprawnienia administracyjne w dotkniętym urządzeniu (firewall/WAF/proxy/switch manager). To otwiera drogę do:

zmiany konfiguracji i reguł filtracji,
wdrożenia backdoorów (np. zmian w politykach lub skryptach),
pivotu do innych segmentów sieci i eksfiltracji danych.

Rekomendacje operacyjne / co zrobić teraz

Wyłącz FortiCloud SSO (jeśli włączone) natychmiast, a następnie zaplanuj aktualizację do wersji niepodatnych wg PSIRT.
- GUI: System → Settings → przełącz “Allow administrative login using FortiCloud SSO” na Off.CLI: config system global set admin-forticloud-sso-login disable end
Zaktualizuj FortiOS/FortiProxy/FortiSwitchManager/FortiWeb do wydań z poprawką dla FG-IR-25-647. Gdy strona PSIRT będzie dostępna, zweryfikuj konkretne „Solution” wersje i matryce zgodności.
Przegląd audytowy:
- Sprawdź, gdzie faktycznie włączono FortiCloud SSO (nie zakładaj ustawień domyślnych po rejestracji do FortiCare).
- Przejrzyj logi uwierzytelniania i administracyjne pod kątem anomalii (logowania bez korelacji z IdP).
- Wymuś rotację haseł/tokenów administratorów oraz odśwież SAML metadata na IdP po aktualizacji.
Twardnienie dostępu zarządczego:
- Ogranicz trusted hosts i segmentację dla interfejsów zarządczych.
- Wymuś MFA poza SSO (lokalne konto break-glass, out-of-band).
- Rozważ tymczasowe odseparowanie portów zarządczych od Internetu (VPN z certyfikatami + allow-list).
Atak powierzchniowy – redukcja: jeśli musisz utrzymać SSO, włącz monitoring integralności SAML i alerty korelujące błędy weryfikacji podpisu/issuer.
Zarządzanie ryzykiem dostawcy: uwzględnij nowe CVE w asset discovery i inwentaryzacji – skanery (np. RunZero/Tenable) już wykrywają podatne wersje.

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

Wcześniejsze głośne incydenty Fortinet (np. FortiWeb CVE-2025-64446) dotyczyły błędów w panelach zarządzania prowadzących m.in. do tworzenia kont admina. Nowe CVE uderzają w warstwę federacji tożsamości (SAML/SSO) – skutkiem jest ominięcie logowania bezpośrednio na bramie, co bywa jeszcze trudniejsze do wykrycia, jeśli logi IdP nie pokazują próby logowania.

Podsumowanie / kluczowe wnioski

Dwie krytyczne luki (CVE-2025-59718/59719) pozwalają ominąć FortiCloud SSO w wielu produktach Fortinet.
Ekspozycja występuje tylko, gdy FortiCloud SSO jest włączone – ale może zostać automatycznie aktywowane podczas rejestracji do FortiCare, jeśli nie odznaczono przełącznika.
Działanie natychmiastowe: wyłącz SSO FortiCloud i aktualizuj do wersji podanych w FG-IR-25-647; zweryfikuj logi i wzmocnij dostęp administracyjny.

Źródła / bibliografia

BleepingComputer – „Fortinet warns of critical FortiCloud SSO login auth bypass flaws”, 9 grudnia 2025. (BleepingComputer)
NVD – CVE-2025-59718 (FortiOS/FortiProxy/FortiSwitchManager): opis i zakres wersji. (NVD)
NVD – CVE-2025-59719 (FortiWeb): opis, CVSS, zakres wersji. (NVD)
Fortinet PSIRT (FG-IR-25-647) – strona doradcza (matryca rozwiązań; chwilowo zdarzają się błędy 5xx). (fortiguard.com)
runZero – szybka identyfikacja aktywów Fortinet dotkniętych CVE-2025-59718/59719 (listy wersji). (runZero)

Ivanti łata krytyczną podatność RCE w Endpoint Manager (CVE-2025-10573). Co powinni zrobić administratorzy?

Wprowadzenie do problemu / definicja luki

Ivanti poinformowało o krytycznej podatności w Endpoint Manager (EPM), oznaczonej jako CVE-2025-10573. Błąd klasy stored XSS pozwala nieuprzywilejowanemu atakującemu wstrzyknąć złośliwy JavaScript, który po wyświetleniu przez administratora skutkuje przejęciem jego sesji — a w konsekwencji może prowadzić do pełnego zdalnego wykonania kodu (RCE) z uprawnieniami admina narzędzia. Luka została załatana w wydaniu EPM 2024 SU4 SR1.

W skrócie

Identyfikator: CVE-2025-10573 (CVSS 9.6 wg zgłaszającego)
Wpływ: przejęcie sesji admina EPM → potencjalnie RCE i pełna kontrola nad zarządzanymi stacjami
Warunki: dostęp do primary EPM web service + interakcja admina (wyświetlenie zainfekowanej konsoli)
Wersje: dotyczy wersji do EPM 2024 SU4 włącznie; patch w EPM 2024 SU4 SR1
Status: brak potwierdzonej eksploatacji w momencie publikacji, ale w Internecie widoczne są setki instancji EPM wystawionych publicznie
Działanie: pilna aktualizacja do EPM 2024 SU4 SR1 i schowanie EPM z Internetu (tylko dostęp zaufany/VPN)

Kontekst / historia / powiązania

Według doniesień prasowych Ivanti EPM bywał celem ataków, a CISA wielokrotnie dodawała luki w EPM do wykazów KEV, nakazując szybkie łatanie. To wpisuje się w szerszy trend regularnych podatności w ekosystemie Ivanti (EPM, EPMM, Connect Secure). Aktualna luka (grudzień 2025) pojawia się po serii wcześniejszych biuletynów i kampanii przeciw produktom Ivanti.

Analiza techniczna / szczegóły luki

Badacz z Rapid7 zidentyfikował wektor: nieautoryzowane dodanie „fałszywych” endpointów do serwera EPM poprzez web API incomingdata (CGI postcgi.exe), z polami skanu zawierającymi payload JS. Dane trafiają do bazy i są niebezpiecznie osadzane w interfejsie WWW administratora (np. frameset.aspx, db_frameset.aspx). Gdy admin wyświetli skażony widok, następuje wykonanie kodu JS w kontekście jego sesji (stored XSS). Rapid7 przytacza przykład żądania POST oraz pokazuje miejsca wykonania payloadu w UI.

Ivanti potwierdza, że problem rozwiązano w EPM 2024 SU4 SR1. NVD opisuje błąd jako stored XSS wymagający interakcji użytkownika, ale możliwy do wyzwolenia przez zdalnego, nieautoryzowanego napastnika.

Praktyczne konsekwencje / ryzyko

Przejęcie konsoli EPM: sesja admina = możliwość zdalnego sterowania hostami zarządzanymi, instalacji oprogramowania, zmian konfiguracji i lateral movement w domenie.
Ekspozycja w Internecie: choć EPM „nie powinien” być wystawiany publicznie, Shadowserver identyfikuje setki dostępnych z sieci instancji — co dramatycznie obniża barierę ataku.
Łańcuchy ataków: przejęta konsola EPM bywa „multiplikatorem mocy” dla atakujących (dystrybucja narzędzi, ransomware, kradzież poświadczeń, wyłączanie EDR). Wcześniejsze incydenty z produktami Ivanti pokazują, że realna eksploatacja często następuje szybko po publikacji łat.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast zaktualizuj do EPM 2024 SU4 SR1 (wersja zawiera poprawkę CVE-2025-10573). Zweryfikuj sukces aktualizacji na wszystkich core serverach.
Usuń ekspozycję EPM do Internetu. Konsola i endpointy powinny być dostępne wyłącznie przez sieci zaufane/VPN/ZTNA. Zweryfikuj dostępność portów i adresów publicznych (np. skanem z zewnątrz). Shadowserver publicznie raportuje widoczne instancje EPM — traktuj to jako ryzyko wysokie.
Tymczasowe twardnienie przed aktualizacją (gdy patching wymaga okna serwisowego):
- Ogranicz dostęp do /incomingdata/postcgi.exe tylko z sieci agentów/zarządzanych hostów.
- WAF/Reverse proxy: filtracja znaków cudzysłowów i <script> w polach skanów, CSP/X-Content-Type-Options, włączenie HttpOnly/SameSite dla ciasteczek sesyjnych (redukcja skutków XSS). (Działania doraźne – nie zastępują patcha). (na podstawie opisu wektora od Rapid7)
Monitoring i detekcja:
- Przejrzyj logi serwera pod kątem nietypowych żądań POST do incomingdata/postcgi.exe i nagłych „fal” rejestracji urządzeń.
- Szukaj artefaktów XSS w polach inwentarzowych, alertów EDR w kontekście procesu przeglądarki u adminów oraz nietypowych akcji konsoli (zdalne instalacje, skrypty). (wynika z mechaniki luki)
Segmentacja i zasada najmniejszych uprawnień: ogranicz liczbę kont admina EPM; stosuj MFA/SSO; rozdzielaj role „konsola” vs. „deployment”. (dobre praktyki ogólne)
Testy podatności: jeżeli korzystasz z Rapid7 (InsightVM/Nexpose/Exposure Command), użyj najnowszych treści detekcyjnych z 9 grudnia 2025. Inne skanery również już publikują sygnatury (NVD/Tenable).

Różnice / porównania z innymi przypadkami

Ten przypadek (CVE-2025-10573) różni się od wcześniejszych RCE w Ivanti EPM/EPMM tym, że stanem początkowym jest stored XSS + interakcja admina, ale efektywnie pozwala osiągnąć podobną dominację co klasyczne RCE po przejęciu sesji.
Ekspozycja ma kluczowe znaczenie: jak pokazują dane Shadowserver, samo „wystawienie” paneli zarządzania zwiększa powierzchnię ataku — w poprzednich falach dotyczących produktów Ivanti ataki szybko następowały po publikacji.

Podsumowanie / kluczowe wnioski

Luka CVE-2025-10573 w Ivanti EPM jest krytyczna: umożliwia przejęcie sesji admina i potencjalne pełne RCE na środowisku zarządzania.
Łatka jest dostępna: EPM 2024 SU4 SR1. Wdrożenie należy traktować priorytetowo.
Nigdy nie wystawiaj EPM bezpośrednio do Internetu. Zastosuj segmentację, kontrolę dostępu i monitoruj anomalia w żądaniach do incomingdata.

Źródła / bibliografia

BleepingComputer – „Ivanti warns of critical Endpoint Manager code execution flaw”, 9 grudnia 2025. (BleepingComputer)
Rapid7 – „CVE-2025-10573: Ivanti EPM Unauthenticated Stored Cross-Site Scripting (Fixed)”, 9 grudnia 2025 (analiza techniczna, PoC request). (Rapid7)
NVD – rekord CVE-2025-10573 (opis i klasyfikacja). (NVD)
Ivanti – „December 2025 Security Update” (komunikat miesięczny z ujawnieniem luk w EPM). (ivanti.com)
Shadowserver – statystyki widocznych w Internecie instancji Ivanti EPM. (dashboard.shadowserver.org)

Firefox 146 łata krytyczne luki: WebRTC UAF, sandbox escape w CanvasWebGL i obejście SOP (MFSA 2025-92)

Wprowadzenie do problemu / definicja luki

Mozilla opublikowała MFSA 2025-92, zestaw poprawek bezpieczeństwa dla Firefox 146, który zamyka m.in. use-after-free w WebRTC (CVE-2025-14321), ucieczkę z sandboxa w CanvasWebGL (CVE-2025-14322), eskalację uprawnień w DOM Notifications (CVE-2025-14323) oraz obejście Same-Origin Policy (CVE-2025-14331). Część błędów ma status „high”, a podatności pamięciowe standardowo mogą prowadzić do zdalnego wykonania kodu.

W skrócie

Aktualizacja: przejdź do Firefox 146 (stabilny) lub odpowiednich wydań ESR 115.31 / 140.6.
Najpoważniejsze wektory: WebRTC (UAF), CanvasWebGL (sandbox escape), Request Handling (obejście SOP).
Dotknięte wersje: w zależności od CVE – przeważnie Firefox < 146, a dla części błędów także ESR < 115.31 i/lub ESR < 140.6.

Kontekst / historia / powiązania

Wersja Firefox 146 została udostępniona 9 grudnia 2025 r. i oprócz funkcjonalnych zmian zawiera zestaw istotnych łatek bezpieczeństwa opisanych w MFSA 2025-92. Linie ESR otrzymały równoległe poprawki (MFSA 2025-93 / 2025-94), co jest kluczowe dla środowisk korporacyjnych z długim cyklem testów.

Analiza techniczna / szczegóły luki

CVE-2025-14321 — WebRTC: Signaling (use-after-free, „high”)
Błąd użycia po zwolnieniu pamięci w ścieżce sygnalizacji WebRTC. Dotyczy Firefox < 146 oraz ESR < 140.6; w sprzyjających warunkach może prowadzić do korupcji pamięci i wykonania kodu.

CVE-2025-14322 — Graphics: CanvasWebGL (sandbox escape, „high”)
Nieprawidłowe warunki brzegowe umożliwiają ucieczkę z sandboxa podczas przetwarzania WebGL. Dotyczy Firefox < 146, ESR < 115.31 oraz ESR < 140.6. To szczególnie groźne w scenariuszach z aktywną treścią 3D/graficzną.

CVE-2025-14323 — DOM: Notifications (privilege escalation, „high”)
Błąd w obsłudze API powiadomień DOM mogący skutkować eskalacją uprawnień. Wpływa na Firefox < 146 oraz obie linie ESR (zależnie od buildów).

CVE-2025-14331 — Request Handling (Same-Origin Policy bypass, „moderate”)
Możliwe obejście SOP, co otwiera drogę do nieautoryzowanego odczytu zasobów między domenami w określonych warunkach. Wpływa na Firefox < 146, ESR < 115.31 i ESR < 140.6.

Inne poprawki: m.in. błędy w JIT (CVE-2025-14324/30), GMP A/V UAF (CVE-2025-14326), Downloads Panel (spoofing, CVE-2025-14327), Netmonitor (priv-esc, CVE-2025-14328/29) oraz zbiorcze „memory safety bugs” w 146 i ESR 140.6.

Praktyczne konsekwencje / ryzyko

RCE przez treści webowe: UAF oraz błędy bezpieczeństwa pamięci (w tym JIT) tradycyjnie dają realne ścieżki do zdalnego wykonania kodu po wejściu na złośliwą stronę.
Izolacja naruszona: CanvasWebGL z obejściem sandboxa potencjalnie przełamuje model ochrony procesu treści.
Wycieki danych między domenami: obejście SOP może umożliwić ataki cross-origin (np. kradzież danych z zalogowanych aplikacji).
Środowiska korporacyjne (ESR): część podatności dotyka ESR, więc opóźnianie rolloutów zwiększa okno ekspozycji. Organizacje powinny traktować aktualizację jako pilną.

Rekomendacje operacyjne / co zrobić teraz

Natychmiastowa aktualizacja przeglądarek:
- Stabilny kanał: do Firefox 146.
- ESR: do 115.31 i/lub 140.6 – zgodnie z Twoją linią wdrożeniową.
Weryfikacja zgodności w przedsiębiorstwie: użyj Firefox for Enterprise Release Notes do oceny wpływu zmian na polityki, GPO, rozszerzenia i narzędzia.
Higiena dodatków i treści: ogranicz/monitoruj obciążające ścieżki (WebRTC, WebGL) w krytycznych stacjach do czasu pełnego rolloutu; egzekwuj polityki about:policies oraz CSP tam, gdzie to możliwe. (Wniosek ogólny oparty o naturę błędów.)
Monitorowanie i detekcja anomalii:
- crash-logi procesów content/GPU w okolicy Canvas/WebGL,
- nietypowe żądania cross-origin (sygnał prób obejścia SOP),
- incydenty z udziałem WebRTC/Notifications. (Wniosek operacyjny.)
Zarządzanie ryzykiem użytkowników wysokiego profilu: przyspiesz aktualizacje na stacjach adminów, deweloperów oraz zespołów z dostępem do danych wrażliwych.

Różnice / porównania z innymi przypadkami

Podobnie jak w poprzednich wydaniach, Mozilla zbiorczo oznacza „memory safety bugs” jako potencjalnie prowadzące do RCE — to standard w ich biuletynach. Nowością tej tury jest konstelacja trzech krytycznych obszarów naraz: WebRTC, CanvasWebGL i SOP.
Linie ESR są aktualizowane równolegle (115.31 / 140.6), co podkreśla wagę poprawek dla środowisk z wydłużonym cyklem wsparcia.

Podsumowanie / kluczowe wnioski

Zaktualizuj teraz: Firefox 146 i odpowiednie ESR zamykają luki o potencjale RCE, sandbox escape i naruszeniu SOP.
Najwyższy priorytet w firmach: luki dotykają ESR, więc rollout powinien być traktowany jako pilny task bezpieczeństwa.
Monitoruj symptomy: awarie procesów treści/GPU, anomalie cross-origin i aktywność WebRTC/Notifications.

Źródła / bibliografia

Mozilla Foundation Security Advisory MFSA 2025-92 – „Security Vulnerabilities fixed in Firefox 146”. (9 grudnia 2025). (Mozilla)
Firefox 146 – Release Notes (9 grudnia 2025). (firefox.com)
NVD – wpis CVE-2025-14321 (WebRTC UAF). (NVD)
NVD – wpis CVE-2025-14322 (CanvasWebGL sandbox escape). (NVD)
Mozilla MFSA 2025-93 (ESR 115.31) – powiązane łatki/wersje ESR. (Mozilla)

SAP łata trzy krytyczne luki w wielu produktach (grudzień 2025)

Wprowadzenie do problemu / definicja luki

9 grudnia 2025 r. SAP opublikował biuletyn Security Patch Day z 14 nowymi notami bezpieczeństwa, w tym trzema lukami o randze „Critical”. Poprawki obejmują m.in. SAP Solution Manager, SAP Commerce Cloud (komponenty Tomcat) oraz SAP jConnect (SDK for ASE). SAP zaleca natychmiastowe wdrożenie aktualizacji we wszystkich środowiskach.

W skrócie

CVE-2025-42880 (CVSS 9.9) — code injection w SAP Solution Manager ST 720; błąd walidacji wejścia może prowadzić do pełnego przejęcia systemu po stronie serwera przez uwierzytelnionego atakującego.
CVE-2025-55754 (CVSS 9.6) — podatności w Apache Tomcat wykorzystywanym przez SAP Commerce Cloud (powiązana także CVE-2025-55752); problem z nieprawidłowym „ucieczkowaniem” sekwencji ANSI w logach konsolowych. Zalecana aktualizacja Tomcat do 9.0.109 / 10.1.45 / 11.0.11.
CVE-2025-42928 (CVSS 9.1) — deserialization w SAP jConnect (SDK for ASE 16.0.4, 16.1); w określonych warunkach użytkownik z wysokimi uprawnieniami może osiągnąć RCE przygotowanym wejściem.

Kontekst / historia / powiązania

Zestaw poprawek wpisuje się w trend intensywnego łatana krytycznych błędów w ekosystemie SAP. W 2025 r. obserwowano już ataki in-the-wild na inną lukę typu wstrzyknięcie kodu w SAP (CVE-2025-42957), co zwiększa ryzyko szybkiego instrumentowania świeżo ujawnianych usterek.
Niezależne analizy (Onapsis) wskazują, że część z grudniowych „HotNews” dotyczy komponentów o dużym zasięgu i złożonych zależnościach (np. Tomcat w SAP Commerce Cloud), co komplikuje priorytetyzację i wymusza spójne zarządzanie wersjami.

Analiza techniczna / szczegóły luki

CVE-2025-42880 — SAP Solution Manager (ST 720), CVSS 9.9

Brak właściwej sanitacji danych wejściowych przy wywołaniu remote-enabled function module umożliwia uwierzytelnionemu atakującemu wstrzyknięcie kodu i przejęcie kontroli nad systemem (CIA: H/H/H; wektor AV:N/AC:L/PR:L/UI:N/S:C).

CVE-2025-55754 (+ CVE-2025-55752) — Apache Tomcat w SAP Commerce Cloud, CVSS 9.6

Tomcat niepoprawnie przetwarza sekwencje ANSI w logach; na konsolach Windows wspierających kolorowanie możliwa jest manipulacja konsolą/Schowkiem i nakłonienie administratora do uruchomienia poleceń. SAP agreguje podatności w notę #3683579 dla wersji HY_COM 2205, COM_CLOUD 2211, COM_CLOUD 2211-JDK21. Naprawa: podniesienie Tomcat do wersji 9.0.109 / 10.1.45 / 11.0.11.

CVE-2025-42928 — SAP jConnect (SDK for ASE 16.0.4/16.1), CVSS 9.1

Błąd deserializacji niezaufanych danych (CWE-502) pozwala, „w określonych warunkach”, użytkownikowi o wysokich uprawnieniach wywołać RCE poprzez specjalnie przygotowane dane wejściowe (wektor AV:N/AC:L/PR:H/UI:N/S:C).

Praktyczne konsekwencje / ryzyko

Przejęcie instancji SolMana i eskalacja w całym krajobrazie SAP (monitoring, konfiguracja, integracje), co może skutkować trwałym naruszeniem integralności procesów biznesowych.
Ryzyka łańcuchowe w e-commerce — podatny Tomcat w SAP Commerce Cloud zwiększa powierzchnię ataku na krytyczne procesy (konta klientów, zamówienia, ceny, integracje ERP/CRM).
RCE w warstwie łącznikowej (jConnect) może ułatwić atakującym pivot do systemów bazodanowych i exfiltrację danych o wysokiej wartości.

Rekomendacje operacyjne / co zrobić teraz

Priorytetyzacja wg wpływu i ekspozycji:
- 1. CVE-2025-42880 (SolMan ST 720) — natychmiastowe wdrożenie noty #3685270.
  1. CVE-2025-55754/55752 — aktualizacja Tomcat do 9.0.109 / 10.1.45 / 11.0.11 w komponentach SAP Commerce Cloud (nota #3683579). Zweryfikuj wszystkie instancje (również EOL).
  1. CVE-2025-42928 — zastosuj notę #3685286; przejrzyj łańcuchy połączeń i uprawnienia kont używanych przez jConnect.
Tymczasowe osłony (jeśli patch window jest ograniczone):
- Ogranicz dostęp do funkcji zdalnych w SolMan (RFC), segmentacja sieci, dodatkowa MFA dla kont technicznych.
- W Commerce Cloud: wyłącz uruchamianie w konsoli, przekieruj logi Tomcat do plików/siem, wymuś aktualne runtimes.
- Dla jConnect: allow-list źródeł połączeń, walidacja danych, monitorowanie nietypowych ładunków serializacyjnych.
Detekcja i monitoring:
- Szukaj w SIEM m.in. nieoczekiwanych wywołań RFC/RFM w SolMan, nietypowych wzorców w logach Tomcat (sekwencje ESC[), anomalii w ruchu JDBC/jConnect. (Mapowanie do CVE wg biuletynu SAP i NVD).
Higiena wersji:
- Porównaj wersje Tomcat z tabelami „Security” producenta; utrzymuj min. 9.0.109/10.1.45/11.0.11.
Procesy DevSecOps:
- Dodaj testy regresyjne pod kątem deserializacji/escape sequences w CI, włącz skanowanie zależności i SCA.

Różnice / porównania z innymi przypadkami

Atakowalność: SolMan (PR:L) jest groźny, bo uderza w centralny system ALM z wysokimi uprawnieniami i szerokimi integracjami. jConnect wymaga PR:H, ale skutki RCE są systemowe. Tomcatowe CVE w Commerce Cloud ma profil bardziej „admin-tricking” (manipulacja konsolą), jednak w środowiskach operacyjnych może prowadzić do wykonania poleceń przez operatora.
Porównanie z tegorocznymi kampaniami: w 2025 r. widzieliśmy już aktywną eksploatację innej krytycznej luki SAP (CVE-2025-42957) — to sygnał, że „time-to-exploit” dla ekosystemu SAP skraca się po publikacji poprawek.

Podsumowanie / kluczowe wnioski

Grudniowy Patch Day SAP przynosi 3 krytyczne luki o szerokim wpływie na krajobraz SAP (ALM, e-commerce, warstwa łącznikowa DB). Patchuj niezwłocznie.
Dla SAP Commerce Cloud aktualizacje Tomcat do 9.0.109/10.1.45/11.0.11 są kluczowe, a zarządzanie wersjami powinno objąć wszystkie środowiska.
Utrzymuj detekcję anomalii i kontrolę uprawnień — wcześniejsze incydenty pokazują, że luki SAP szybko trafiają na radar aktorów zagrożeń.

Źródła / bibliografia

SAP Security Patch Day — December 2025 (lista not, wersje, CVSS). (SAP Support Portal)
BleepingComputer: „SAP fixes three critical vulnerabilities across multiple products”. (omówienie i kontekst). (BleepingComputer)
NVD: CVE-2025-42880 (Solution Manager), CVE-2025-42928 (jConnect), CVE-2025-55754 (Tomcat). (NVD)
Apache Tomcat Security — wersje naprawcze 9.0.109 / 10.1.45 / 11.0.11. (tomcat.apache.org)
Onapsis — Patch Day (grudzień 2025) — analiza i priorytetyzacja „HotNews”. (Onapsis)

Krytyczna podatność w Apache Tika prowadzi do XXE — co trzeba załatać już dziś (CVE-2025-66516)

Wprowadzenie do problemu / definicja luki

W Apache Tika ujawniono krytyczną podatność XXE (XML External Entity Injection) oznaczoną jako CVE-2025-66516 i ocenioną na CVSS 10.0. Błąd umożliwia atakującemu wstrzyknięcie zewnętrznych encji XML poprzez spreparowany plik PDF zawierający XFA, co może prowadzić do odczytu wrażliwych plików, SSRF, a nawet Denial-of-Service. Luka dotyczy kluczowych modułów Tiki i została skorygowana w najnowszych wydaniach projektu.

W skrócie

CVE-2025-66516 (CVSS 10.0) — XXE w Tice wyzwalane przez PDF z XFA.
Dotyczy m.in.: tika-core (1.13–3.2.1), tika-pdf-module (2.0.0–3.2.1), tika-parsers (1.13–1.28.5).
Źródło problemu leży w tika-core; samo podniesienie wersji parsera PDF nie wystarczało. Naprawa wymaga aktualizacji tika-core ≥ 3.2.2.
Luka rozszerza wcześniejsze CVE-2025-54988 – obecny wpis obejmuje więcej pakietów/gałęzi 1.x.

Kontekst / historia / powiązania

W sierpniu 2025 r. Apache Tika załatała XXE w module tika-parser-pdf-module (CVE-2025-54988). Późniejsza analiza wykazała jednak, że wektor wejścia był w PDF-parserze, lecz istotą podatności był kod w tika-core. Stąd drugi wpis CVE-2025-66516, który poszerza zakres dotkniętych pakietów, w tym gałąź 1.x (gdzie PDFParser znajdował się w „tika-parsers”). To wyjaśnia przypadki, w których organizacje zaktualizowały sam PDF-parser, a i tak pozostały podatne.

Analiza techniczna / szczegóły luki

Podatność polega na niewłaściwym przetwarzaniu zewnętrznych encji XML podczas analizy PDF-ów zawierających formularze XFA. W praktyce napastnik może osadzić w PDF odwołania do file://, http(s):// czy innych schematów, zmuszając Tikę do:

odczytu lokalnych plików i ich ujawnienia (np. /etc/passwd, klucze, tokeny),
wykonywania żądań SSRF do zasobów wewnętrznych (np. metadane chmury, serwisy admin),
potencjalnego przepełnienia zasobów (DoS) poprzez ekspansję encji.
Dotknięte zakresy wersji wskazane są dla tika-core 1.13–3.2.1, tika-pdf-module 2.0.0–3.2.1 oraz tika-parsers 1.13–1.28.5. Naprawa wymaga aktualizacji tika-core; sama aktualizacja parsera PDF nie usuwała ryzyka.

Praktyczne konsekwencje / ryzyko

Apache Tika jest powszechnie wbudowana w systemy wyszukiwania, DMS/ECM, pipeline’y ETL, antywirusy, serwisy e-discovery i platformy bezpieczeństwa. W środowiskach, gdzie Tika parsuje niezweryfikowane dokumenty (np. uploady użytkowników, skrzynki pocztowe, roboty indeksujące), XXE może skutkować:

wyciekiem danych z hosta analizującego,
SSRF do sieci wewnętrznej/chmury,
eskalacją na łańcuchach (np. pobranie kluczy, które umożliwią dalszy ruch boczny),
a w określonych konfiguracjach — RCE (gdy łańcuchy XXE/SSRF dotykają usług wykonujących polecenia).

Rekomendacje operacyjne / co zrobić teraz

Pilna aktualizacja pakietów Tiki
- Zaktualizuj do wydań naprawczych, w szczególności tika-core ≥ 3.2.2, oraz powiązane moduły (tika-pdf-module, tika-parsers). Jeśli używasz metapakietów (np. tika-server-standard, tika-app), upewnij się, że transitively podnoszą tika-core.
Twardnienie środowiska analizy plików
- Sandbox (konteneryzacja, seccomp, AppArmor/SELinux) dla procesu parsowania.
- Blokada egress: ogranicz ruch wychodzący z hostów parsujących (eliminuje SSRF exfil).
- Mounty „read-only” i brak dostępu do sekretów (klucze, tokeny) dla kontenerów Tiki.
Konfiguracja parsera PDF / XML
- Jeżeli to możliwe, wyłącz rozwiązywanie zewnętrznych encji XML dla ścieżek, gdzie Tika jest używana (np. przez odpowiednie fabryki parserów XML/bezpieczne funkcje w JVM), do czasu pełnej aktualizacji. (Wskazówka ogólna przy XXE).
Weryfikacja łańcucha zależności
- Przejrzyj SBOM/aplikacje korzystające z Tiki (w tym aplikacje serwerowe: tika-server-standard, tika-grpc, tika-app oraz paczki „standard-modules/package”). Upewnij się, że wszystkie zależności podbiły tika-core.
Monitoring i detekcja
- Szukaj nietypowych wywołań file:///http:// w logach Tiki, błędów parsera PDF, anomalii sieci wychodzącej z hostów analizy.
- Rozważ reguły detekcyjne dla wzorców XXE/SSRF w ruchu wychodzącym. (Dobre praktyki wg opracowań branżowych).

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

CVE-2025-54988 (sierpień 2025) opisano pierwotnie jako XXE w tika-parser-pdf-module. Obecny wpis CVE-2025-66516 koryguje i rozszerza zakres: problem faktycznie tkwił w tika-core, a dodatkowo wskazano dotknięte gałęzie 1.x. Dlatego część środowisk po wcześniejszej „łatce” nadal była podatna.

Podsumowanie / kluczowe wnioski

To krytyczna XXE (CVSS 10.0) w powszechnie wykorzystywanym komponencie — Tika.
Aktualizacja tika-core jest obowiązkowa; sama podmiana PDF-parsera nie wystarcza.
Środowiska parsujące niezaufane dokumenty są szczególnie narażone — wdrażaj sandbox, blokadę egress i monitoring.
Sprawdź cały łańcuch zależności (serwery Tiki, metapakiety), aby uniknąć „fałszywego poczucia bezpieczeństwa” po częściowych aktualizacjach.

Źródła / bibliografia

SecurityWeek: „Critical Apache Tika Vulnerability Leads to XXE Injection” (08.12.2025). (SecurityWeek)
CVE Program (cve.org): CVE-2025-66516 — rozszerzenie zakresu wobec CVE-2025-54988. (CVE)
GitHub Advisory: „Apache Tika has XXE vulnerability — CVE-2025-66516” (zakres wersji i wymóg tika-core ≥ 3.2.2). (GitHub)
CSO Online: przegląd i kontekst „patch widziany jako niepełny” (grudzień 2025). (CSO Online)
Belgian CCB Advisory: implikacje dla metapakietów (tika-server-standard, tika-app, itp.) i rozszerzenie wobec CVE-2025-54988. (CCB Safeonweb)

Korea zaostrzy audyty ISMS po wycieku danych w Coupang. Co to oznacza dla firm?

Wprowadzenie do problemu / definicja luki

Rząd Korei Południowej ogłosił, że zaostrzy proces certyfikacji i nadzoru nad państwowym systemem zarządzania bezpieczeństwem informacji (ISMS) oraz ISMS-P po masywnym wycieku danych w platformie e-commerce Coupang. W agendzie są m.in. obowiązkowe stosowanie ISMS dla kluczowych sektorów, dogłębne kontrole po-incydentowe oraz możliwość unieważniania certyfikatów w razie poważnych naruszeń. Decyzję zakomunikowano po międzyresortowym spotkaniu Personal Information Protection Commission (PIPC) i Ministerstwa Nauki i ICT (MSIT).

W skrócie

Skala: ujawniono dane ok. 33–33,7 mln kont klientów Coupang; incydent miał pozostawać niewykryty przez kilka miesięcy.
Wektor: w śledztwie analizowany jest wątek insiderski oraz wykorzystanie skradzionego klucza prywatnego/uprzywilejowanego dostępu.
Regulacje: rząd planuje obowiązkowość ISMS dla telekomów i platform oraz ostrzejsze audyty i kontrole terenowe; możliwe zmiany ustawowe.
Działania PIPC: nadzwyczajne posiedzenie PIPC nałożyło na Coupang środki zaradcze i obowiązek rozszerzonej notyfikacji.

Kontekst / historia / powiązania

Koreański ISMS/ISMS-P to państwowe reżimy certyfikacyjne pokrywające ogólne bezpieczeństwo informacji (ISMS) oraz ochronę danych osobowych (ISMS-P). Dotąd uzyskanie certyfikatów często następowało na wniosek operatora; władze zapowiadają przejście na model obowiązkowy dla wybranych branż i wzmocnienie nadzoru „po fakcie”. Impulsem stał się wyciek w Coupang — największy od lat — oraz rosnąca presja polityczna i społeczna.

Analiza techniczna / szczegóły luki

Dostępne raporty śledcze wskazują na kilka krytycznych obszarów kontroli, które mogły zawieść:

Zarządzanie kluczami i tożsamościami – pojawiły się doniesienia o wykorzystaniu skradzionego klucza prywatnego oraz możliwym zaangażowaniu osoby związanej wcześniej z systemami uwierzytelniania i IAM w Coupang. To sugeruje niedostatki w HSM/KMS, rotacji kluczy i monitoringu użycia kluczy.
Detekcja i czas ujęcia incydentu (MTTD) – naruszenie mogło trwać od czerwca do listopada, co wskazuje na luki w telemetryce i korelacji zdarzeń (SIEM/UEBA) oraz w alertingu anomalii egress.
Segmentacja i najmniejsze uprawnienia – skoro możliwe było długotrwałe pobieranie rekordów PII, segmentacja danych, kontrole DLP i polityki just-in-time access musiały być niewystarczające. (Wniosek analityczny oparty na dotychczasowych ustaleniach śledztwa).

Praktyczne konsekwencje / ryzyko

Regulator „po drugiej stronie kabla”: firmy działające w Korei (lub obsługujące klientów/kontenery danych w KR) mogą spodziewać się częstszych kontroli, audytów na miejscu i testów skuteczności — nie tylko weryfikacji dokumentów.
Ryzyko łańcucha dostaw: dostawcy i BPO z dostępem do PII klientów koreańskich będą włączani w zakres wymogów ISMS/ISMS-P.
Koszt naruszeń: po incydencie politycy wzywają do wyższych kar i odszkodowań karnych, co podnosi ryzyko finansowe.

Rekomendacje operacyjne / co zrobić teraz

Dla CISO i działów bezpieczeństwa (także poza Koreą, jeśli obsługujesz użytkowników z KR):

Zamroź i przeglądnij łańcuch zaufania: inwentaryzacja kluczy, weryfikacja ochrony KMS/HSM, natychmiastowa rotacja kluczy o podniesionym ryzyku, wdrożenie key-use attestation i alertingu nadużyć.
Wzmocnij IAM: przegląd ról uprzywilejowanych, JIT + MFA hardware, sesje krótkotrwałe, ciągły behavioral UEBA dla adminów i developerów.
Telemetryka i czas ujęcia: reguły detekcji exfiltracji (DNS, S3, BigQuery, Object Storage), eBPF/EDR na hostach przetwarzających PII, korelacja z DLP. Incydent pokazał, że miesiące „ciszy” są realne.
Kontrola dostawców: rozszerz GRC o dowody skuteczności, nie tylko certyfikaty (logi z testów odzyskiwania, wyniki purple-team, wyniki TTP-based controls).
Ćwiczenia insider-risk: scenariusze z nadużyciem kluczy i offboardingiem pracowników (revoke, rotation, break-glass review).
Komunikacja i zgodność: przygotuj playbook PIPC (wzory notyfikacji, kanały komunikacji, FAQ), aby spełnić wymagania rozszerzonej notyfikacji i działań naprawczych.

Różnice / porównania z innymi przypadkami

ISMS/ISMS-P vs ISO/IEC 27001/27701: ISO kładzie nacisk na system zarządzania i cykl PDCA, natomiast ISMS/ISMS-P w Korei – oprócz elementów systemowych – w praktyce jest bardziej operacyjny i sektorowy (telekom, platformy), a po zmianach ma mocniejszy nadzór po-incydentowy z sankcją unieważnienia certyfikatu. Zapowiedzi idą w kierunku obowiązkowego zakresu dla wybranych branż, podczas gdy ISO pozostaje dobrowolne (choć rynkowo wymagane).
RODO (UE): podobnie jak w UE, rośnie presja finansowa i oczekiwanie „efektywności” środków, nie samej zgodności formalnej; koreańskie władze – wzorem praktyk EOG – naciskają na real-world security outcomes i szybkie notyfikacje.

Podsumowanie / kluczowe wnioski

Korea przechodzi od „checklist compliance” do „assurance of effectiveness”: audyty, kontrole terenowe i realna odpowiedzialność (włącznie z utratą certyfikatu).
Incydent w Coupang podkreśla, że największe ryzyko często siedzi „wewnątrz”: ochrona i monitoring kluczy, IAM i telemetria muszą być priorytetem.
Organizacje działające w KR (lub przetwarzające dane Koreańczyków) powinny zacząć przygotowania już dziś: przegląd kluczy, inspekcje dostawców, scenariusze insider-risk i gotowe szablony notyfikacji do PIPC.

Źródła / bibliografia

Korea JoongAng Daily: „Gov’t to toughen certification screening for information security system amid Coupang data breach”, 7 grudnia 2025. (Korea Joongang Daily)
The Korea Times: „Gov’t to toughen certification screening for information security system…”, 6 grudnia 2025. (The Korea Times)
Reuters: „South Korea’s Lee calls for tougher penalties after Coupang data breach”, 2 grudnia 2025. (Reuters)
Reuters: „Coupang apologises over massive data breach (33.7m accounts)”, 29 listopada 2025. (Reuters)
Digital Policy Alert: „PIPC required Coupang to implement corrective notification and strengthened mitigation”, 3 grudnia 2025. (Digital Policy Alert)

Krytyczna luka w dodatku „King Addons for Elementor” aktywnie wykorzystywana. Jak się bronić?

Wprowadzenie do problemu / definicja luki

Atakujący aktywnie wykorzystują krytyczną podatność CVE-2025-8489 w wtyczce King Addons for Elementor (dodatek do buildera Elementor dla WordPressa). Błąd pozwala podnieść uprawnienia podczas rejestracji użytkownika i uzyskać rolę administratora bez uwierzytelnienia — co w praktyce oznacza pełne przejęcie strony. Według informacji z branżowych raportów ataki rozpoczęły się pod koniec października, a do tej pory odnotowano dziesiątki tysięcy prób eksploatacji.

W skrócie

CVE-2025-8489 (CVSS 9.8) — błąd eskalacji uprawnień: dowolny rejestrujący się może nadać sobie rolę administrator. Dotyczy wersji 24.12.92–51.1.14.
Eksploatacja trwa — zarejestrowano ~48–50 tys. prób ataków; używano m.in. zapytań do admin-ajax.php z parametrem user_role=administrator.
Aktualizacja naprawcza — problem załatano w 51.1.35 (wydanie 25 września 2025 r.). Zaktualizuj do 51.1.35+.

Kontekst / historia / powiązania

Błąd został ujawniony 31 października 2025 r., a masowe skanowanie i próby wykorzystania nasiliły się 9–10 listopada. Wtyczka ma ok. 10 tys. aktywnych instalacji, więc nawet umiarkowany odsetek niezałatanych instancji to duża powierzchnia ataku. Dodatkowo obserwowane były powtarzalne adresy IP źródłowe (np. 45.61.157.120, 2602:fa59:3:424::1).

Analiza techniczna / szczegóły luki

Istota problemu: handler rejestracji użytkowników w King Addons nie ograniczał ról, które można przypisać w procesie zakładania konta. Skutkiem był brak kontroli roli i możliwość samodzielnego nadania roli administrator. Klasyfikacja słabości: CWE-269 (Improper Privilege Management).
Wektor ataku: zapytanie do admin-ajax.php z parametrem wskazującym pożądaną rolę (user_role=administrator). Po udanym założeniu konta napastnik ma pełny panel administracyjny.
Zakres wersji: NVD wskazuje, że podatne są 24.12.92–51.1.14; poprawka znajduje się od 51.1.35.
Ślad w repo WordPressa: log zmian/depozyty dla King Addons potwierdzają wydania z 25 września 2025 r. (51.1.35 i 51.1.36).

Praktyczne konsekwencje / ryzyko

Pełne przejęcie strony: dodawanie backdoorów, podmiana treści, przekierowania, wstrzykiwanie złośliwego JS/SEO spam, instalowanie dodatkowych wtyczek do utrzymania trwałości.
Łańcuchy ataku: po uzyskaniu admina możliwe jest RCE poprzez edytor motywu/wtyczek lub upload plików, a także kradzież danych użytkowników i sekretów konfiguracyjnych. (Wniosek na bazie uprawnień admina oraz obserwacji incydentów WP).

Rekomendacje operacyjne / co zrobić teraz

Natychmiastowa aktualizacja King Addons do ≥ 51.1.35 (lub wyżej) albo tymczasowe wyłączenie wtyczki, jeśli aktualizacja niemożliwa. Zweryfikuj w panelu WordPress /Composer.
Przegląd kont użytkowników: usuń nieznane konta adminów; wymuś reset haseł administratorów i edytorów. Zweryfikuj adresy e-mail adminów.
Logi i IOC: sprawdź logi pod kątem żądań do admin-ajax.php z parametrem user_role=administrator oraz ruchu z adresów IP wskazywanych w raportach.
Twarde zasady rejestracji: jeśli nie potrzebujesz publicznej rejestracji — wyłącz ją. W przeciwnym razie zastosuj allowlistę ról, moderację nowych kont, reCAPTCHA/WAF. (Dobre praktyki wynikające z charakteru luki).
Skan i hardening: przeskanuj stronę (np. Wordfence, inne WAF-y), usuń web-shell’e, sprawdź crontaby, wp-content/uploads, mu-plugins, niepodpisane wtyczki/motywy. (Dobre praktyki).
Segmentacja i kopie zapasowe: odseparuj panel administracyjny (np. dostęp tylko przez VPN/IP allowlist), trzymaj offline’owe backupy, z testem odtwarzania. (Dobre praktyki).

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

Równolegle zgłoszono i załatano inną krytyczną podatność w ekosystemie WordPress: ACF Extended – CVE-2025-13486 (CVSS 9.8), RCE bez uwierzytelnienia w wersjach 0.9.0.5–0.9.1.1, naprawioną w 0.9.2. Mechanizm: przekazywanie danych użytkownika do call_user_func_array() w prepare_form(). To inny typ błędu (RCE) niż w King Addons (eskalacja uprawnień), ale efekt końcowy bywa podobny — pełna kompromitacja strony. Wnioski: utrzymywać higienę aktualizacji i minimalizować liczbę dodatków.

Podsumowanie / kluczowe wnioski

King Addons (CVE-2025-8489) to łatwa do wykorzystania, publicznie atakowana luka umożliwiająca utworzenie konta admina. Zaktualizuj do ≥51.1.35 i przeprowadź incident check (kontrola kont, logów, artefaktów).
Fala ataków na wtyczki (w tym ACF Extended) przypomina, że wtyczki to główny wektor kompromitacji WordPressa — wdrażaj WAF, ograniczaj rejestrację i przeglądaj zależności.

Źródła / bibliografia

BleepingComputer: „Critical flaw in WordPress add-on for Elementor exploited in attacks” (03.12.2025). (BleepingComputer)
SecurityWeek: „Critical King Addons Vulnerability Exploited to Hack WordPress Sites” (03.12.2025). (SecurityWeek)
NVD (NIST): CVE-2025-8489 – opis, zakres wersji, CVSS, CWE. (NVD)
WordPress.org (profil/commits KingAddons) – potwierdzenie wydań 51.1.35/51.1.36 (25.09.2025). (WordPress.org)
GitHub Advisory DB: CVE-2025-13486 (ACF Extended) – szczegóły RCE i CVSS. (GitHub)