Archiwa: NIST - Security Bez Tabu

Chrome łata aktywnie wykorzystywaną lukę zero-day w silniku V8

Wprowadzenie do problemu / definicja

Google udostępnił poprawki bezpieczeństwa dla przeglądarki Chrome, eliminujące aktywnie wykorzystywaną lukę zero-day oznaczoną jako CVE-2026-87491. Podatność dotyczy silnika V8, czyli kluczowego komponentu odpowiedzialnego za wykonywanie kodu JavaScript i WebAssembly.

Błąd został sklasyfikowany jako out-of-bounds write, a więc nieprawidłowy zapis danych poza dozwolonym obszarem pamięci. Tego typu problemy należą do najgroźniejszych klas błędów w nowoczesnych przeglądarkach, ponieważ mogą prowadzić do naruszenia integralności procesu i wykonania kontrolowanego kodu.

W skrócie

CVE-2026-87491 umożliwia zdalnemu atakującemu wykonanie dowolnego kodu w obrębie piaskownicy przeglądarki po nakłonieniu ofiary do otwarcia odpowiednio spreparowanej strony HTML. Google potwierdził, że exploit był wykorzystywany w rzeczywistych atakach.

Podatność: CVE-2026-87491
Komponent: silnik V8
Typ błędu: out-of-bounds write
Skutek: zdalne wykonanie kodu w sandboxie Chrome
Status: aktywnie wykorzystywana luka zero-day
Poprawione wersje: Chrome 153.0.8010.36 dla Linuksa oraz 153.0.8010.36/.37 dla Windows i macOS

Kontekst / historia

Podatności w V8 od lat pozostają jedną z najpoważniejszych kategorii błędów w ekosystemie Chromium. Silnik ten przetwarza niezaufane treści dostarczane bezpośrednio przez witryny internetowe, dlatego regularnie znajduje się w centrum zainteresowania operatorów exploitów, grup APT oraz podmiotów rozwijających komercyjne łańcuchy ataku.

W tym przypadku luka została zgłoszona 6 sierpnia 2026 roku przez badaczkę Jihyeon Jeong z Compsec Lab na Seoul National University. Google potwierdził następnie, że błąd jest wykorzystywany in the wild, ale ograniczył publiczne ujawnienie szczegółów technicznych do czasu szerszego wdrożenia poprawek. To standardowa praktyka mająca ograniczyć szybkie uzbrojenie podatności przez kolejnych atakujących.

Incydent wpisuje się w szerszy trend z 2026 roku, w którym Chrome wielokrotnie otrzymywał poprawki dla aktywnie eksploatowanych luk zero-day. Pokazuje to, że przeglądarka nadal pozostaje jednym z najważniejszych wektorów ataku zarówno w środowiskach korporacyjnych, jak i domowych.

Analiza techniczna

CVE-2026-87491 to błąd typu out-of-bounds write w V8. W praktyce oznacza to, że podczas przetwarzania określonych konstrukcji JavaScript lub WebAssembly może dojść do zapisu poza przewidzianą strukturą pamięci. Taka sytuacja może prowadzić do uszkodzenia struktur sterty, modyfikacji wskaźników, destabilizacji procesu renderera, a w sprzyjających warunkach także do kontrolowanego wykonania kodu.

Według opisu problemu atak wymaga dostarczenia specjalnie przygotowanej strony HTML. Po jej otwarciu przez ofiarę napastnik może doprowadzić do wykonania arbitralnego kodu wewnątrz sandboxa Chrome. Sama luka nie oznacza więc automatycznie pełnego przejęcia systemu operacyjnego, ale stanowi bardzo cenny element większego łańcucha ataku.

W praktyce exploity przeglądarkowe są często łączone z dodatkowymi podatnościami, które umożliwiają ucieczkę z piaskownicy, eskalację uprawnień lub trwałe osadzenie złośliwego oprogramowania. Z perspektywy obrońców oznacza to, że nawet pozornie ograniczone wykonanie kodu w sandboxie należy traktować jako incydent wysokiego ryzyka.

Istotne znaczenie ma także fakt, że problem dotyczy V8, czyli komponentu współdzielonego przez wiele przeglądarek opartych na Chromium. Oznacza to potencjalne ryzyko również dla użytkowników takich rozwiązań jak Edge, Brave, Opera czy Vivaldi do czasu wdrożenia odpowiednich aktualizacji przez ich producentów.

W tej samej paczce Google załatał również inne poważne błędy, w tym podatności w WebGL i komponencie Cast. Oznacza to, że opublikowana aktualizacja nie jest wyłącznie jednopunktową poprawką dla jednej luki zero-day, lecz większym pakietem ograniczającym ekspozycję na błędy pamięciowe i inne klasy zagrożeń.

Konsekwencje / ryzyko

Najważniejsze ryzyko związane z CVE-2026-87491 polega na możliwości zdalnego uruchomienia kodu po stronie klienta wyłącznie poprzez odwiedzenie spreparowanej witryny. Taki scenariusz bardzo dobrze wpisuje się w kampanie phishingowe, malvertising, przejęcia legalnych serwisów oraz ataki typu watering hole.

Dla użytkowników indywidualnych skutkiem może być infekcja malware, przejęcie sesji, kradzież danych uwierzytelniających albo dalsza kompromitacja urządzenia przy połączeniu z kolejnym exploitem. W środowiskach firmowych ryzyko jest jeszcze większe, ponieważ przeglądarka stanowi podstawowy interfejs do pracy z pocztą, usługami SaaS, panelami administracyjnymi i aplikacjami wewnętrznymi.

Nawet jeśli wykonanie kodu ogranicza się do sandboxa, podatność nie powinna być bagatelizowana. W nowoczesnych kampaniach ofensywnych luka w renderze przeglądarki bywa zaledwie pierwszym etapem ataku. Dla zaawansowanego przeciwnika może to być wystarczający punkt wejścia do dalszej eksploitacji środowiska.

Dodatkowym czynnikiem ryzyka pozostaje tempo wdrażania aktualizacji. W wielu organizacjach stacje robocze nie otrzymują poprawek natychmiast, a użytkownicy odkładają restart aplikacji. To właśnie pierwsze dni po publikacji aktualizacji są zwykle okresem najwyższej ekspozycji.

Rekomendacje

