Archiwa: Linux - Strona 6 z 42 - Security Bez Tabu

Nowa kampania cyberwywiadowcza przeciwko telekomom: Showboat dla Linuksa i JFMBackdoor dla Windows

Cybersecurity news

Wprowadzenie do problemu / definicja

Sektor telekomunikacyjny ponownie stał się celem zaawansowanej kampanii cyberwywiadowczej. Opisana operacja pokazuje, że napastnicy koncentrują się nie tylko na samym uzyskaniu dostępu, ale przede wszystkim na jego długotrwałym utrzymaniu, prowadzeniu ruchu bocznego oraz budowaniu ukrytych punktów pośredniczących wewnątrz środowiska ofiary.

W kampanii wykorzystano dwa odrębne narzędzia: linuxowy implant Showboat oraz windowsowy JFMBackdoor. Taki dobór malware wskazuje na świadome dostosowanie działań do hybrydowych środowisk, typowych dla operatorów telekomunikacyjnych i dużych dostawców usług łączności.

W skrócie

  • Kampania została przypisana grupie Calypso, znanej również jako Red Lamassu.
  • Aktywność ma charakter cyberwywiadowczy i była obserwowana co najmniej od połowy 2022 roku.
  • Celem były podmioty telekomunikacyjne w regionie Azji i Pacyfiku oraz części Bliskiego Wschodu.
  • W systemach Linux używano modułowego implantu Showboat.
  • W środowiskach Windows końcowym ładunkiem był JFMBackdoor uruchamiany z wykorzystaniem DLL sideloading.
  • Główny nacisk położono na persystencję, tunelowanie ruchu oraz skryte operacje wewnątrz sieci.

Kontekst / historia

Telekomunikacja od lat pozostaje jednym z najcenniejszych celów dla grup powiązanych z cyberwywiadem. Infrastruktura operatorów zapewnia dostęp do rozległych systemów IT, danych abonentów, metadanych komunikacyjnych oraz platform wspierających transmisję i zarządzanie usługami. Z punktu widzenia atakujących kompromitacja takiego środowiska może przynieść zarówno korzyści wywiadowcze, jak i operacyjne.

W analizowanej kampanii szczególnie istotna jest jej długotrwałość. Wielomiesięczna, a nawet wieloletnia aktywność sugeruje rozbudowane zaplecze operacyjne, odpowiednie finansowanie oraz zdolność do prowadzenia cierpliwych, trudnych do wykrycia działań. Dodatkowo infrastruktura wykorzystywana przez sprawców miała podszywać się pod podmioty z branży telekomunikacyjnej, co utrudniało identyfikację ruchu i analizę zaplecza ataku.

Analiza techniczna

Showboat, określany także jako kworker, to framework poeksploatacyjny przeznaczony dla systemów Linux. Po wdrożeniu zbiera informacje o hoście i przesyła je do serwera dowodzenia. Malware obsługuje transfer plików, ukrywanie procesu oraz persystencję poprzez tworzenie nowej usługi systemowej.

Na uwagę zasługuje mechanizm ukrywania procesu z użyciem kodu pobieranego z zewnętrznych serwisów internetowych pełniących funkcję dead drop resolver. Takie podejście pozwala operatorom elastycznie zmieniać elementy infrastruktury C2 bez konieczności wymiany całego implantu, a jednocześnie utrudnia analizę kampanii.

Kluczową funkcją Showboat jest także możliwość działania jako proxy SOCKS5 oraz narzędzie do przekierowania portów. W praktyce oznacza to, że przejęty host może zostać użyty jako przekaźnik do dalszego rekonesansu, ruchu bocznego i uzyskiwania dostępu do kolejnych segmentów sieci.

W wariancie windowsowym łańcuch infekcji rozpoczynał się od uruchomienia skryptu wsadowego, który zrzucał komponenty wymagane do procedury DLL sideloading. Wykorzystywano legalny plik fltMC.exe wraz z podstawioną biblioteką FLTLIB.dll, co prowadziło do załadowania JFMBackdoor. Tego typu technika zwiększa skuteczność ataku, ponieważ bazuje na wiarygodnym binarium systemowym i może utrudniać wykrycie przez mniej zaawansowane mechanizmy ochronne.

JFMBackdoor oferuje szeroki zestaw funkcji typowych dla zaawansowanego implantu szpiegowskiego. Obejmuje zdalne wykonywanie poleceń w trybie reverse shell, zarządzanie plikami, tunelowanie TCP, kontrolę procesów i usług, modyfikację rejestru, wykonywanie zrzutów ekranu oraz obsługę zaszyfrowanej konfiguracji. Istotnym elementem są również mechanizmy samooczyszczania i antyforensics, których celem jest ograniczenie liczby artefaktów pozostawianych po operacji.

Konsekwencje / ryzyko

Dla operatorów telekomunikacyjnych zagrożenie nie kończy się na pojedynczym serwerze lub stacji roboczej. Host przejęty przez implant pełniący rolę proxy lub punktu pivot może umożliwić atakującym dostęp do systemów zarządzania, środowisk core, platform OSS/BSS oraz segmentów administracyjnych i monitorujących.

Nawet jeśli głównym celem sprawców pozostaje wywiad, potencjalne skutki biznesowe są poważne. Mogą obejmować wyciek danych, utratę poufności informacji operacyjnych, naruszenie tajemnicy telekomunikacyjnej, a także długotrwałą obecność napastników niewidoczną dla standardowych procedur SOC.

Ryzyko dodatkowo zwiększa wieloplatformowość zestawu narzędzi. Możliwość działania zarówno w systemach Linux, jak i Windows odpowiada realiom współczesnych środowisk telekomunikacyjnych, w których heterogeniczność infrastruktury jest normą. Wykorzystanie legalnych komponentów systemowych, usług persystencji i kanałów tunelowania sprawia, że aktywność złośliwa może przypominać zwykły ruch administracyjny.

Rekomendacje

Organizacje z sektora telekomunikacyjnego powinny potraktować tę kampanię jako sygnał do przeglądu widoczności ruchu east-west oraz połączeń wychodzących z systemów Linux i Windows. Szczególnie istotne jest monitorowanie nietypowych połączeń proxy, przekierowań portów, nowych usług systemowych oraz anomalii w relacjach parent-child procesów.

