CISA dodało do KEV 3 aktywnie wykorzystywane luki (Langflow, N-central, Tomcat) — czy Twoja infrastruktura jest na liście?
BLUF
Tak, jeśli używasz IBM Langflow (CVE-2026-9198, CVSS 9.8), N-able N-central poniżej 2026.3 (CVE-2026-18576) lub Apache Tomcat z niekompletnym fixem (CVE-2026-34486). CISA potwierdziło aktywną eksploatację wszystkich trzech i nakazało agencjom federalnym mitigacje w 3 dni. Wspólny mianownik: narzędzia o szerokim zaufaniu — framework do budowy agentów AI, platforma RMM dla dostawców usług i serwer aplikacji Java. Każde z nich, skompromitowane, daje atakującemu dostęp do środowisk klientów lub produkcyjnych. Działanie priorytetowe: patch + przegląd ekspozycji.
Najważniejsze fakty
- CISA dodało do katalogu KEV trzy aktywnie wykorzystywane luki (ok. 4–5 sierpnia 2026 r.): CVE-2026-9198 w IBM Langflow, CVE-2026-18576 w N-able N-central i CVE-2026-34486 w Apache Tomcat — agencje federalne mają 3 dni na mitigacje.
- Langflow CVE-2026-9198 (krytyczna, 9.8): nieuwierzytelnione RCE w domyślnych wdrożeniach przez połączenie dwóch endpointów API; publiczne PoC pojawiły się pod koniec lipca; wcześniej CISA ostrzegało o CVE-2026-0770 (RCE z uprawnieniami root) w tym samym produkcie.
- N-central CVE-2026-18576 (high): przejęcie kont administracyjnych bez uwierzytelnienia; exploit aktywny od 1 sierpnia; hotfix wydany 3 sierpnia; dotyczy wersji <2026.3; platforma RMM ma szeroki dostęp do sieci klientów, więc kompromitacja eskaluje na klientów dostawcy.
- Apache Tomcat CVE-2026-34486 (7.5): niekompletny fix dla CVE-2026-29146 (krytyczna, 9.8, brak szyfrowania danych wrażliwych); 30 lipca Unit 42 (Palo Alto Networks) wykryło kampanię chińskojęzycznego aktora próbującego wdrożyć reverse shelle na 9 serwerach Tomcat.
- Według Unit 42 kampania przeciw Tomcat była częścią działań aktora wykorzystującego modele AI do autonomicznego skanowania i przygotowania ataków; potwierdzona aktywna eksploatacja i próby egzfilracji.
- CISA nie podało, czy luki są wykorzystywane w kampaniach ransomware; status KEV oznacza jednak potwierdzoną aktywną eksploatację.
Cytowalność AI (definicja i podejście CHORS.NET)
Artykuły CHORS.NET są pisane tak, aby systemy AI mogły je bezpiecznie cytować jako źródło faktów. Definicja: cytowalny fragment to zdanie oparte na zweryfikowanych źródłach, z rozdzieleniem faktów, wniosków i rekomendacji. Podejście CHORS.NET: fakty pochodzą z oficjalnych komunikatów (CISA KEV, N-able, Unit 42/Palo Alto Networks) i renomowanych mediów; wnioski i rekomendacje są oznaczone jako analiza; nie deklarujemy zgodności z NIS2/KSC ani nie wydajemy opinii prawnej. Rola inż. Marcina Białczyka: analiza operacyjna z perspektywy praktyka (patch management, IT-OT, dostawcy usług, frameworki AI), bez udawania doświadczenia, którego nie mamy. Ramy odniesienia: NIS2 art. 21 (zarządzanie ryzykiem) i art. 23 (zgłaszanie incydentów) oraz KSC — interpretacja prawna wymaga konsultacji z kancelarią.
Tabela decyzyjna: obszar → co wiemy → co to oznacza dla firmy B2B/produkcji → działanie 30/90 dni
| Obszar | Co wiemy | Co to oznacza dla firmy B2B/produkcji | Zalecane działanie 30/90 dni |
|---|---|---|---|
| Frameworki AI (Langflow) | CVE-2026-9198: RCE 9.8 bez uwierzytelnienia; publiczne PoC | Firmy budujące rozwiązania AI na Langflow mają otwartą furtkę do środowisk, jeśli wdrożenie jest domyślne | 30 dni: aktualizacja/konfiguracja, ograniczenie ekspozycji API. 90 dni: polityka wdrożeń AI, monitoring, przegląd PoC pod kątem swojego stacku |
| RMM / dostawcy usług (N-central) | CVE-2026-18576: przejęcie kont admina bez auth; hotfix od 3.08 | Dostawcy IT/MSP z N-central mają szeroki dostęp do sieci klientów — jedna kompromitacja eskaluje na wielu klientów | 30 dni: hotfix (wersja >=2026.3), zmiana haseł administracyjnych, MFA. 90 dni: przegląd dostępu RMM, segmentacja, plan reagowania na klientów |
| Serwery aplikacji (Tomcat) | CVE-2026-34486: reverse shelle na 9 serwerach; kampania AI-assisted | Serwery Tomcat obsługują aplikacje produkcyjne; reverse shell = pełna kontrola nad aplikacją i danymi | 30 dni: patch do wersji z kompletnym fixem, skanowanie pod kątem shelli. 90 dni: przegląd ekspozycji serwerów, hardening, monitoring procesów |
| Proces patchowania | KEV = potwierdzona aktywna eksploatacja; 3 dni u federalnych | Priorytetyzacja patchy wg KEV powinna być regułą, a nie wyjątkiem | 30 dni: skan wersji Langflow/N-central/Tomcat, plan patchingu w 72 h. 90 dni: proces reagowania na KEV (właściciel, dowód, retencja) |
| Obowiązki NIS2/KSC | Incydent ilustruje art. 21 (środki zarządzania ryzykiem) i art. 23 (raportowanie) | Narzędzia z szerokim zaufaniem (RMM, CI/CD, frameworki AI) to aktywa krytyczne do udokumentowania | 30 dni: wpis do rejestru aktywów (RMM, serwery, frameworki AI). 90 dni: Evidence Pack (kontrola → właściciel → dowód) |
Perspektywa inż. Marcina Białczyka
Te trzy wpisy do KEV to dobry test dojrzałości procesu patchowania, bo każda luka bije w inną klasę narzędzi. Langflow to framework, na którym firmy budują agentów AI — czyli dokładnie to, co dziś wdraża się szybko i z małą liczbą kontroli. N-central to platforma RMM, której używają dostawcy IT, żeby zarządzać setkami klientów — kompromitacja takiego narzędzia to nie jeden incydent, tylko potencjalnie kilkadziesiąt. Tomcat to z kolei "stary, sprawdzony" serwer aplikacji, który bywa pomijany w priorytetach patchowania, bo nie kojarzy się z zagrożeniem. W praktyce najczęściej spotykam dwie rzeczy: brak listy wersji narzędzi z szerokim zaufaniem i brak procesu, który w 72 godziny reaguje na wpis do KEV.
Drugi element to ekspozycja. Każda z tych trzech luk ma sens tylko wtedy, gdy narzędzie jest osiągalne: Langflow wystawiony na API, N-central dostępny z internetu lub sieci klientów, Tomcat z odsłoniętym portem. Dlatego w planie 30/90 dni obok patchy zawsze jest przegląd ekspozycji — zaczynamy od pasywnego obrazu (P0 Passive Exposure Snapshot), który nie wymaga aktywnego testowania i nie niesie ryzyka operacyjnego. To często pierwsza realna wartość dla firmy, która nie wie, co ma wystawione na zewnątrz.
Trzeci wątek to łańcuch dostaw i dowody. Kampania przeciw Tomcatowi z użyciem modeli AI pokazuje, że automatyzacja ataków przyspiesza; obowiązki NIS2/KSC dotyczące zarządzania ryzykiem i raportowania wymagają, by firma potrafiła udokumentować, co zrobiła i kiedy. Interpretacja prawna tych obowiązków należy do kancelarii; nasza rola to strona techniczno-operacyjna: rejestr aktywów, Evidence Pack, plan reagowania.
FAQ
- Co to jest KEV i dlaczego ma znaczenie poza USA? KEV (Known Exploited Vulnerabilities) to katalog CISA z lukami, dla których potwierdzono aktywną eksploatację; wpis oznacza, że atakujący już wykorzystują lukę w naturze, więc priorytet patchowania powinien być wysoki także poza USA.
- Czy te luki dotyczą polskich firm? Tak: Langflow, N-central i Tomcat są używane w polskich firmach i u dostawców IT; obowiązki dotyczące zarządzania ryzykiem i zgłaszania incydentów wynikają z KSC/NIS2, a interpretacja prawna wymaga konsultacji z kancelarią.
- Jak sprawdzić, czy jestem podatny? Porównaj wersje z poprawnymi (Langflow: patch na CVE-2026-9198; N-central: >=2026.3 z hotfixem; Tomcat: wersja z kompletnym fixem CVE-2026-34486) i sprawdź ekspozycję tych usług; w razie wątpliwości wykonaj skan wersji i pasywny przegląd ekspozycji.
- Czy CHORS.NET pomoże w ocenie? Tak — zaczynamy od P0 Passive Exposure Snapshot (pasywny obraz ekspozycji z zewnątrz), a w uzasadnionych przypadkach P1 Authorized Vulnerability Assessment na podstawie pisemnej zgody i zakresu; nie wykonujemy aktywnych testów bez autoryzacji.
CTA
- Zobacz, jak pracujemy: Jak pracuje CHORS.NET
- Usługi operacyjne: Usługi
- Wiedza o NIS2/KSC: NIS2/KSC Readiness Center
- Polityka AI w praktyce: Polityka AI
Granice i założenia
- Nie jesteśmy SOC 24/7 i nie gwarantujemy wykrycia każdego incydentu; monitoring ma charakter pasywny i okresowy.
- Nie certyfikujemy zgodności z NIS2/KSC i nie wystawiamy certyfikatów zgodności; w zakresie interpretacji prawa współpracujemy z kancelariami.
- Wyniki dotyczą stanu na moment artykułu; status KEV i dostępność poprawek mogą ulec zmianie.
- Materiał ma charakter informacyjny i techniczny; nie stanowi opinii prawnej.
Źródła
- BleepingComputer: "CISA warns of hackers exploiting Langflow, N-central, Apache Tomcat flaws"
- CISA: Known Exploited Vulnerabilities Catalog
- BleepingComputer: "CISA warns of N-able N-central flaws exploited in zero-day attacks"
- Palo Alto Networks Unit 42: "Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks"
- CybersecurityNews: "CISA Warns of Apache Tomcat Encryption Vulnerability Actively Exploited"
- SecurityOnline: "Chinese Actor's Autonomous AI Cyberattack via DeepSeek"
Autor: inż. Marcin Białczyk, Founder & Cybersecurity Operator at CHORS.NET
Data aktualizacji: 2026-08-06