Organizacje powinny jak najszybciej wymusić aktualizację Chrome do wersji zawierających poprawkę, czyli co najmniej 153.0.8010.36 na Linuksie oraz 153.0.8010.36 lub 153.0.8010.37 na Windows i macOS. Samo pobranie aktualizacji nie zawsze wystarcza, ponieważ użytkownik może nadal działać na starszym procesie przeglądarki do momentu jej ponownego uruchomienia.

zweryfikować wersje przeglądarek na stacjach roboczych i w środowiskach VDI,
wymusić restart przeglądarki po instalacji aktualizacji,
monitorować logi EDR pod kątem anomalii w procesach przeglądarki,
ograniczyć możliwość instalacji niezatwierdzonych rozszerzeń,
zwiększyć czujność wobec phishingu i złośliwych reklam,
przyspieszyć wdrażanie poprawek także dla innych przeglądarek opartych na Chromium.

Zespoły SOC powinny zwrócić szczególną uwagę na nietypowe zachowania procesów renderera, powtarzające się awarie przeglądarki, podejrzane uruchomienia procesów potomnych oraz próby pobrania dodatkowych ładunków po wejściu użytkownika na stronę internetową. Warto również korelować telemetrię z proxy, DNS i EDR w poszukiwaniu krótkich łańcuchów zdarzeń rozpoczynających się od wizyty na nowej domenie i kończących uruchomieniem skryptów lub binariów poza standardowym profilem użytkownika.

Użytkownicy końcowi powinni upewnić się, że przeglądarka została nie tylko zaktualizowana, ale także ponownie uruchomiona. W praktyce jest to obecnie najważniejsza kontrola ograniczająca ryzyko wykorzystania tej podatności.

Podsumowanie

CVE-2026-87491 to kolejna aktywnie wykorzystywana luka zero-day w Chrome, tym razem osadzona w silniku V8. Błąd klasy out-of-bounds write umożliwia zdalne wykonanie kodu w obrębie sandboxa po odwiedzeniu spreparowanej strony.

Mimo że publiczne szczegóły exploita pozostają ograniczone, samo potwierdzenie aktywnej eksploatacji powinno być dla organizacji sygnałem do natychmiastowego działania. Priorytetem pozostaje szybkie wdrożenie aktualizacji, wymuszenie restartu przeglądarek oraz zwiększony monitoring środowisk, w których Chrome i inne przeglądarki Chromium są podstawowym narzędziem pracy.

Źródła

SAP łata krytyczną lukę OVERPASS w jądrze systemu

Wprowadzenie do problemu / definicja

SAP opublikował wrześniowy pakiet poprawek bezpieczeństwa, w którym najwięcej uwagi przyciąga krytyczna podatność CVE-2026-44756, określana nazwą OVERPASS. Luka została oceniona na maksymalny wynik CVSS 10.0 i dotyczy korupcji pamięci w mechanizmie przetwarzania SAP Extended Passport, używanym do śledzenia i przekazywania informacji pomiędzy komponentami systemu.

Z punktu widzenia bezpieczeństwa jest to wyjątkowo groźny scenariusz, ponieważ błąd znajduje się w jądrze SAP, a więc w warstwie współdzielonej przez wiele elementów krajobrazu aplikacyjnego. Tego typu podatności mogą wpływać nie tylko na pojedynczą usługę, ale na kilka ścieżek komunikacji jednocześnie.

W skrócie

Najważniejsze informacje o luce OVERPASS wskazują, że może ona umożliwić zdalnemu, nieuwierzytelnionemu atakującemu wykonanie dowolnych poleceń systemowych z wysokimi uprawnieniami procesu SAP. Problem obejmuje wiele wersji jądra oraz powiązane komponenty komunikacyjne, co znacząco zwiększa potencjalną powierzchnię ataku.

podatność ma identyfikator CVE-2026-44756,
otrzymała najwyższą ocenę krytyczności CVSS 10.0,
nie wymaga uwierzytelnienia do potencjalnego wykorzystania,
może prowadzić do zdalnego wykonania poleceń na hoście SAP,
SAP zaleca natychmiastowe wdrożenie poprawki.

Kontekst / historia

Wrześniowy cykl aktualizacji SAP objął 19 nowych not bezpieczeństwa oraz jedną aktualizację wcześniejszej poprawki. W tym zestawie OVERPASS wyróżnia się zarówno poziomem ryzyka, jak i zakresem systemów, których może dotyczyć. Problem obejmuje wiele linii jądra SAP oraz komponenty związane z komunikacją, w tym SAP Web Dispatcher i pokrewne warianty kernelowe.

Znaczenie tej luki rośnie również dlatego, że ekosystem SAP jest głęboko zintegrowany z procesami biznesowymi, aplikacjami webowymi i komunikacją między systemami. W praktyce oznacza to, że podatność w warstwie kernelowej może przełożyć się na szerokie skutki operacyjne dla środowisk ERP. Dodatkowo w tym samym cyklu SAP zaadresował także inną krytyczną lukę w SAP NetWeaver Message Server, co pokazuje wagę całego pakietu poprawek.

Analiza techniczna

CVE-2026-44756 wynika ze słabości typu buffer overflow w bibliotece odpowiedzialnej za przetwarzanie Extended Passport Protocol. Oznacza to możliwość doprowadzenia do korupcji pamięci podczas obsługi specjalnie przygotowanych danych wejściowych związanych z EPP.

Technicznie istotne jest to, że podatny kod nie jest ograniczony do jednego interfejsu. Mechanizm EPP funkcjonuje jako standardowy element śledzenia żądań w środowisku SAP, dlatego znajduje zastosowanie w wielu kanałach komunikacji. Jeżeli wadliwy fragment znajduje się w jądrze współdzielonym przez różne protokoły, atakujący może próbować osiągnąć go z kilku kierunków, w tym przez warstwę internetową obsługiwaną przez Internet Communication Manager.

Skuteczne wykorzystanie luki może skutkować uruchomieniem dowolnych poleceń systemowych na hoście SAP z uprawnieniami administracyjnymi użytkownika technicznego obsługującego instancję. Dla zespołów bezpieczeństwa oznacza to ryzyko pełnego przejęcia procesu aplikacyjnego, manipulacji logiką biznesową, dostępu do danych wrażliwych oraz dalszego ruchu bocznego wewnątrz środowiska.

Warto również zwrócić uwagę, że pojedyncza poprawka jądra ma eliminować wszystkie znane wektory eksploatacji. Sugeruje to, że źródło błędu zostało zlokalizowane w centralnym fragmencie kodu współdzielonym przez różne funkcje komunikacyjne.