W środowiskach Windows warto wzmocnić detekcję DLL sideloading, zwłaszcza przypadków uruchamiania zaufanych binariów z niestandardowych lokalizacji oraz ładowania bibliotek o nazwach odpowiadających legalnym komponentom systemowym. Skuteczne może być także łączenie telemetrii EDR z kontrolą integralności plików i regułami wykrywającymi nietypowe użycie narzędzi systemowych.

W systemach Linux rekomendowane jest monitorowanie tworzenia i modyfikacji usług, nietypowych nazw procesów naśladujących komponenty jądra oraz połączeń do zewnętrznych zasobów mogących pełnić funkcję pośrednich kanałów sterowania. Należy również analizować hosty potencjalnie wykorzystywane jako SOCKS5 lub punkty port forwarding.

Na poziomie architektury bezpieczeństwa warto wdrożyć segmentację krytycznych stref, ograniczyć dostęp administracyjny, egzekwować zasadę najmniejszych uprawnień oraz stosować silne uwierzytelnianie dla kont uprzywilejowanych. Uzupełnieniem tych działań powinien być aktywny threat hunting ukierunkowany na długotrwałą persystencję, artefakty antyforensics oraz klastry infrastruktury podszywające się pod branżę telekomunikacyjną.

Podsumowanie

Opisana kampania potwierdza, że ataki na sektor telekomunikacyjny pozostają domeną dojrzałych operacji cyberwywiadowczych, nastawionych na dyskretną i długotrwałą obecność w strategicznych środowiskach. Showboat i JFMBackdoor nie są jedynie narzędziami do infekcji, lecz elementami szerszego zestawu wspierającego persystencję, tunelowanie ruchu oraz dalszą eksplorację sieci ofiary.

Dla zespołów bezpieczeństwa oznacza to konieczność odejścia od skupiania się wyłącznie na pojedynczych wskaźnikach kompromitacji. Kluczowe staje się wykrywanie zachowań wskazujących na pivoting, skrytą persystencję i działania stealth w środowiskach wieloplatformowych.

Źródła

Mythos Nie Wystarczy. Lekcja Z Cloudflare.

Mythos jednak nie taki wspaniały?

Mythos Preview to jeden z tych tematów, przy których łatwo popaść w skrajności. Jedni widzą początek końca klasycznego pentestingu. Drudzy widzą głównie marketing, PR i kolejną falę zachwytu nad AI. Prawda jest mniej wygodna: Mythos jest wystarczająco mocny, żeby potraktować go bardzo poważnie, ale nie jest magicznym inżynierem bezpieczeństwa, którego można podpiąć do repozytorium i powiedzieć: „znajdź wszystko, co groźne”.

Czytaj dalej „Mythos Nie Wystarczy. Lekcja Z Cloudflare.”

DirtyDecrypt: publiczny PoC ujawnia nową lukę eskalacji uprawnień w jądrze Linux

Cybersecurity news

Wprowadzenie do problemu / definicja

DirtyDecrypt to nowa lokalna podatność eskalacji uprawnień w jądrze Linux, oznaczona jako CVE-2026-31635. Luka wynika z błędu klasy page cache write primitive, związanego z nieprawidłową ochroną mechanizmu copy-on-write w ścieżce deszyfrowania pakietów w podsystemie rxgk. W praktyce może to pozwolić lokalnemu atakującemu na modyfikację danych w pamięci współdzielonej lub w pamięci podręcznej uprzywilejowanych plików, a w konsekwencji na uzyskanie uprawnień roota.

W skrócie

Największe znaczenie tej podatności wynika z publicznego udostępnienia działającego proof-of-concept, który obniża próg wejścia dla potencjalnych napastników. Problem nie dotyczy wszystkich dystrybucji Linuxa, lecz przede wszystkim tych, które wykorzystują jądra skompilowane z włączoną opcją CONFIG_RXGK. Wśród wskazywanych środowisk znajdują się między innymi Fedora, Arch Linux oraz openSUSE Tumbleweed, podczas gdy typowe instalacje Ubuntu i Debiana nie są zwykle uznawane za podatne w standardowej konfiguracji.

  • Podatność umożliwia lokalną eskalację uprawnień.
  • Publiczny PoC zwiększa ryzyko praktycznego wykorzystania.
  • Kluczowe znaczenie ma obecność opcji CONFIG_RXGK.
  • Zagrożone są szczególnie systemy wieloużytkownikowe i hosty kontenerowe.

Kontekst / historia

DirtyDecrypt wpisuje się w szerszą serię błędów bezpieczeństwa związanych z naruszeniem integralności page cache w jądrze Linux. Badacze wiążą ją z rodziną podatności podobnych do wcześniejszych przypadków, takich jak Copy Fail, Dirty Frag czy Fragnesia. Wspólną cechą tych problemów jest możliwość modyfikacji danych, które zgodnie z założeniami izolacji pamięci powinny pozostawać odseparowane od innych procesów i kontekstów wykonania.

Luka została nagłośniona w okresie zwiększonego zainteresowania badaczy bezpieczeństwa zagadnieniami związanymi z pamięcią współdzieloną i obsługą page cache w jądrze. Choć wskazywano, że problem może być powiązany z wcześniej naprawianymi błędami, publikacja działającego kodu PoC szybko podniosła rangę zagrożenia. Szczególne obawy dotyczą środowisk, w których atakujący może już uzyskać ograniczony dostęp lokalny, na przykład przez konto użytkownika, powłokę w systemie współdzielonym lub kontener uruchomiony na podatnym hoście.

Analiza techniczna

Źródłem podatności jest funkcja rxgk_decrypt_skb(), odpowiedzialna za obsługę deszyfrowania przychodzących buforów socketów w podsystemie rxgk. Kluczowy problem polega na tym, że podczas operacji zapisu jądro nie zapewnia właściwej ochrony copy-on-write dla współdzielonych stron pamięci. W bezpiecznym modelu przed zapisem powinna zostać utworzona prywatna kopia strony, tak aby zmiany wykonane w jednym kontekście nie wpływały na dane należące do innych procesów lub do page cache powiązanego z plikami systemowymi.

W DirtyDecrypt ten mechanizm nie działa prawidłowo, co otwiera drogę do skierowania zapisu na stronę powiązaną z wrażliwym zasobem. W zależności od scenariusza eksploatacji może to umożliwić modyfikację krytycznych plików, takich jak polityki kontroli dostępu, konfiguracje sudo czy binaria oznaczone bitem SUID. Tego typu zmiany mogą następnie zostać wykorzystane do przejęcia pełnych uprawnień administracyjnych.

