27 października 2026 roku CISA dodała do katalogu znanych wykorzystywanych podatności (KEV) dwie aktywnie eksploatowane luki, z federalnym terminem usunięcia wyznaczonym na 10 listopada:
CVE-2026-111497, błąd w bibliotece kompresji Brotli firmy Google, oceniony na CVSS 9,2, znany jako Node2Shell, a ostatnio również Broccoli2Shell
CVE-2026-48356, luka nieograniczonego przesyłania plików w Adobe Commerce i Magento, oceniona jako krytyczna, znana jako PolyShell
Jedna korekta przed wszystkim innym, bo zmienia sposób traktowania obu tych spraw. Żadna z nich nie jest zero-day. Zero-day to luka wykorzystywana, zanim istnieje poprawka. Adobe wydało swoją w lipcu 2026 roku, ponad trzy miesiące przed tym wpisem. Poprawki dla Brotli pojawiły się około sześciu dni przed działaniem CISA. To znane, załatane podatności wykorzystywane przeciwko organizacjom, które nie zainstalowały aktualizacji.
To nie jest problem mniejszy. To problem innego rodzaju i wymaga innego rozwiązania.
Co się wydarzyło
Luka w Brotli
Brotli to format i biblioteka kompresji opracowane przez Google, służące do zmniejszania ruchu sieciowego. Jest wszędzie: w przeglądarkach, serwerach WWW, sieciach CDN, środowiskach uruchomieniowych języków programowania i w niezliczonych aplikacjach, które nigdy nie wspominają o niej z nazwy.
Wpis w katalogu CISA opisuje, co zyskuje napastnik: możliwość „uszkodzenia sąsiadującej pamięci stanu dekodera, ujawnienia wrażliwej zawartości pamięci, wywołania odmowy usługi", a potencjalnie również wykonania dowolnego kodu, przy użyciu spreparowanego strumienia skompresowanego formatem Brotli.
Klasa techniczna to niesprawdzona wartość zwracana prowadząca do zapisu poza zakresem w dekoderze. Napastnik działa zdalnie i bez uwierzytelnienia. Danymi wejściowymi są po prostu skompresowane dane, które oprogramowanie ofiary dekompresuje.
Podatne wersje: Brotli od 1.0.3 do 1.2.0. Wersje poprawione: 1.0.10, 1.1.1 i 1.2.1.
Luka nosiła początkowo nazwę Node2Shell, bo ujawniła się za pośrednictwem Node.js. Od początku tamtego tygodnia wiadomo, że dotyczy wszystkiego, co używa bibliotek Brotli do dekodowania tego formatu, a nie tylko Node.js, i stąd wzięła się druga nazwa.
Projekty i dostawcy niższego szczebla wydali własne aktualizacje, w tym Node.js, PHP, Bun i Microsoft .NET, przy czym Microsoft opublikował awaryjną aktualizację bezpieczeństwa dla .NET. Red Hat wydał biuletyn RHSB-2026-015.
Badania Wiz wskazują, że problem dotyczy 91 procent środowisk chmurowych, co daje wyobrażenie o tym, jak szeroko ta biblioteka jest osadzona.
Luka w Adobe Commerce
CVE-2026-48356 to nieograniczone przesyłanie pliku niebezpiecznego typu w Adobe Commerce i Magento Open Source. Nieuwierzytelniony napastnik może przesłać plik i doprowadzić do wykonania kodu w kontekście bieżącego konta użytkownika, a następnie potencjalnie rozszerzyć dostęp.
Podatne wydania obejmują Adobe Commerce 2.4.9, 2.4.8-p5 i wcześniejsze wspierane wersje oraz Magento Open Source 2.4.9 i wcześniejsze. Adobe naprawiło błąd w lipcu 2026 roku w biuletynie APSB26-73.
Oceny istotności podawane dla tej luki różnią się między źródłami, pojawiają się zarówno 9,3, jak i 9,6. Tak czy inaczej jest krytyczna.
Firma Sansec przeanalizowała kampanię wykorzystującą tę klasę ataku i podaje, że stojąca za nią grupa skompromitowała co najmniej 953 sklepy od lipca 2025 roku, w większości działające na Magento, a do przesyłania webshelli wykorzystywała właśnie lukę PolyShell.
Czego CISA nie podała
W obu wpisach CISA nie podała żadnych szczegółów o atakach: kto je prowadzi, które produkty są celem, kiedy aktywność się zaczęła ani jak jest rozległa. Wykorzystanie przez ransomware oznaczono w obu przypadkach jako nieznane.
Ta powściągliwość jest dla wpisów KEV normą i jednocześnie problemem praktycznym, bo pozostawia obrońców bez wskaźników, których mogliby szukać.
Dlaczego luka w Brotli jest trudniejsza niż wygląda
To fragment zasługujący na największą uwagę i nie chodzi w nim o istotność.
Prawdopodobnie nie możesz załatać Brotli bezpośrednio. To biblioteka osadzona wewnątrz innych rzeczy. Twoja ekspozycja znajduje się w środowisku uruchomieniowym Node.js, w instalacji PHP, w aplikacjach .NET, w obrazach bazowych kontenerów, w urządzeniach sieciowych i w komercyjnym oprogramowaniu, którego dostawca w ogóle nie poinformował Cię, czy używa Brotli.
Praktyczna konsekwencja: poprawka zwykle należy do kogoś innego. Czekasz na aktualizację środowiska uruchomieniowego, przebudowę obrazu bazowego albo komunikat dostawcy. Twoim zadaniem jest ustalić, na co konkretnie czekasz w przypadku każdego systemu, a to właśnie ta praca jest wąskim gardłem, a nie samo wgranie poprawki.
Inwentarze oprogramowania pomogą mniej, niż byś chciał. Brotli nie pojawi się w większości spisów zasobów, bo nikt nie zainstalował jej świadomie. Trafiła tam jako zależność zależności.
Istnieje użyteczny środek przejściowy. Do czasu aktualizacji można blokować przychodzące żądania skompresowane formatem Brotli na serwerze proxy lub zaporze albo wyłączyć dekodowanie Brotli. Kosztuje to wydajność i może zepsuć działanie części klientów, ale usuwa ścieżkę ataku. Dla systemów wystawionych do internetu, gdzie łatanie zajmie kilka dni, warto to rozważyć.
Dlaczego to ma znaczenie
„Wykorzystywane" i „zero-day" to nie to samo, a różnica wyznacza Twoją reakcję. Zero-day oznacza czekanie na dostawcę. Wykorzystywana znana luka oznacza, że poprawka już istnieje, a zamknięcie luki czasowej należy do Ciebie. Poprawka Adobe jest dostępna od lipca. Organizacje kompromitowane przez ten błąd miały ponad trzy miesiące.
Wpis do KEV to sygnał zmieniający priorytet. Sama krytyczna ocena CVSS nie jest dowodem, że ktoś Cię atakuje. Wpis w KEV jest. Dla amerykańskich agencji federalnych dyrektywa BOD 22-01 czyni termin 10 listopada wiążącym. Dla wszystkich pozostałych powinien działać jako wyzwalacz eskalacji, bo oznacza, że teoretyczne stało się rzeczywiste.
Sklepy Magento są stałym celem. Liczba co najmniej 953 skompromitowanych sklepów podana przez Sansec pokazuje, że to kampania zindustrializowana, a nie okazjonalne sondowanie. Platformy e-commerce obsługują płatności i dane klientów, a webshelle podłożone miesiące temu mogą nadal działać w sklepach, które zostały już załatane.
Załatanie Magento nie kończy pracy. Jeśli Twój sklep był niezałatany między lipcem a dniem dzisiejszym, możesz już mieć webshell albo wstrzyknięte bloki CMS. Aktualizacja zamyka drzwi i nic nie robi z kimś, kto jest już w środku.
Prawdziwą lekcją jest głębokość zależności. Biblioteka kompresji, której większość zespołów nigdy świadomie nie wybrała, jest dziś ryzykiem zdalnego wykonania kodu w 91 procentach środowisk chmurowych. Tak wyglądają współczesne łańcuchy dostaw oprogramowania.
Kogo to dotyczy
Każdego systemu z Brotli w wersjach od 1.0.3 do 1.2.0, bezpośrednio lub w postaci osadzonej.
Środowisk Node.js, PHP, Bun i .NET, dla których wydano aktualizacje.
Środowisk chmurowych w ogóle, gdzie Wiz szacuje odsetek dotkniętych na 91 procent.
Obrazów kontenerów i osadzonych środowisk uruchomieniowych, gdzie biblioteka jest najmniej widoczna.
Sklepów Adobe Commerce i Magento Open Source w wersjach 2.4.9, 2.4.8-p5 lub wcześniejszych, które pominęły lipcowe aktualizacje 2026 roku.
Amerykańskich cywilnych agencji federalnych, objętych wiążącym terminem 10 listopada dla obu luk.
Każdego korzystającego z komercyjnych urządzeń lub oprogramowania dostawców, kto może jeszcze nie wiedzieć, czy Brotli jest w środku.
Co powinny zrobić organizacje
Dla Brotli, po kolei
Ustal, gdzie znajduje się Brotli. Zacznij od środowisk uruchomieniowych: Node.js, PHP, Bun, .NET. Potem obrazy bazowe kontenerów, następnie urządzenia i oprogramowanie komercyjne. To właśnie ten etap jest całą pracą.
Zainstaluj aktualizacje wydane przez dostawców, w tym awaryjną aktualizację .NET oraz wytyczne Red Hata z biuletynu RHSB-2026-015.
Jeśli kompilujesz lub dołączasz Brotli samodzielnie, przejdź na wersję 1.0.10, 1.1.1 lub 1.2.1, zależnie od używanej gałęzi.
Tam, gdzie łatanie zajmie kilka dni, blokuj żądania skompresowane Brotli na proxy lub zaporze albo wyłącz dekodowanie Brotli. Traktuj to jako rozwiązanie tymczasowe i pogódź się z kosztem wydajnościowym.
Zapytaj dostawców wprost, czy ich produkty zawierają Brotli, i zapisz odpowiedzi. Większość nie poinformuje Cię z własnej inicjatywy.
Przebuduj obrazy kontenerów zamiast łatać działające kontenery, żeby poprawka przetrwała kolejne wdrożenie.
Dla Adobe Commerce i Magento
Potwierdź, że działasz na wydaniu zawierającym lipcowe poprawki 2026 roku (APSB26-73). Jeśli nie, to od teraz priorytet wyższy niż wszystko inne na Twojej liście.
Po załataniu poszukaj tego, co może już tam być. Sprawdź webshelle, nieoczekiwane pliki w katalogach przesyłania, wstrzyknięte bloki CMS, nieznane konta administracyjne i zmodyfikowane szablony.
Przejrzyj dostępy i przepływy płatnicze, bo ta klasa kompromitacji celuje w jedno i drugie.
Sprawdź, po czyjej stronie leży łatanie u Twojego dostawcy hostingu. W usłudze zarządzanej Magento aktualizacja może należeć do niego, a to wymaga potwierdzenia, a nie założenia.
Proces
Wepnij katalog KEV w priorytetyzację jako automatyczną eskalację, a nie listę, do której ktoś czasem zagląda. Jego celem jest powiedzenie Ci, co jest faktycznie atakowane.
Traktuj „poprawka należy do kogoś innego" jako stan monitorowany, a nie ślepy zaułek. Zapisz, na którego dostawcę czekasz, przypominaj mu i w międzyczasie wdróż środki kompensujące.
Pamiętaj, że CISA nie opublikowała żadnych wskaźników, więc wykrywanie opiera się tu na Twoim własnym poszukiwaniu, a nie na gotowej liście.
Podsumowanie
Dwie krytyczne luki, obie pod aktywnym atakiem, żadna nowa. Adobe naprawiło jedną w lipcu. Projekt Brotli i jego dostawcy naprawili drugą tydzień przed wpisem CISA. Eksploatacja zachodzi w przerwie między istnieniem poprawki a jej zainstalowaniem, a to właśnie tam mieszka większość rzeczywistych kompromitacji.
Lekcja: w przypadku bibliotek osadzonych trudne nie jest łatanie, tylko ustalenie, gdzie ta rzecz w ogóle jest. Brotli znajduje się według Wiz w 91 procentach środowisk chmurowych, a prawie nikt nie zdecydował o jej umieszczeniu tam. Przyszła wewnątrz środowiska uruchomieniowego, wewnątrz obrazu, wewnątrz produktu dostawcy. Nie da się załatać czegoś, czego nie potrafisz zlokalizować, a praca wyszukiwawcza następująca po takim ujawnieniu jest wolniejsza i mniej efektowna niż sama poprawka.
Druga lekcja jest dla każdego, kto prowadzi sklep na Magento. Lipcowa poprawka zatrzymuje nowe włamania. Nie robi nic z webshellem, który siedzi na Twoim serwerze od sierpnia. Łatanie i reagowanie na incydent to dwie osobne prace, a pominięcie drugiej dlatego, że wykonało się pierwszą, to sposób, w jaki organizacje kończą skompromitowane przez podatność, którą uważają za usuniętą.
Dwie rzeczy warte zrobienia dziś: spisz każde środowisko uruchomieniowe i każdy obraz kontenera w swojej infrastrukturze zawierający Brotli oraz potwierdź dokładne wydanie Adobe Commerce, na którym działa Twój sklep.