Konsekwencje / ryzyko

Ryzyko związane z OVERPASS należy uznać za bardzo wysokie. Połączenie zdalnego charakteru podatności, braku wymogu uwierzytelnienia i możliwości wykonania kodu z wysokimi uprawnieniami tworzy scenariusz wyjątkowo niebezpieczny dla organizacji korzystających z SAP w środowiskach produkcyjnych.

Potencjalne skutki obejmują:

pełne przejęcie serwera aplikacyjnego SAP,
kradzież lub modyfikację danych biznesowych,
zakłócenie ciągłości działania procesów ERP,
wykorzystanie systemu jako punktu wejścia do dalszych ataków w sieci,
naruszenie integralności i poufności danych regulowanych.

Szczególnie narażone są organizacje udostępniające interfejsy SAP do Internetu, korzystające z SAP Web Dispatcher lub utrzymujące szeroką komunikację między systemami SAP i systemami satelitarnymi. W takich środowiskach skutki luki kernelowej mogą wykraczać poza pojedynczą instancję.

Rekomendacje

Najważniejszym działaniem pozostaje natychmiastowe wdrożenie oficjalnej poprawki SAP dla CVE-2026-44756 we wszystkich podatnych wersjach jądra i komponentach powiązanych. Ze względu na maksymalną ocenę CVSS nie powinno się odkładać aktualizacji na odległe okno serwisowe.

Organizacje powinny równolegle podjąć następujące kroki:

przeprowadzić pilny przegląd inwentarza systemów SAP pod kątem podatnych wersji,
ustalić, które instancje są osiągalne z Internetu lub z sieci o podwyższonym ryzyku,
nadać priorytet aktualizacji systemom publicznie dostępnym i krytycznym biznesowo,
monitorować logi ICM, Web Dispatcher oraz zdarzenia systemowe pod kątem nietypowych żądań,
zweryfikować integralność hostów SAP, zwłaszcza jeśli instalacja łaty została opóźniona,
ograniczyć ekspozycję usług SAP do niezbędnych segmentów sieci,
przygotować procedury awaryjne obejmujące analizę powłamaniową, reset poświadczeń technicznych i kontrolę ruchu bocznego.

Warto także spojrzeć szerzej na cały wrześniowy pakiet poprawek. Skoro wraz z OVERPASS usunięto również inne krytyczne błędy, aktualizacja całego krajobrazu SAP powinna zostać potraktowana jako działanie priorytetowe i skoordynowane.

Podsumowanie

OVERPASS, czyli CVE-2026-44756, należy do najpoważniejszych podatności SAP ujawnionych w 2026 roku. Luka w jądrze systemu może być osiągalna zdalnie bez uwierzytelnienia i prowadzić do wykonania poleceń systemowych z wysokimi uprawnieniami, co stwarza realne ryzyko przejęcia hosta SAP oraz kompromitacji danych biznesowych.

Dla organizacji utrzymujących środowiska SAP oznacza to konieczność natychmiastowego działania. Sama instalacja poprawki powinna zostać uzupełniona o monitoring, segmentację sieci, przegląd ekspozycji usług oraz ocenę, czy przed wdrożeniem aktualizacji nie doszło już do prób nadużycia podatności.

Źródła

SAP warns of maximum severity 'OVERPASS’ kernel vulnerability — https://www.bleepingcomputer.com/news/security/sap-warns-of-maximum-severity-overpass-kernel-vulnerability/
SAP Security Patch Day – September 2026 — https://support.sap.com/en/my-support/knowledge-base/security-notes-news/september-2026.html
Mitigating OVERPASS (CVE-2026-44756): A Critical Vulnerability in the SAP Kernel — https://onapsis.com/blog/sap-overpass-remediation/
CVE-2026-44756 — https://www.cve.org/CVERecord?id=CVE-2026-44756
CVE-2026-58240 — https://nvd.nist.gov/vuln/detail/CVE-2026-58240

Naruszenie danych u partnera logistycznego Trezora objęło 67 tys. klientów z USA

Wprowadzenie do problemu / definicja

Incydenty bezpieczeństwa po stronie dostawców zewnętrznych należą do najtrudniejszych wyzwań w nowoczesnym cyberbezpieczeństwie. Najnowsza sprawa dotycząca Trezora pokazuje, że nawet jeśli producent nie odnotuje bezpośredniego włamania do własnej infrastruktury, naruszenie u partnera logistycznego może doprowadzić do ujawnienia danych klientów i wygenerować poważne ryzyko operacyjne.

W tym przypadku problem dotyczy danych zamówień przechowywanych przez ShipMonk. Trezor podkreśla, że incydent nie objął portfeli sprzętowych, kluczy prywatnych ani seed phrase, jednak sam wyciek danych identyfikacyjnych i adresowych klientów stanowi istotne zagrożenie.

W skrócie

Naruszenie objęło dodatkowo około 67 tys. klientów z USA.
Ujawnione dane obejmowały m.in. imię i nazwisko, adres e-mail, numer telefonu, adres dostawy oraz numer zamówienia.
Dane dotyczyły zamówień z okresu od listopada 2019 do sierpnia 2021.
Incydent miał miejsce po stronie partnera logistycznego ShipMonk, a nie w infrastrukturze Trezora.
Największe ryzyko dotyczy phishingu, socjotechniki oraz potencjalnych zagrożeń fizycznych.

Kontekst / historia

Sprawa jest rozwinięciem wcześniejszego incydentu ujawnionego w sierpniu 2026 roku. Wówczas informowano o mniejszej skali wycieku, obejmującej około 13,7 tys. klientów. Komunikacja firmy sugerowała wtedy, że zakres incydentu został ograniczony dzięki 90-dniowej polityce retencji danych związanych z zamówieniami.

Na początku września 2026 roku Trezor przekazał jednak, że ShipMonk zidentyfikował dodatkowy zbiór historycznych danych klientów z USA. Szczególnie istotne jest to, że dane te miały wcześniej zostać usunięte zgodnie z deklarowaną polityką retencji. Oznacza to, że problem nie dotyczy wyłącznie samego włamania, ale również nadzoru nad procesami usuwania danych oraz rzeczywistej kontroli nad praktykami partnerów biznesowych.

Analiza techniczna