Z technicznego punktu widzenia nie jest to jedynie błąd pojedynczej aplikacji userspace, ale naruszenie podstawowych założeń izolacji pamięci na poziomie jądra. To właśnie dlatego luka ma szczególnie wysoki ciężar operacyjny i powinna być traktowana jako realny wektor post-exploitation, a nie jedynie ciekawostka badawcza.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją DirtyDecrypt jest możliwość lokalnego podniesienia uprawnień do poziomu root. Oznacza to, że nawet ograniczony dostęp do systemu może w sprzyjających warunkach doprowadzić do pełnego przejęcia hosta. Szczególnie narażone są środowiska wieloużytkownikowe, serwery współdzielone, zaplecza deweloperskie oraz infrastruktura, w której użytkownicy lub procesy mają możliwość uruchamiania własnego kodu.

Ryzyko dodatkowo wzrasta w środowiskach kontenerowych. Jeśli podatny pozostaje sam host, luka może zostać wykorzystana jako element ucieczki z izolowanego środowiska i przejęcia kontroli nad systemem bazowym. W efekcie lokalna podatność jednego użytkownika lub kontenera może przełożyć się na zagrożenie dla wielu usług, danych i tenantów działających na tym samym węźle.

  • Możliwość uzyskania uprawnień roota przez lokalnego użytkownika.
  • Wyższe ryzyko w systemach z dostępem shell dla wielu osób.
  • Potencjalny wpływ na hosty uruchamiające kontenery.
  • Skrócony czas reakcji obronnej ze względu na publiczny PoC.

Rekomendacje

Najważniejszym krokiem jest ustalenie, czy używane jądra zostały skompilowane z włączoną opcją CONFIG_RXGK. To właśnie ta cecha konfiguracji pozwala ocenić, czy dane środowisko znajduje się w realnej strefie ryzyka. Organizacje powinny niezwłocznie przeprowadzić inwentaryzację podatnych systemów, zwłaszcza jeśli korzystają z Fedory, Arch Linuxa, openSUSE Tumbleweed lub niestandardowych buildów kernela.

Z perspektywy operacyjnej zalecane są następujące działania:

  • pilne wdrożenie aktualizacji jądra oraz zaleceń publikowanych przez dostawcę dystrybucji,
  • weryfikacja konfiguracji kernela w obrazach bazowych, pipeline’ach CI/CD i środowiskach testowych,
  • ograniczenie lokalnego dostępu interaktywnego dla nieuprzywilejowanych użytkowników,
  • monitorowanie nietypowych zmian w plikach systemowych, konfiguracjach sudo i plikach SUID,
  • przegląd bezpieczeństwa hostów kontenerowych oraz dodatkowa segmentacja wrażliwych workloadów,
  • wdrożenie działań kompensujących tam, gdzie poprawki nie mogą zostać zastosowane natychmiast.

W organizacjach o podwyższonym profilu ryzyka warto także tymczasowo ograniczyć możliwość uruchamiania niezweryfikowanego kodu lokalnie oraz zredukować liczbę kont z dostępem shell. Tego rodzaju środki nie usuwają samej podatności, ale mogą znacząco utrudnić jej praktyczne wykorzystanie.

Podsumowanie

DirtyDecrypt pokazuje, że błędy związane z page cache i ochroną copy-on-write nadal należą do najbardziej niebezpiecznych klas podatności w jądrze Linux. Choć problem nie obejmuje wszystkich dystrybucji, połączenie możliwości uzyskania roota i publicznie dostępnego kodu PoC czyni tę lukę poważnym zagrożeniem dla podatnych środowisk. Administratorzy powinni jak najszybciej ustalić, czy ich systemy wykorzystują CONFIG_RXGK, a następnie wdrożyć poprawki i działania ograniczające ryzyko.

Źródła

  1. Security Affairs — https://securityaffairs.com/192436/uncategorized/dirtydecrypt-poc-released-for-yet-another-linux-flaw.html
  2. NVD: CVE-2026-31635 — https://nvd.nist.gov/vuln/detail/CVE-2026-31635
  3. DirtyDecrypt PoC Repository — https://github.com/zellic/DirtyDecrypt
  4. Moselwal — DirtyDecrypt technical analysis — https://moselwal.com/dirtydecrypt-linux-kernel-lpe/
  5. Kernel Config Reference: CONFIG_RXGK — https://www.kernelconfig.io/config_rxgk

PinTheft: nowy exploit lokalnej eskalacji uprawnień do roota w Arch Linux

Cybersecurity news

Wprowadzenie do problemu / definicja

PinTheft to nowo ujawniona podatność lokalnej eskalacji uprawnień w jądrze Linux, która może umożliwić atakującemu z dostępem do zwykłego konta użytkownika przejęcie uprawnień roota. Problem dotyczy ścieżki zerocopy w module RDS i choć został już załatany, publiczne udostępnienie kodu PoC wyraźnie zwiększa ryzyko praktycznego wykorzystania luki.

Z perspektywy bezpieczeństwa jest to szczególnie istotne w środowiskach, w których aktualizacje jądra są wdrażane z opóźnieniem. Nawet jeśli powierzchnia ataku nie jest uniwersalna, publiczny exploit obniża próg wejścia dla cyberprzestępców i zwiększa presję na szybkie działania obronne.

W skrócie

PinTheft został opisany jako lokalny błąd eskalacji uprawnień w jądrze Linux. Mechanizm wykorzystania opiera się na podwójnym zwolnieniu zasobów w ścieżce RDS zerocopy, co może zostać przekształcone w nadpisanie page cache przy użyciu io_uring fixed buffers.

  • podatność umożliwia przejście z konta lokalnego użytkownika do roota,
  • publiczny kod PoC zwiększa ryzyko szybkiego wykorzystania w praktyce,
  • najbardziej narażone są systemy z aktywnym modułem RDS,
  • kluczową metodą ograniczenia ryzyka pozostaje szybka aktualizacja jądra.

Kontekst / historia

Luka została załatana na początku maja 2026 roku, a 20 maja 2026 roku pojawiły się informacje o publicznie dostępnym exploicie PoC. W chwili ujawnienia podatność nie miała jeszcze jednoznacznie przypisanego identyfikatora CVE, co może utrudniać jej śledzenie w części procesów compliance i narzędzi do zarządzania podatnościami.

