CVE-2026-0770 w Langflow na liście CISA: co wpis w katalogu KEV oznacza dla firmy

21 lipca 2026 roku amerykańska agencja cyberbezpieczeństwa CISA dodała podatność CVE-2026-0770 do katalogu Known Exploited Vulnerabilities (KEV), czyli wykazu luk znanych z wykorzystania w atakach. Wpis dotyczy oprogramowania Langflow. Tego samego dnia do katalogu trafiły jeszcze trzy inne podatności, między innymi luka w DD-WRT oraz dwie w WordPressie.

Z tego tekstu dowiesz się, na czym polega ten typ błędu i dlaczego sama obecność w katalogu KEV podnosi priorytet naprawy. Opisana jest też dyrektywa BOD 26-04, która porządkuje kolejność działań, oraz lista kroków i pytań kontrolnych dla zespołu IT.

Fakty o wpisie CVE-2026-0770

Dwie pozycje z tabeli wymagają doprecyzowania. Materiały odniesienia to miejsca, od których zespół techniczny powinien zacząć weryfikację: wpis wskazuje konkretne wydanie Langflow v1.9.0 w serwisie GitHub oraz kartę podatności w publicznej bazie NVD. Wymagane działanie oznacza z kolei, że obok samej naprawy trzeba spełnić dodatkowe warunki opisane w dyrektywie i w wymogach przeglądu śledczego.

Na czym polega ta podatność

Nazwa wpisu opisuje klasę błędu. Program przyjmuje i wykonuje funkcjonalność pochodzącą ze źródła, którego nie kontroluje. Inaczej mówiąc, w aplikacji istnieje mechanizm pozwalający dostarczyć jej polecenia z zewnątrz, a pochodzenie tych poleceń nie jest wystarczająco sprawdzane.

Dobra analogia to sekretariat, który wykonuje każde polecenie znalezione we wspólnej skrzynce na dokumenty, bez weryfikacji nadawcy. Oficjalnie polecenia powinny pochodzić od zarządu, w praktyce do skrzynki może wrzucić kartkę każdy, kto do niej dotrze. Jeśli nikt nie kontroluje pochodzenia kartki, obca osoba każe firmie wykonać własne instrukcje, firmowymi rękami i na firmowy koszt.

W przypadku oprogramowania skutek jest podobny. Atakujący, który potrafi dostarczyć własną funkcjonalność do podatnego mechanizmu, sprawia, że aplikacja wykonuje jego instrukcje z uprawnieniami nadanymi jej przez firmę. Dla właściciela oznacza to ryzyko utraty kontroli nad danymi przetwarzanymi przez aplikację oraz nad systemem, na którym działa.

Co zmienia obecność w katalogu KEV

Katalog KEV nie jest listą wszystkich znanych błędów. Jak informuje CISA, do wpisu kwalifikuje się wyłącznie podatność z identyfikatorem CVE, udokumentowanym dowodem wykorzystania i jasną wskazówką naprawczą. Każdy z tych warunków ma praktyczne znaczenie: błąd jest jednoznacznie nazwany, ataki nie są hipotezą, a droga naprawy istnieje.

Obecność CVE-2026-0770 w katalogu oznacza więc, że wykorzystanie tej luki jest faktem, a nie scenariuszem teoretycznym. To przesądza o priorytecie: naprawa nie czeka na okresowe okno aktualizacji.

Warto też wiedzieć, czego wpis nie rozstrzyga. Według katalogu KEV ta podatność nie jest oznaczona jako wykorzystywana w kampaniach ransomware. Brak takiego oznaczenia nie jest powodem do obniżenia priorytetu, mówi jedynie, że wpis nie wiąże luki z tego typu kampaniami.

Dyrektywa BOD 26-04 i kolejność napraw

Z wpisem w katalogu KEV wiąże się dyrektywa CISA BOD 26-04, zatytułowana Prioritizing Security Updates Based on Risk. Formalnie dotyczy ona agencji federalnych Stanów Zjednoczonych, ale opisany w niej schemat to gotowy model ustalania priorytetów, przydatny także w firmie prywatnej.

Według dyrektywy termin naprawy zależy od czterech zmiennych: ekspozycji zasobu, obecności podatności w katalogu KEV, możliwości zautomatyzowania ataku oraz skutku technicznego wykorzystania luki. Zgodnie z tą dyrektywą najszybszej reakcji wymagają podatności z katalogu KEV w zasobach publicznie dostępnych, których wykorzystanie daje atakującemu pełną kontrolę nad zasobem. Sprawy mniej ryzykowne wolno odsunąć w czasie.

Tomasz Kaczmarek

Mogę Ci jakoś pomóc?

Umów spotkanie +48 888 777 822

lub

biuro@uxu.pl

Według wytycznych wdrożeniowych do dyrektywy, po dodaniu podatności do katalogu agencja ustala, czy sprawa mieści się w progu naprawy krótszym niż trzy dni, oraz czy wymagany jest przegląd śledczy (ang. Forensics Triage Requirements), czyli sprawdzenie, czy przed naprawą nie doszło już do kompromitacji systemów. Według tych samych wytycznych CISA nie wydaje odstępstw ani wyjątków od działań wymaganych dyrektywą, a trudności wdrożeniowe agencja zgłasza pocztą elektroniczną do zespołu odpowiedzialnego za dyrektywy.

Dla firmy spoza administracji USA liczy się logika modelu, nie formalny obowiązek. System wystawiony do internetu, podatność z potwierdzonym wykorzystaniem i skutek w postaci przejęcia kontroli to połączenie, które w tym schemacie ląduje na samej górze listy napraw.

Działania po stronie firmy

Poniższa tabela zbiera kroki wynikające wprost z wpisu w katalogu KEV oraz z logiki dyrektywy BOD 26-04.

Przegląd śledczy to odpowiedź na pytanie, czy ktoś zdążył wykorzystać lukę, zanim została zamknięta. Sama naprawa zamyka drzwi, ale nie mówi, czy ktoś przez nie już wszedł. Dlatego wpis w katalogu KEV przywołuje wymogi przeglądu obok samej naprawy, a nie zamiast niej.

Pytania kontrolne dla zespołu IT

Zarząd nie potrzebuje wiedzy technicznej, żeby skontrolować wykonanie prac. Wystarczy zestaw pytań z jednoznaczną formą odpowiedzi.

Podsumowanie jest krótkie. Podatność CVE-2026-0770 w oprogramowaniu Langflow ma potwierdzone wykorzystanie, skoro trafiła do katalogu KEV, a wpis wskazuje, gdzie szukać instrukcji producenta. Kolejność działań narzuca logika dyrektywy BOD 26-04: najpierw systemy dostępne z zewnątrz, naprawa zgodna z instrukcją producenta, a po niej sprawdzenie, czy atak nie wydarzył się przed łatką.

• ransomware
• zgodność
• sieci
• licencje
• cyberbezpieczeństwo

Paweł Niedźwiecki

Mogę Ci jakoś pomóc?

Umów spotkanie +48 888 777 822 lub biuro@uxu.pl

Udostępnij

Twitter LinkedIn Facebook Kopiuj link