Dostępne informacje wskazują, że źródłem incydentu był nieautoryzowany dostęp do systemów ShipMonk. To klasyczny przykład ataku na łańcuch dostaw, w którym przestępcy nie uderzają bezpośrednio w producenta końcowego, lecz w podmiot przetwarzający jego dane operacyjne.

W doniesieniach dotyczących sprawy pojawia się również wątek krytycznej podatności typu SQL injection w Metabase, oznaczonej jako CVE-2026-72898. Jeśli podatny komponent analityczny miał dostęp do baz danych zawierających informacje o zamówieniach, wykorzystanie luki mogło umożliwić odczyt i eksport rekordów klientów.

Najbardziej niepokojący aspekt incydentu dotyczy jednak trwałości danych w środowisku partnera. Trezor deklarował ograniczoną retencję danych zakupowych do 90 dni, tymczasem ujawnione rekordy obejmowały znacznie starszy okres. Może to wskazywać na kilka potencjalnych słabości:

nieskuteczne usuwanie danych z systemów operacyjnych,
pozostawienie danych w warstwach pośrednich lub narzędziach analitycznych,
brak spójnej anonimizacji danych historycznych,
nieprawidłową segmentację środowisk i zbiorów danych,
niewystarczającą weryfikację wykonania polityk retencyjnych.

Z perspektywy bezpieczeństwa jest to ważna lekcja: sama polityka prywatności i formalne zapisy umowne nie gwarantują ochrony, jeśli organizacja nie potrafi technicznie potwierdzić, że dane rzeczywiście zostały usunięte.

Konsekwencje / ryzyko

Choć incydent nie naruszył bezpieczeństwa kryptograficznego urządzeń Trezora, jego skutki dla klientów mogą być poważne. Połączenie danych identyfikacyjnych, kontaktowych i adresowych z informacją o zakupie portfela sprzętowego znacząco zwiększa skuteczność ataków socjotechnicznych.

Cyberprzestępcy mogą wykorzystywać te informacje do przygotowywania wiarygodnych kampanii phishingowych, fałszywych wiadomości od przewoźników, podszywania się pod wsparcie techniczne lub prób wyłudzenia danych związanych z aktywami cyfrowymi. W ekosystemie kryptowalut sam fakt posiadania urządzenia do cold storage może zostać potraktowany jako sygnał, że ofiara przechowuje wartościowe środki.

Z perspektywy organizacyjnej incydent zwiększa także ryzyko reputacyjne, kontraktowe i regulacyjne. Jeżeli partner nie wywiązał się z ustaleń dotyczących retencji danych, rodzi to pytania o skuteczność audytów, egzekwowanie wymagań bezpieczeństwa oraz zgodność z zasadą minimalizacji danych.

Rekomendacje

Osoby, których dane mogły zostać objęte incydentem, powinny przyjąć, że wzrośnie liczba prób phishingu i innych form oszustw. Szczególną ostrożność należy zachować wobec wiadomości e-mail, SMS-ów, połączeń telefonicznych oraz korespondencji, które odnoszą się do zamówienia, dostawy lub rzekomej weryfikacji portfela.

Nie należy nigdy ujawniać seed phrase ani kluczy prywatnych.
Warto weryfikować każdą wiadomość dotyczącą dostawy, zwrotu lub wsparcia technicznego.
Należy zachować ostrożność wobec kontaktów telefonicznych podszywających się pod support lub firmę kurierską.
Dobrym krokiem jest wzmocnienie zabezpieczeń kont pocztowych i powiązanych usług, w tym stosowanie MFA.

Po stronie firm kluczowe znaczenie ma zaostrzenie kontroli nad dostawcami. Organizacje powinny wymagać technicznego potwierdzania retencji danych, regularnych audytów, testów zgodności oraz weryfikacji środowisk pomocniczych, takich jak systemy analityczne, kopie zapasowe czy narzędzia raportowe.

W przypadku usług obsługujących produkty o podwyższonym profilu ryzyka warto rozważyć krótszą retencję, szerszą anonimizację, segmentację danych klientów oraz ograniczanie liczby podmiotów mających dostęp do pełnych danych identyfikacyjnych i adresowych.

Podsumowanie

Incydent związany z Trezorem i ShipMonk pokazuje, że bezpieczeństwo organizacji jest tak silne, jak bezpieczeństwo jej partnerów. Nawet bez naruszenia samego produktu wyciek danych zamówień może prowadzić do realnych zagrożeń dla klientów, w tym phishingu, oszustw ukierunkowanych i zwiększonego ryzyka fizycznego.

Najważniejszy wniosek z tej sprawy dotyczy konieczności praktycznej, a nie wyłącznie formalnej, kontroli nad retencją danych u dostawców zewnętrznych. Systemy logistyczne i analityczne powinny być traktowane jako pełnoprawna część powierzchni ataku i podlegać równie rygorystycznym kontrolom jak kluczowa infrastruktura biznesowa.

Źródła

Krytyczna luka SQL Injection w Sangoma Switchvox aktywnie wykorzystywana do zdalnego wykonania kodu

Wprowadzenie do problemu / definicja

Sangoma Switchvox, platforma PBX i VoIP wykorzystywana w środowiskach firmowych, znalazła się w centrum uwagi po ujawnieniu krytycznej podatności oznaczonej jako CVE-2026-9586. Luka ma charakter nieautoryzowanego SQL injection i według dostępnych informacji jest już aktywnie wykorzystywana w rzeczywistych atakach, co znacząco podnosi jej priorytet z perspektywy zespołów bezpieczeństwa.

Problem jest szczególnie niebezpieczny, ponieważ exploit nie wymaga wcześniejszego uwierzytelnienia. Oznacza to, że atakujący może próbować przejąć podatny system zdalnie, bez znajomości poświadczeń i bez konieczności uzyskania wcześniejszego dostępu do środowiska.

W skrócie

CVE-2026-9586 to krytyczna podatność SQL injection oceniona na 9.3 w skali CVSS. Dotyczy komponentu odpowiedzialnego za przetwarzanie danych XML w Sangoma Switchvox i umożliwia zdalne wykonanie nieautoryzowanych instrukcji SQL wobec backendowej bazy PostgreSQL.

atak nie wymaga logowania,
wektor ataku jest zdalny,
potencjalny skutek obejmuje zdalne wykonanie kodu,
luka została powiązana z aktywną eksploatacją,
podatność trafiła do katalogu Known Exploited Vulnerabilities.