PinTheft wpisuje się w szerszy trend ujawniania lokalnych błędów eskalacji uprawnień w Linuksie. Ostatnie miesiące pokazały, że mechanizmy pamięci, buforowania i ścieżki wejścia/wyjścia w jądrze pozostają jednym z najważniejszych obszarów ryzyka dla administratorów oraz zespołów bezpieczeństwa.

Analiza techniczna

Źródłem problemu jest obsługa ścieżki RDS zerocopy send path. W uproszczeniu mechanizm przypinania stron pamięci użytkownika działa strona po stronie. Gdy w późniejszym etapie przetwarzania dochodzi do błędu, wcześniej przypięte strony są zwalniane, ale część struktur odpowiedzialnych za opis scatterlist i liczników pozostaje aktywna.

To prowadzi do sytuacji, w której te same zasoby mogą zostać ponownie zwolnione podczas kolejnego etapu czyszczenia komunikatu RDS. Taki stan otwiera drogę do utraty referencji do stron pamięci. W opisanym scenariuszu exploit wykorzystuje ten mechanizm do przejęcia referencji FOLL_PIN, a następnie z użyciem io_uring fixed buffers umożliwia kontrolowany wpływ na pamięć i finalnie uzyskanie uprawnień roota.

Skuteczne wykorzystanie podatności wymaga jednak spełnienia określonych warunków. Potrzebny jest załadowany moduł RDS, aktywne io_uring, obecność czytelnego pliku SUID-root oraz zgodna architektura x86_64 dla przygotowanego ładunku. Oznacza to, że nie każda instalacja Linuxa będzie w praktyce tak samo podatna, ale systemy spełniające te wymagania pozostają realnie zagrożone.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją PinTheft jest możliwość pełnego przejęcia hosta po wcześniejszym uzyskaniu dostępu do zwykłego konta użytkownika. W praktyce oznacza to, że phishing, kradzież poświadczeń, malware, błędna konfiguracja SSH lub inny lokalny punkt wejścia mogą stać się jedynie pierwszym etapem ataku.

Ryzyko jest szczególnie wysokie w środowiskach deweloperskich, laboratoryjnych oraz CI/CD, gdzie wielu użytkowników pracuje lokalnie na hostach Linux i gdzie restarty związane z aktualizacją jądra bywają odkładane. Publiczna dostępność PoC dodatkowo zwiększa prawdopodobieństwo pojawienia się kolejnych wariantów exploita oraz prób automatyzacji ataków.

  • eskalacja uprawnień do poziomu roota,
  • pełna kompromitacja hosta po przejęciu zwykłego konta,
  • wyższe ryzyko w środowiskach wieloużytkownikowych,
  • większa presja na szybkie patchowanie z powodu publicznego PoC.

Rekomendacje

Podstawowym działaniem ochronnym jest natychmiastowa aktualizacja jądra Linux do wersji dostarczonej przez dystrybucję z odpowiednią poprawką. Organizacje powinny możliwie szybko ustalić, które hosty korzystają z podatnych konfiguracji, i nadać aktualizacji wysoki priorytet.

Jeżeli wdrożenie poprawek musi zostać odłożone, warto tymczasowo wyłączyć moduły rds oraz rds_tcp, a także zablokować ich ponowne ładowanie. To znacząco ogranicza możliwość wykorzystania opisanego scenariusza ataku.

  • zidentyfikować hosty z podatnym jądrem i aktywnym RDS,
  • wdrożyć poprawki jądra w trybie priorytetowym,
  • tymczasowo wyłączyć moduły rds i rds_tcp,
  • ograniczyć lokalny dostęp użytkowników do wrażliwych systemów,
  • przejrzeć obecność i zasadność plików SUID-root,
  • monitorować użycie io_uring i ładowanie modułów jądra,
  • skrócić czas między publikacją poprawek a ich wdrożeniem.

W środowiskach o podwyższonych wymaganiach bezpieczeństwa warto również ocenić, czy moduł RDS jest rzeczywiście potrzebny. Jeżeli nie jest wykorzystywany operacyjnie, jego trwałe wyłączenie może zmniejszyć ekspozycję nie tylko na PinTheft, ale również na przyszłe błędy w tym obszarze.

Podsumowanie

PinTheft pokazuje, że nawet relatywnie wąska podatność lokalna może stać się poważnym zagrożeniem, jeśli pojawia się publiczny exploit i istnieje możliwość szybkiego przejścia do uprawnień roota. Choć nie każda dystrybucja i konfiguracja Linuxa jest jednakowo narażona, przypadki z aktywnym RDS i opóźnionym patchowaniem powinny być traktowane jako obszar podwyższonego ryzyka.

Z perspektywy obronnej najważniejsze są szybkie aktualizacje jądra, ograniczanie zbędnych modułów oraz konsekwentny hardening systemów Linux. To właśnie połączenie patch managementu, kontroli konfiguracji i monitoringu lokalnych prób eskalacji uprawnień pozostaje najlepszą odpowiedzią na klasę zagrożeń reprezentowaną przez PinTheft.

Źródła

  1. Exploit released for new PinTheft Arch Linux root escalation flaw — https://www.bleepingcomputer.com/news/linux/exploit-released-for-new-pintheft-arch-linux-root-escalation-flaw/
  2. V12 Security advisory for PinTheft — https://github.com/v12-dev/pocs/tree/main/CVE-2026-xxxx-pintheft
  3. Linux kernel patch discussion for the RDS zerocopy issue — https://lore.kernel.org/

DirtyDecrypt (CVE-2026-31635): publiczny PoC zwiększa ryzyko eskalacji uprawnień w Linuksie

Cybersecurity news

Wprowadzenie do problemu / definicja

DirtyDecrypt, oznaczony jako CVE-2026-31635, to poważna podatność lokalnej eskalacji uprawnień w jądrze Linux. Luka wynika z nieprawidłowej obsługi mechanizmu copy-on-write podczas przetwarzania odszyfrowywanych buforów sieciowych, co może umożliwić użytkownikowi bez uprawnień administracyjnych wpływ na dane należące do bardziej uprzywilejowanych procesów lub do pamięci podręcznej chronionych plików.

Znaczenie problemu istotnie wzrosło po opublikowaniu publicznego kodu proof-of-concept. Taki rozwój sytuacji zwykle przyspiesza powstawanie kolejnych wariantów exploitów i skraca czas reakcji dostępny zespołom odpowiedzialnym za bezpieczeństwo.