Kontekst / historia

Systemy klasy PBX i VoIP są często kluczowym elementem infrastruktury operacyjnej przedsiębiorstw. Odpowiadają nie tylko za obsługę połączeń, ale również za integrację z katalogami użytkowników, systemami powiadomień, CRM oraz innymi usługami biznesowymi. Z tego powodu ich kompromitacja może mieć znacznie szersze skutki niż chwilowa niedostępność telefonii.

W przypadku Switchvox istotne jest również to, że tego typu rozwiązania bywają wystawiane do sieci lub pozostają szeroko dostępne wewnątrz organizacji. To czyni je atrakcyjnym celem dla napastników, zwłaszcza gdy wykryta luka pozwala działać bez uwierzytelnienia. Doniesienia o aktywnym wykorzystaniu CVE-2026-9586 wskazują, że organizacje nie mają komfortu czasowego na odkładanie aktualizacji i działań detekcyjnych.

Analiza techniczna

Istota podatności sprowadza się do niewłaściwej obsługi danych wejściowych w punkcie końcowym przetwarzającym XML. Według publicznych opisów kontrolowana przez użytkownika wartość pola PhoneIP mogła być używana w zapytaniach do PostgreSQL bez odpowiedniej sanitacji i bez bezpiecznej parametryzacji. To klasyczny wzorzec prowadzący do SQL injection.

Z perspektywy atakującego scenariusz jest stosunkowo prosty. Odpowiednio spreparowane żądanie HTTP z zawartością XML może zmienić logikę zapytania wykonywanego po stronie serwera. Jeżeli aplikacja lub baza działa z podwyższonymi uprawnieniami, skutki mogą wyjść daleko poza sam odczyt danych i doprowadzić do zdalnego wykonania kodu na hoście.

Możliwe ścieżki nadużycia obejmują:

odczyt oraz modyfikację danych konfiguracyjnych systemu telefonicznego,
manipulację rekordami w bazie danych,
pozyskanie informacji o użytkownikach i topologii środowiska,
wykorzystanie funkcji bazy do osiągnięcia wykonania kodu,
ustanowienie trwałości poprzez modyfikację konfiguracji lub osadzenie backdoora.

Najbardziej alarmujący jest brak wymogu uwierzytelnienia. W praktyce oznacza to, że ochrona oparta wyłącznie na hasłach lub wieloskładnikowym logowaniu nie eliminuje ryzyka, jeśli podatny interfejs pozostaje osiągalny sieciowo.

Konsekwencje / ryzyko

Udany atak na Switchvox może przełożyć się zarówno na skutki techniczne, jak i biznesowe. Na poziomie technicznym mówimy o możliwości przejęcia serwera aplikacyjnego, manipulacji bazą danych, zmianie konfiguracji usług i potencjalnym uzyskaniu trwałego dostępu do systemu.

Na poziomie operacyjnym zagrożenie obejmuje zakłócenia działania telefonii, nieautoryzowane zmiany trasowania połączeń, kompromitację kont użytkowników, utratę poufności danych komunikacyjnych oraz wykorzystanie przejętego serwera jako punktu pivot do dalszej penetracji sieci firmowej.

Ryzyko jest szczególnie wysokie z kilku powodów:

atak jest zdalny,
nie wymaga logowania,
potwierdzono aktywną eksploatację,
systemy VoIP i PBX bywają słabiej monitorowane niż inne serwery krytyczne,
kompromitacja może otworzyć drogę do ataku na kolejne segmenty infrastruktury.

Rekomendacje

Organizacje korzystające z Sangoma Switchvox powinny potraktować CVE-2026-9586 jako incydent wysokiego priorytetu. Niezbędne są równolegle działania naprawcze, ograniczenie ekspozycji oraz aktywne poszukiwanie oznak kompromitacji.

W pierwszej kolejności warto:

zidentyfikować wszystkie instancje Switchvox w środowisku,
niezwłocznie wdrożyć poprawki lub zalecane środki naprawcze producenta,
ograniczyć dostęp do interfejsów administracyjnych do zaufanych adresów i segmentów sieci,
przeanalizować logi aplikacyjne, systemowe i bazodanowe pod kątem nietypowych żądań XML,
sprawdzić środowisko pod kątem wskaźników kompromitacji związanych z aktywną kampanią.

Dodatkowo zalecane jest:

wdrożenie reguł WAF lub IDS/IPS wykrywających wzorce SQL injection,
monitorowanie procesów potomnych i nietypowych wywołań inicjowanych przez aplikację lub PostgreSQL,
rotacja poświadczeń, jeśli istnieje podejrzenie naruszenia,
weryfikacja integralności konfiguracji PBX, numeracji, kont i integracji,
segmentacja systemu telefonicznego i ograniczenie komunikacji bocznej.

Jeżeli organizacja podejrzewa, że podatność została już wykorzystana, samo zainstalowanie poprawki może nie wystarczyć. W takiej sytuacji należy zabezpieczyć artefakty, przeprowadzić pełną analizę incydentu, ocenić zakres modyfikacji w bazie danych i rozważyć odtworzenie systemu do zaufanego stanu.

Podsumowanie

CVE-2026-9586 w Sangoma Switchvox łączy trzy wyjątkowo groźne cechy: brak uwierzytelnienia, zdalną eksploatację i możliwość osiągnięcia zdalnego wykonania kodu. Potwierdzenia aktywnego wykorzystania sprawiają, że nie jest to hipotetyczny problem, lecz realne zagrożenie wymagające natychmiastowej reakcji.

Dla zespołów bezpieczeństwa priorytetem powinno być szybkie łatanie, ograniczenie powierzchni ataku, monitoring prób nadużyć oraz weryfikacja, czy system telefoniczny nie został już użyty jako punkt wejścia do szerszej kompromitacji środowiska.

Źródła

SecurityWeek — https://www.securityweek.com/sangoma-switchvox-vulnerabilities-exploited-in-the-wild/
CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
NVD: CVE-2026-9586 — https://nvd.nist.gov/vuln/detail/CVE-2026-9586
Horizon3.ai — Threat advisory on CVE-2026-9586 — https://horizon3.ai/

Plex wzywa do pilnej aktualizacji po usunięciu wielu nieujawnionych luk bezpieczeństwa

Wprowadzenie do problemu / definicja

Plex zaapelował do użytkowników i administratorów o natychmiastową aktualizację kluczowych komponentów swojej platformy po usunięciu wielu nieujawnionych podatności bezpieczeństwa. Producent nie opublikował pełnych szczegółów technicznych, co w praktyce zwykle oznacza próbę ograniczenia ryzyka szybkiego przygotowania exploitów przez cyberprzestępców przed wdrożeniem poprawek na szeroką skalę.

Komunikat należy traktować poważnie, zwłaszcza że Plex Media Server jest często wystawiany do internetu w celu zdalnego dostępu do biblioteki multimediów. W takich scenariuszach nawet brak publicznych szczegółów o lukach nie zmniejsza ryzyka, lecz przeciwnie — sugeruje, że czas na reakcję administratorów jest ograniczony.

W skrócie

Plex zaleca pilną aktualizację do Plex Media Server 1.43.3 lub nowszej.
Użytkownicy Plex Desktop powinni przejść do wersji 1.115.0 lub nowszej.
Poprawki usuwają kilka nieujawnionych błędów bezpieczeństwa, dla których wystąpiono o identyfikatory CVE.
Szczególnej uwagi wymagają instalacje publicznie dostępne oraz wdrożenia na urządzeniach NAS.
Brak szczegółów technicznych nie oznacza niskiego ryzyka — wręcz przeciwnie, może wskazywać na podwyższoną pilność działań.

Kontekst / historia

Alert Plex pojawił się na początku września 2026 roku i dotyczy serwerów działających w wersji 1.43.2 oraz starszych, a także wcześniejszych wydań aplikacji desktopowej. Producent potwierdził jedynie, że nowe wersje eliminują kilka problemów bezpieczeństwa i zalecił jak najszybsze wdrożenie aktualizacji.

Nie jest to pierwszy przypadek, gdy bezpieczeństwo ekosystemu Plex staje się przedmiotem zainteresowania administratorów i zespołów bezpieczeństwa. W 2025 roku opisywano podatność CVE-2025-34158, związaną z błędem uwierzytelnienia oraz nadmiernym ujawnieniem danych właściciela serwera przez interfejs API. Tego typu błędy są szczególnie groźne, ponieważ mogą wspierać dalsze etapy rozpoznania środowiska i przygotowania bardziej zaawansowanego ataku.

Wcześniejsze incydenty i podatności związane z Plex pokazywały również, że platforma może stanowić element większego łańcucha ataku. Z tego powodu każdy komunikat producenta o pilnej aktualizacji, nawet bez pełnych danych technicznych, powinien być traktowany jako istotne ostrzeżenie operacyjne.

Analiza techniczna

Najważniejszym aspektem obecnej sytuacji jest brak publicznej dokumentacji technicznej dotyczącej usuniętych luk. Taki model ujawnienia zwykle oznacza jeden z dwóch scenariuszy: albo trwa jeszcze proces koordynacji publikacji szczegółów i numerów CVE, albo producent celowo ogranicza informacje, by utrudnić przygotowanie skutecznych metod ataku przeciwko niezałatanym instancjom.

Aktualizacja obejmuje dwa kluczowe komponenty:

Plex Media Server 1.43.3
Plex Desktop 1.115.0

Bez dostępu do technicznych analiz nie da się dziś jednoznacznie określić, jakie klasy błędów zostały wyeliminowane. Na podstawie wcześniejszych przypadków związanych z Plex można jednak wskazać najbardziej prawdopodobne obszary ryzyka:

błędy autoryzacji i kontroli dostępu w API,
ujawnienie danych administracyjnych, identyfikatorów lub tokenów,
nadmierną ekspozycję usług zarządzania do internetu,
możliwość enumeracji infrastruktury i powiązanych zasobów,
błędy sieciowe prowadzące do nadużyć lub dalszej kompromitacji hosta.

Szczególnie problematyczne są wdrożenia na urządzeniach NAS, gdzie proces aktualizacji zależy od dostawcy platformy. W praktyce oznacza to, że część administratorów może nie zobaczyć nowego pakietu w natywnym repozytorium i błędnie założyć, że system pozostaje aktualny, mimo że poprawka producenta została już wydana.

Istotnym czynnikiem ryzyka pozostaje także charakter typowych wdrożeń Plex. Serwer często działa w sieciach domowych, małych biurach lub środowiskach prosumenckich, gdzie poziom segmentacji, monitoringu i kontroli dostępu bywa ograniczony. To zwiększa prawdopodobieństwo, że nawet lokalny błąd w aplikacji może zostać wykorzystany do dalszego ruchu bocznego lub rozpoznania sieci.

Konsekwencje / ryzyko

Skala zagrożenia zależy przede wszystkim od sposobu wdrożenia usługi. Najwyższe ryzyko dotyczy środowisk, w których Plex jest publicznie dostępny, współdzielony z wieloma użytkownikami lub uruchamiany na hostach mających dostęp do innych zasobów sieci lokalnej.

Potencjalne skutki wykorzystania nieujawnionych jeszcze luk mogą obejmować:

nieautoryzowany dostęp do panelu administracyjnego lub API,
wyciek danych konfiguracyjnych i informacji o koncie właściciela,
przejęcie sesji lub eskalację uprawnień,
rozpoznanie infrastruktury i urządzeń powiązanych z usługą,
wykorzystanie hosta jako punktu wejścia do dalszej penetracji sieci lokalnej.

Dodatkowym problemem jest duża liczba publicznie osiągalnych interfejsów Plex Media Server. Takie systemy stanowią atrakcyjny cel dla automatycznych skanerów, które po publikacji nowych błędów szybko identyfikują podatne wersje i próbują masowo je wykorzystać.

Rekomendacje

Administratorzy powinni potraktować komunikat Plex jako zdarzenie wymagające szybkiej i konkretnej reakcji. Podstawowe działania ograniczające ryzyko obejmują:

niezwłoczną aktualizację Plex Media Server do wersji 1.43.3 lub nowszej,
aktualizację Plex Desktop do wersji 1.115.0 lub nowszej,
ręczne wdrożenie pakietu na NAS, jeśli aktualizacja nie jest jeszcze dostępna w repozytorium producenta urządzenia,
przegląd ekspozycji usługi i wyłączenie bezpośredniego dostępu z internetu tam, gdzie nie jest on konieczny,
ograniczenie dostępu za pomocą VPN, list kontroli dostępu lub dodatkowo chronionego reverse proxy,
weryfikację aktywnych tokenów, sesji i udostępnionych kont,
analizę logów pod kątem nietypowych żądań do API oraz prób logowania,
segmentację hosta Plex od bardziej wrażliwych systemów w sieci.