W skrócie

  • CVE-2026-31635, znane jako DirtyDecrypt lub DirtyCBC, dotyczy jądra Linux.
  • Podatność jest błędem typu Local Privilege Escalation.
  • Źródłem problemu jest brak właściwej ochrony copy-on-write w ścieżce rxgk_decrypt_skb().
  • Skutkiem może być modyfikacja współdzielonych stron pamięci, a w konsekwencji wpływ na dane procesów uprzywilejowanych lub page cache chronionych plików.
  • Najbardziej narażone są systemy z aktywnym CONFIG_RXGK.
  • Publicznie dostępny PoC zwiększa prawdopodobieństwo szybkiej operacjonalizacji ataków.

Kontekst / historia

Podatność została zgłoszona w maju 2026 roku i wpisuje się w szerszą klasę błędów związanych z nieprawidłową obsługą zapisu do współdzielonych stron pamięci w jądrze Linux. W ostatnim czasie badacze bezpieczeństwa zwracają uwagę na rosnącą liczbę luk wykorzystujących subtelne zależności pomiędzy page cache, buforami jądra oraz mechanizmem copy-on-write.

DirtyDecrypt jest kolejnym przykładem tego typu problemów. Chociaż wymaga lokalnego dostępu do systemu, może stanowić bardzo skuteczny element łańcucha ataku po wcześniejszym uzyskaniu ograniczonego dostępu. Upublicznienie kodu demonstracyjnego dodatkowo zwiększa presję na szybkie działania naprawcze.

Analiza techniczna

Sedno podatności znajduje się w funkcji rxgk_decrypt_skb(), odpowiedzialnej za określoną ścieżkę odszyfrowywania przychodzących buforów sk_buff. W prawidłowym modelu bezpieczeństwa Linux modyfikacja współdzielonej strony pamięci powinna zostać poprzedzona utworzeniem prywatnej kopii, tak aby zapis nie wpływał na inne obiekty korzystające z tej samej strony.

W przypadku DirtyDecrypt ten warunek nie jest zachowany w odpowiedni sposób. W rezultacie zapis może objąć stronę, która nadal pozostaje współdzielona. To z kolei otwiera drogę do nadpisania danych obecnych w pamięci procesów uprzywilejowanych albo do modyfikacji page cache dla plików mających istotne znaczenie dla bezpieczeństwa systemu.

Techniczna istota zagrożenia polega na tym, że atak nie musi opierać się wyłącznie na klasycznej modyfikacji danych na dysku. Wystarczy przejęcie kontroli nad reprezentacją danych w pamięci podręcznej jądra, aby wpłynąć na sposób ich odczytu przez system i procesy działające z wyższymi uprawnieniami.

Problem dotyczy przede wszystkim konfiguracji, w których aktywne jest CONFIG_RXGK. Oznacza to, że nie wszystkie instalacje Linuksa są automatycznie narażone, jednak w praktyce powierzchnia ataku może obejmować wybrane współczesne dystrybucje desktopowe, rolling-release, środowiska deweloperskie oraz niektóre hosty wielodostępowe i kontenerowe.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem wykorzystania CVE-2026-31635 jest możliwość uzyskania uprawnień roota przez lokalnego użytkownika. W praktyce oznacza to pełne przejęcie hosta, instalację mechanizmów persistence, wyłączenie narzędzi ochronnych, kradzież sekretów oraz wykorzystanie systemu jako punktu wyjścia do dalszych działań w sieci organizacji.

Ryzyko rośnie szczególnie w środowiskach współdzielonych, gdzie z jednego systemu korzysta wielu użytkowników albo wiele różnych obciążeń aplikacyjnych. Podatność może być również atrakcyjna w infrastrukturze kontenerowej jako element większego łańcucha post-exploitation prowadzącego do kompromitacji hosta.

Dostępność publicznego PoC dodatkowo zwiększa zagrożenie. Gdy kod demonstracyjny trafia do otwartego obiegu, próg wejścia dla atakujących znacząco się obniża, a czas potrzebny do opracowania bardziej stabilnych wariantów eksploatacji zwykle się skraca.

Rekomendacje

Priorytetem powinno być potwierdzenie, czy używane wersje jądra zawierają poprawkę dla CVE-2026-31635 oraz czy dana konfiguracja obejmuje aktywne CONFIG_RXGK. Organizacje powinny jak najszybciej przeanalizować biuletyny bezpieczeństwa dostawców dystrybucji i wdrożyć zaktualizowane pakiety kernela, a następnie przeprowadzić restart hostów.

Do czasu pełnego załatania środowiska warto ograniczyć możliwość lokalnego uruchamiania niezatwierdzonego kodu, szczególnie przez użytkowników z dostępem do powłoki. Zalecane jest także zwiększenie monitoringu pod kątem prób eskalacji uprawnień oraz nietypowych zmian dotyczących kluczowych plików i procesów uprzywilejowanych.

  • Przeprowadzić inwentaryzację wersji jądra na wszystkich hostach.
  • Zweryfikować konfigurację kompilacji jądra pod kątem CONFIG_RXGK.
  • Wdrożyć poprawki bezpieczeństwa i wykonać restart systemów.
  • Ograniczyć lokalny dostęp interaktywny tam, gdzie nie jest niezbędny.
  • Wzmocnić detekcję zdarzeń LPE w EDR i SIEM.
  • Monitorować anomalie związane z SUID, sudoers i integralnością plików systemowych.
  • Oddzielić obciążenia o różnym poziomie zaufania w środowiskach kontenerowych.

Podsumowanie

DirtyDecrypt, czyli CVE-2026-31635, to istotna podatność lokalnej eskalacji uprawnień w jądrze Linux, której znaczenie wzrosło po publikacji publicznego kodu PoC. Błąd związany z niewłaściwą obsługą copy-on-write w ścieżce rxgk_decrypt_skb() może umożliwić modyfikację wrażliwych danych w pamięci i doprowadzić do pełnej kompromitacji systemu.

Dla zespołów bezpieczeństwa i administratorów oznacza to konieczność szybkiej weryfikacji narażonych konfiguracji, wdrożenia poprawek oraz traktowania tej luki jako realnego zagrożenia post-exploitation, zwłaszcza w środowiskach wielodostępowych i kontenerowych.