W środowiskach o wyższym profilu ryzyka warto dodatkowo przeprowadzić inwentaryzację wszystkich instancji Plex, sprawdzić reguły przekierowania portów oraz objąć hosty rozszerzonym monitoringiem systemowym lub narzędziami klasy EDR.

Podsumowanie

Obecna aktualizacja Plex jest istotna właśnie dlatego, że producent nie ujawnił jeszcze pełnych szczegółów usuniętych podatności. Tego typu komunikaty zwykle oznaczają podwyższony poziom ryzyka i ograniczone okno czasowe na wdrożenie poprawek przed pojawieniem się prób aktywnego wykorzystania luk.

Dla administratorów wniosek jest jednoznaczny: jeśli środowisko działa w wersji starszej niż Plex Media Server 1.43.3 lub Plex Desktop 1.115.0, aktualizacja powinna zostać przeprowadzona bez zwłoki. Równolegle warto ograniczyć ekspozycję usługi, przeanalizować logi i upewnić się, że Plex nie stanowi łatwego punktu wejścia do dalszego ataku.

Źródła

Plex Urges Immediate Updates After Patching Multiple Undisclosed Security Flaws — https://thehackernews.com/2026/09/plex-urges-immediate-updates-after.html
Important Security Update for Plex Media Server v1.43.2 and earlier — https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
NVD: CVE-2025-34158 — https://nvd.nist.gov/vuln/detail/CVE-2025-34158
NVD: CVE-2020-5741 — https://nvd.nist.gov/vuln/detail/CVE-2020-5741
12-22-2022: Notice of Security Incident — https://blog.lastpass.com/posts/notice-of-recent-security-incident

CVE-2025-57819 w FreePBX: krytyczne RCE przez nieuwierzytelnione SQL Injection w Endpoint Manager

Wprowadzenie do problemu / definicja

CVE-2025-57819 to krytyczna podatność bezpieczeństwa dotycząca platformy FreePBX i komercyjnego modułu Endpoint Manager. Luka pozwala na przeprowadzenie nieuwierzytelnionego ataku SQL Injection, który w sprzyjających warunkach może zostać rozwinięty do zdalnego wykonania kodu na serwerze. Dla organizacji wykorzystujących telefonię IP oznacza to ryzyko przejęcia infrastruktury komunikacyjnej bez konieczności wcześniejszego logowania do panelu administracyjnego.

Problem jest szczególnie istotny w środowiskach, w których interfejs administracyjny FreePBX został wystawiony do internetu lub zabezpieczony jedynie podstawową filtracją ruchu. W takim scenariuszu pojedynczy błąd walidacji danych wejściowych może doprowadzić do naruszenia poufności, integralności i dostępności całego systemu telefonicznego.

W skrócie

Podatność CVE-2025-57819 dotyczy mechanizmu obsługi żądań w module Endpoint Manager i umożliwia atak bez uwierzytelnienia. Napastnik może wysłać specjalnie przygotowane żądanie do panelu administracyjnego, wykorzystać błąd SQL Injection, a następnie zmodyfikować dane w taki sposób, by uzyskać wykonywanie poleceń systemowych.

atak jest zdalny i nie wymaga logowania,
wektor wejściowy obejmuje interfejs administracyjny,
skutkiem może być pełna kompromitacja serwera PBX,
zagrożone były wersje FreePBX 15.x wcześniejsze niż 15.0.66, 16.x wcześniejsze niż 16.0.89 oraz 17.x wcześniejsze niż 17.0.3.

Kontekst / historia

FreePBX należy do najpopularniejszych platform zarządzania telefonią opartą o Asterisk, dlatego każda luka wpływająca na warstwę administracyjną ma znaczenie wykraczające poza pojedynczy host. Kompromitacja może przełożyć się na zakłócenie pracy IVR, kolejek połączeń, trunków SIP, nagrywania rozmów i integracji z systemami biznesowymi.

W opisie zagrożenia wskazano, że nieautoryzowana aktywność wymierzona w publicznie dostępne instalacje była obserwowana już w sierpniu 2025 roku. Dodatkowym problemem jest publiczna dostępność materiałów opisujących exploit, co obniża próg wejścia dla napastników i przyspiesza automatyzację prób wykorzystania luki na podatnych instancjach.

Analiza techniczna

Techniczne źródło problemu stanowi niewłaściwa sanitizacja danych wejściowych przekazywanych do endpointu administracyjnego. Szczególnie istotny jest parametr brand obsługiwany przez ścieżkę admin/ajax.php w module Endpoint Manager. Jeśli dane wejściowe trafiają do zapytania SQL bez odpowiedniego oczyszczenia, atakujący może wstrzyknąć własne instrukcje i wpłynąć na zachowanie aplikacji.

Znaczenie praktyczne tej luki wykracza poza samo odczytywanie danych z bazy. W opisanym scenariuszu exploitacyjnym SQL Injection może zostać użyte do modyfikacji rekordów odpowiedzialnych za zadania harmonogramu. W konsekwencji napastnik doprowadza do uruchomienia złośliwego polecenia systemowego, co skutkuje uzyskaniem zdalnej powłoki i przejęciem serwera.

identyfikacja dostępnego endpointu administracyjnego,
wykorzystanie SQL Injection bez uwierzytelnienia,
modyfikacja zawartości bazy danych,
uruchomienie poleceń przez mechanizm zadań cyklicznych,
przejęcie hosta i możliwość dalszego ruchu bocznego.

W środowisku PBX taki łańcuch ataku jest wyjątkowo niebezpieczny, ponieważ może otworzyć drogę do pozyskania konfiguracji trunków, danych abonentów, nagrań rozmów, sekretów SIP oraz poświadczeń wykorzystywanych przez inne elementy infrastruktury.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2025-57819 należy ocenić jako krytyczne. Atak nie wymaga interakcji użytkownika, może zostać przeprowadzony zdalnie i potencjalnie kończy się pełną kompromitacją systemu. Dla przedsiębiorstw oznacza to zarówno ryzyko techniczne, jak i operacyjne.