Źródła

  1. https://thehackernews.com/2026/05/dirtydecrypt-poc-released-for-linux.html
  2. https://nvd.nist.gov/vuln/detail/CVE-2026-31635
  3. https://github.com/
  4. https://www.kernelconfig.io/
  5. https://lore.kernel.org/

Złośliwe pakiety npm dostarczają infostealery i bota DDoS Phantom Bot

Cybersecurity news

Wprowadzenie do problemu / definicja

Ekosystem npm pozostaje jednym z najczęściej atakowanych elementów łańcucha dostaw oprogramowania. Najnowsza kampania pokazuje, że cyberprzestępcy nadal skutecznie wykorzystują zaufanie programistów do bibliotek open source, publikując pakiety zawierające kod kradnący dane oraz komponenty służące do budowy botnetu DDoS.

Szczególnie niepokojące jest to, że część wykorzystywanego kodu bazuje na wcześniej ujawnionym narzędziu Shai-Hulud. Oznacza to, że publicznie dostępne ofensywne projekty mogą bardzo szybko zostać zaadaptowane do realnych kampanii wymierzonych w deweloperów, zespoły DevOps i organizacje korzystające z automatyzacji CI/CD.

W skrócie

Badacze bezpieczeństwa zidentyfikowali cztery złośliwe pakiety npm opublikowane z jednego konta. Były to: chalk-tempalte, @deadcode09284814/axios-util, axois-utils oraz color-style-utils.

  • Trzy pakiety działały jako infostealery kradnące dane i sekrety.
  • Pakiet axois-utils dostarczał dodatkowo bota DDoS Phantom Bot.
  • Pakiet chalk-tempalte zawierał klon robaka Shai-Hulud.
  • Kampania łączyła typo-squatting, kradzież sekretów i elementy trwałej infekcji hosta.

Kontekst / historia

Ataki na rejestry pakietów open source od lat należą do najskuteczniejszych metod kompromitacji środowisk developerskich. npm jest szczególnie atrakcyjnym celem ze względu na ogromną skalę wykorzystania, częste automatyczne instalacje zależności oraz silne powiązanie z procesami build i deployment.

Obecna kampania wpisuje się w szerszy trend wtórnego wykorzystywania publicznie ujawnionego kodu ofensywnego. Po upublicznieniu Shai-Hulud pojawiło się wysokie ryzyko, że mniej zaawansowani aktorzy zaczną kopiować jego mechanizmy i wdrażać je w złośliwych bibliotekach. Wykrycie pakietu chalk-tempalte pokazuje, że ten scenariusz szybko się zmaterializował.

Równie istotne są same nazwy pakietów. Atakujący zastosowali techniki imitowania legalnych bibliotek i tworzenia nazw łudząco podobnych do popularnych modułów, co zwiększa prawdopodobieństwo przypadkowej instalacji przez programistę lub pipeline automatyzacyjny.

Analiza techniczna

Zidentyfikowane pakiety nie były jednorodne pod względem funkcjonalnym, mimo że opublikowano je z jednego konta. To sugeruje, że operator kampanii testował różne ładunki i scenariusze infekcji w ramach jednego ciągu działań.

Pakiet axois-utils został powiązany z botem DDoS Phantom Bot napisanym w Go. Malware obsługiwało generowanie ruchu z wykorzystaniem protokołów HTTP, TCP i UDP, co wskazuje na możliwość prowadzenia różnego typu ataków wolumetrycznych i aplikacyjnych. Dodatkowo wdrażano mechanizmy persystencji, dzięki którym infekcja mogła przetrwać restart systemu.

W środowiskach Windows złośliwy komponent miał dodawać się do folderu autostartu oraz tworzyć zadanie harmonogramu. W praktyce oznacza to, że jednorazowe pobranie zależności mogło skutkować długotrwałym wykorzystaniem stacji roboczej jako węzła botnetu.

Pozostałe pakiety koncentrowały się na kradzieży danych. Zakres wykradanych informacji obejmował między innymi klucze SSH, zmienne środowiskowe, dane chmurowe, informacje systemowe, adres IP oraz artefakty związane z portfelami kryptowalutowymi. Taki zestaw jest szczególnie niebezpieczny dla organizacji programistycznych, ponieważ otwiera drogę do dalszej eskalacji i przejęcia krytycznych zasobów.

Najbardziej interesującym elementem kampanii był pakiet chalk-tempalte, który zawierał klon Shai-Hulud. Według dostępnych analiz kod został wykorzystany niemal bez zmian, ale skonfigurowany do współpracy z własną infrastrukturą dowodzenia i kontroli oraz odrębnym kluczem prywatnym. Wykradzione tokeny GitHub mogły być następnie używane do publikowania danych przez API do publicznych repozytoriów, co zwiększało skalę i szybkość eksfiltracji.

Kampania pokazuje kilka charakterystycznych cech współczesnych ataków supply chain:

  • uruchamianie złośliwego kodu już na etapie instalacji zależności,
  • kradzież sekretów deweloperskich i poświadczeń chmurowych,
  • wykorzystanie zewnętrznej infrastruktury C2,
  • wdrażanie mechanizmów persystencji,
  • łączenie infostealera z funkcjami destrukcyjnymi lub ofensywnymi, takimi jak DDoS.

Konsekwencje / ryzyko

Skutki takiego incydentu wykraczają poza pojedynczą stację roboczą. Na poziomie hosta kompromitacja może oznaczać wyciek kluczy SSH, tokenów GitHub, sekretów aplikacyjnych i danych środowiskowych. Na poziomie zespołu może prowadzić do przejęcia repozytoriów, pipeline’ów CI/CD, kont serwisowych i infrastruktury chmurowej.

Dla przedsiębiorstw największym zagrożeniem jest efekt kaskadowy. Jeśli napastnik uzyska dostęp do rejestrów pakietów, systemów budowania lub kont publikacyjnych, organizacja może nieświadomie stać się źródłem dalszej dystrybucji złośliwego oprogramowania do klientów, partnerów i społeczności open source.

Dodatkowe ryzyko wynika z połączenia infostealera z botem DDoS. Zainfekowane systemy mogą jednocześnie tracić poufne dane i uczestniczyć w atakach na zewnętrzne cele. To zwiększa zarówno skalę incydentu, jak i potencjalne konsekwencje prawne, operacyjne oraz reputacyjne.

Rekomendacje

Organizacje korzystające z npm powinny potraktować ten incydent jako sygnał do pilnego przeglądu procesów związanych z bezpieczeństwem łańcucha dostaw oprogramowania.

  • Zweryfikować, czy wskazane pakiety nie pojawiły się w projektach, plikach lock, cache narzędzi build, obrazach kontenerowych oraz środowiskach CI/CD.
  • Po wykryciu instalacji przeprowadzić pełną rotację sekretów, w tym tokenów GitHub, kluczy SSH, poświadczeń chmurowych i sekretów aplikacyjnych.
  • Sprawdzić historię publikacji, nietypowe commity i nowe publiczne repozytoria mogące świadczyć o nadużyciu kont programistów.
  • Przeanalizować autostart, zadania harmonogramu, nietypowe procesy w Go oraz połączenia sieciowe do nieznanej infrastruktury.
  • Wdrożyć pinning wersji, rygorystyczną kontrolę plików lock i ograniczenie automatycznych aktualizacji bez walidacji.
  • Rozważyć użycie prywatnych mirrorów lub proxy dla pakietów oraz skanowanie zależności pod kątem złośliwych skryptów instalacyjnych.
  • Egzekwować zasadę najmniejszych uprawnień dla tokenów deweloperskich i odseparować środowiska build od systemów produkcyjnych.

Zespoły SOC i DevSecOps powinny również rozszerzyć detekcję o wskaźniki kompromitacji związane z eksfiltracją sekretów, publikacją danych do repozytoriów GitHub oraz persystencją na systemach Windows i Linux.

Podsumowanie

Nowa kampania wymierzona w npm pokazuje, że ataki na łańcuch dostaw stają się coraz bardziej modularne, skalowalne i łatwe do odtworzenia przez kolejnych aktorów. Cztery wykryte pakiety łączyły funkcje kradzieży danych z dystrybucją bota DDoS, a jeden z nich wykorzystywał klon wcześniej ujawnionego robaka Shai-Hulud.

Dla organizacji to wyraźne ostrzeżenie, że bezpieczeństwo zależności open source nie może być traktowane wyłącznie jako problem programistyczny. Kluczowe znaczenie mają szybka identyfikacja zainfekowanych komponentów, pełna rotacja poświadczeń oraz wzmocnienie kontroli nad npm, procesami CI/CD i zarządzaniem sekretami.

Źródła

  1. Four Malicious npm Packages Deliver Infostealers and Phantom Bot DDoS Malware — https://thehackernews.com/2026/05/four-malicious-npm-packages-deliver.html
  2. TeamPCP Copycats: New Actors Deploy Shai-Hulud Clones — https://www.ox.security/blog/new-actors-deploy-shai-hulud-clones-teampcp-copycats-are-here/
  3. Leaked Shai-Hulud malware fuels new npm infostealer campaign — https://www.bleepingcomputer.com/news/security/leaked-shai-hulud-malware-fuels-new-npm-infostealer-campaign/

Pwn2Own Berlin 2026: 47 podatności zero-day i 1,29 mln dolarów nagród

Cybersecurity news

Wprowadzenie do problemu / definicja

Pwn2Own to jeden z najważniejszych konkursów bezpieczeństwa ofensywnego na świecie, w ramach którego badacze prezentują skuteczne ataki na w pełni załatane produkty z użyciem wcześniej nieujawnionych podatności typu zero-day. Edycja Pwn2Own Berlin 2026 potwierdziła, że współczesna powierzchnia ataku obejmuje już nie tylko przeglądarki czy systemy operacyjne, ale również środowiska enterprise, platformy wirtualizacyjne, kontenery oraz rozwiązania oparte na sztucznej inteligencji.

W praktyce konkurs stanowi cenne źródło wiedzy dla producentów i zespołów bezpieczeństwa, ponieważ pokazuje, które klasy błędów nadal umożliwiają przełamywanie zabezpieczeń nawet w aktualnych wersjach popularnych produktów.

W skrócie

Podczas Pwn2Own Berlin 2026 badacze zdobyli łącznie 1 298 250 dolarów za ujawnienie 47 podatności zero-day. Wydarzenie odbyło się od 14 do 16 maja 2026 roku w trakcie konferencji OffensiveCon i skupiało się przede wszystkim na technologiach korporacyjnych oraz systemach AI.

  • Łączna wartość nagród wyniosła 1 298 250 dolarów.
  • Badacze ujawnili 47 podatności zero-day.
  • Najwyższa pojedyncza nagroda wyniosła 200 000 dolarów.
  • Najbardziej wartościowy atak dotyczył Microsoft Exchange i prowadził do zdalnego wykonania kodu z uprawnieniami SYSTEM.
  • Zwycięzcą klasyfikacji Master of Pwn zostało DEVCORE z wynikiem 50,5 punktu i 505 000 dolarów nagród.

Kontekst / historia

Pwn2Own od lat łączy prestiżową rywalizację z praktycznym modelem odpowiedzialnego ujawniania podatności. Uczestnicy muszą atakować systemy w aktualnym, poprawionym stanie, co pozwala realistycznie ocenić odporność nowoczesnych produktów na zaawansowane techniki eksploatacji.

Edycja berlińska w 2026 roku objęła szeroki zakres kategorii: przeglądarki internetowe, aplikacje korporacyjne, lokalne eskalacje uprawnień, serwery, środowiska local inference, rozwiązania cloud-native, kontenery, wirtualizację oraz systemy wykorzystujące duże modele językowe. To wyraźnie pokazuje, że zainteresowanie rynku przesuwa się z pojedynczych aplikacji klienckich w stronę całych stosów infrastrukturalnych i platform AI.

W porównaniu z poprzednią edycją konkursu tegoroczne wyniki oznaczają zauważalny wzrost zarówno liczby skutecznych demonstracji, jak i całkowitej puli wypłat. To istotny sygnał, że złożoność środowisk enterprise i AI przekłada się także na większą liczbę potencjalnych wektorów ataku.

Analiza techniczna

Najważniejszym wnioskiem technicznym z Pwn2Own Berlin 2026 jest skuteczność ataków łańcuchowych. Najwyżej wyceniona demonstracja polegała na połączeniu trzech błędów, co pozwoliło osiągnąć zdalne wykonanie kodu z uprawnieniami SYSTEM w Microsoft Exchange. Tego rodzaju scenariusze są szczególnie groźne, ponieważ pojedyncze podatności o umiarkowanym wpływie mogą po połączeniu doprowadzić do pełnego przejęcia systemu.