przejęcie panelu administracyjnego FreePBX,
nieautoryzowana modyfikacja konfiguracji i bazy danych,
uruchamianie własnych poleceń na serwerze,
instalacja mechanizmów trwałego dostępu,
kradzież poświadczeń i danych konfiguracyjnych,
fraud telekomunikacyjny i nadużycia w ruchu głosowym,
wykorzystanie serwera do dalszych ataków wewnątrz sieci,
zakłócenie ciągłości działania usług telefonicznych.

Dodatkowym problemem jest to, że systemy PBX bywają aktualizowane rzadziej niż inne krytyczne komponenty IT. Jednocześnie ich wysoka wartość operacyjna i częsta ekspozycja na internet czynią je atrakcyjnym celem dla przestępców wykorzystujących skanowanie masowe i gotowe łańcuchy exploitacyjne.

Rekomendacje

Najważniejszym działaniem obronnym jest natychmiastowa weryfikacja wersji FreePBX i modułu Endpoint Manager oraz aktualizacja do wydań zawierających poprawki. Organizacje korzystające z linii 15, 16 i 17 powinny potwierdzić wdrożenie co najmniej wersji 15.0.66, 16.0.89 lub 17.0.3.

ograniczyć dostęp do panelu administracyjnego wyłącznie z zaufanych adresów IP,
ukryć interfejs administracyjny za VPN, ACL lub innym mechanizmem kontroli dostępu,
przeanalizować logi HTTP pod kątem nietypowych żądań do admin/ajax.php i modular.php,
sprawdzić, czy nie pojawiły się nieautoryzowane konta i zmiany w tabelach administracyjnych,
zweryfikować harmonogram zadań pod kątem obcych poleceń,
skontrolować integralność plików konfiguracyjnych i aplikacyjnych,
poszukać oznak trwałości, takich jak podejrzane skrypty i niestandardowe pliki,
po wykryciu incydentu zresetować poświadczenia administracyjne, SIP i inne sekrety przechowywane na serwerze,
objąć serwer dodatkowymi regułami monitoringu, EDR i detekcji połączeń wychodzących.

Z perspektywy zespołów SOC i IR każdy publicznie dostępny, niezałatany system FreePBX warto traktować jako potencjalnie naruszony do czasu przeprowadzenia analizy śladów kompromitacji.

Podsumowanie

CVE-2025-57819 pokazuje, jak pojedynczy błąd walidacji danych wejściowych może uruchomić pełny łańcuch prowadzący do zdalnego wykonania kodu. W przypadku FreePBX skutki mogą obejmować przejęcie infrastruktury telefonicznej, utratę danych, nadużycia telekomunikacyjne oraz przerwy w działaniu usług biznesowych.

Kluczowe znaczenie ma szybkie wdrożenie poprawek, ograniczenie ekspozycji panelu administracyjnego i przegląd środowiska pod kątem oznak wykorzystania luki. Im dłużej podatna instancja pozostaje dostępna z internetu, tym większe ryzyko skutecznego ataku.

Źródła

Exploit Database – FreePBX 17.0.2 – Remote Code Execution (RCE) – Multiple webapps Exploit – https://www.exploit-db.com/exploits/52681
FreePBX Security Advisory – Authentication Bypass Leading to SQL Injection and RCE – https://github.com/FreePBX/security-reporting/security/advisories/GHSA-m42g-xg4c-5f3h
NVD – CVE-2025-57819 – https://nvd.nist.gov/vuln/detail/CVE-2025-57819

CVE-2025-57819 w FreePBX: krytyczne RCE przez nieuwierzytelnione SQL Injection w Endpoint Manager

Wprowadzenie do problemu / definicja

W skrócie

atak jest zdalny i nie wymaga logowania,
wektor wejściowy obejmuje interfejs administracyjny,
skutkiem może być pełna kompromitacja serwera PBX,
zagrożone były wersje FreePBX 15.x wcześniejsze niż 15.0.66, 16.x wcześniejsze niż 16.0.89 oraz 17.x wcześniejsze niż 17.0.3.

Kontekst / historia

Analiza techniczna

identyfikacja dostępnego endpointu administracyjnego,
wykorzystanie SQL Injection bez uwierzytelnienia,
modyfikacja zawartości bazy danych,
uruchomienie poleceń przez mechanizm zadań cyklicznych,
przejęcie hosta i możliwość dalszego ruchu bocznego.

Konsekwencje / ryzyko

przejęcie panelu administracyjnego FreePBX,
nieautoryzowana modyfikacja konfiguracji i bazy danych,
uruchamianie własnych poleceń na serwerze,
instalacja mechanizmów trwałego dostępu,
kradzież poświadczeń i danych konfiguracyjnych,
fraud telekomunikacyjny i nadużycia w ruchu głosowym,
wykorzystanie serwera do dalszych ataków wewnątrz sieci,
zakłócenie ciągłości działania usług telefonicznych.

Rekomendacje

ograniczyć dostęp do panelu administracyjnego wyłącznie z zaufanych adresów IP,
ukryć interfejs administracyjny za VPN, ACL lub innym mechanizmem kontroli dostępu,
przeanalizować logi HTTP pod kątem nietypowych żądań do admin/ajax.php i modular.php,
sprawdzić, czy nie pojawiły się nieautoryzowane konta i zmiany w tabelach administracyjnych,
zweryfikować harmonogram zadań pod kątem obcych poleceń,
skontrolować integralność plików konfiguracyjnych i aplikacyjnych,
poszukać oznak trwałości, takich jak podejrzane skrypty i niestandardowe pliki,
po wykryciu incydentu zresetować poświadczenia administracyjne, SIP i inne sekrety przechowywane na serwerze,
objąć serwer dodatkowymi regułami monitoringu, EDR i detekcji połączeń wychodzących.

Z perspektywy zespołów SOC i IR każdy publicznie dostępny, niezałatany system FreePBX warto traktować jako potencjalnie naruszony do czasu przeprowadzenia analizy śladów kompromitacji.

Podsumowanie

Źródła

Exploit Database – FreePBX 17.0.2 – Remote Code Execution (RCE) – Multiple webapps Exploit – https://www.exploit-db.com/exploits/52681
FreePBX Security Advisory – Authentication Bypass Leading to SQL Injection and RCE – https://github.com/FreePBX/security-reporting/security/advisories/GHSA-m42g-xg4c-5f3h
NVD – CVE-2025-57819 – https://nvd.nist.gov/vuln/detail/CVE-2025-57819