Podczas konkursu skutecznie zaatakowano również takie produkty jak Microsoft Edge, Microsoft SharePoint, Windows 11, Red Hat Enterprise Linux for Workstations, VMware ESXi oraz NVIDIA Container Toolkit. Oznacza to, że podatności wykryto w wielu warstwach stosu technologicznego — od silników przeglądarek i aplikacji korporacyjnych, przez systemy operacyjne, po hipernadzorców i komponenty kontenerowe.

Szczególnie istotne są przypadki lokalnej eskalacji uprawnień w Windows 11 i RHEL. Tego rodzaju błędy często nie są początkowym wektorem wejścia, ale odgrywają kluczową rolę w fazie post-exploitation. Po uzyskaniu ograniczonego dostępu napastnik może dzięki nim przejąć pełną kontrolę nad hostem, pozyskać poświadczenia, wyłączyć mechanizmy ochronne lub utrzymać trwałą obecność w środowisku.

Na uwagę zasługują także udane demonstracje w obszarze środowisk AI i agentów kodujących. To ważny sygnał, że narzędzia oparte na modelach językowych stają się pełnoprawnym celem badań ofensywnych. W takich przypadkach zagrożenia mogą wynikać nie tylko z klasycznych błędów pamięci czy logiki aplikacji, ale również ze słabości integracyjnych, nadmiernych uprawnień agentów, niewystarczającej walidacji danych wejściowych oraz niejasnych granic izolacji między modelem a systemem operacyjnym.

Po zakończeniu konkursu obowiązuje standardowy 90-dniowy okres na przygotowanie i wydanie poprawek przez producentów przed publicznym ujawnieniem technicznych szczegółów. Dla organizacji oznacza to ograniczone okno czasowe na przygotowanie planu reagowania, testowanie obejść oraz monitorowanie prób potencjalnego wykorzystania tych klas podatności.

Konsekwencje / ryzyko

Wyniki Pwn2Own Berlin 2026 pokazują, że nawet dojrzałe i szeroko wdrożone platformy nadal zawierają błędy umożliwiające skuteczne przełamanie zabezpieczeń. Dla organizacji korzystających z Exchange, SharePoint, Windows 11, RHEL, VMware ESXi czy środowisk kontenerowych to wyraźny sygnał, że sam aktualny poziom poprawek nie gwarantuje pełnego bezpieczeństwa.

Największe ryzyko dotyczy systemów o wysokiej wartości biznesowej i dużej ekspozycji administracyjnej, takich jak serwery pocztowe, platformy współpracy, hosty wirtualizacyjne oraz infrastruktura kontenerowa. Podatności prowadzące do zdalnego wykonania kodu lub eskalacji uprawnień mogą skutkować przejęciem środowiska, ruchem bocznym, dostępem do danych wrażliwych, sabotażem usług lub wdrożeniem ransomware.

Dodatkowym zagrożeniem jest sam fakt publicznego potwierdzenia skuteczności exploitów wobec konkretnych produktów. Nawet bez pełnych szczegółów technicznych taka informacja może skłonić grupy cyberprzestępcze oraz podmioty APT do intensywniejszych prób odtworzenia podobnych technik ataku.

Rekomendacje

Organizacje powinny potraktować wyniki konkursu jako sygnał do przeglądu priorytetów w obszarze hardeningu, monitoringu i reagowania na nowe podatności. Szczególnej uwagi wymagają systemy i komponenty wskazane podczas konkursu.

  • Przyspieszyć proces zarządzania poprawkami dla Exchange, SharePoint, Windows 11, RHEL, VMware ESXi oraz komponentów kontenerowych.
  • Przygotować listę zasobów krytycznych i zależności, aby skrócić czas wdrażania aktualizacji po publikacji poprawek.
  • Ograniczać uprawnienia i segmentować środowisko administracyjne, aby utrudnić wykorzystanie podatności eskalacji uprawnień.
  • Wzmocnić telemetrię i detekcję zachowań post-exploitation, w tym monitorowanie nietypowych procesów, prób podnoszenia uprawnień i zmian mechanizmów trwałości.
  • Rozwijać warstwy ochrony kompensacyjnej, takie jak izolacja usług, kontrola aplikacji, reguły sieciowe i ograniczanie powierzchni ataku.
  • Przygotować scenariusze threat hunting dla produktów objętych konkursem oraz aktywnie analizować logi, dane EDR i telemetrię SIEM.
  • W środowiskach AI monitorować uprawnienia agentów, wykonywanie poleceń, połączenia wychodzące i interakcje z lokalnym systemem.

Podsumowanie

Pwn2Own Berlin 2026 pokazał, że krajobraz zagrożeń przesuwa się w stronę złożonych, wieloetapowych ataków obejmujących systemy operacyjne, aplikacje korporacyjne, platformy wirtualizacyjne, kontenery i rozwiązania AI. Łącznie 47 podatności zero-day oraz ponad 1,29 mln dolarów nagród potwierdzają, że nawet dojrzałe produkty pozostają podatne na zaawansowane badania ofensywne.

Dla obrońców najważniejszy wniosek jest praktyczny: utrzymywanie aktualnych poprawek to za mało. Konieczne są dodatkowe warstwy ochrony, segmentacja, monitoring aktywności post-exploitation oraz gotowość do szybkiego reagowania na nowe biuletyny i poprawki producentów.

Źródła

  1. Pwn2Own Berlin 2026: Hackers earn $1,298,250 for 47 zero-days at Pwn2Own Berlin 2026 — https://www.bleepingcomputer.com/news/security/hackers-earn-1-298-250-for-47-zero-days-at-pwn2own-berlin-2026/
  2. Trend Micro Zero Day Initiative — Pwn2Own Berlin 2026, Day Three Results — https://www.zerodayinitiative.com/blog/2026/5/16/pwn2own-berlin-2026-day-three-results
  3. Trend Micro Zero Day Initiative — Pwn2Own Berlin 2026, Day Two Results — https://www.zerodayinitiative.com/blog/2026/5/15/pwn2own-berlin-2026-day-two-results
  4. Trend Micro Zero Day Initiative — Pwn2Own Berlin 2026, Day One Results — https://www.zerodayinitiative.com/blog/2026/5/14/pwn2own-berlin-2026-day-one-results
  5. OffensiveCon — Event information — https://www.offensivecon.org/