Kwiecień 2026: miesiąc w którym infrastruktura AI stała się linią frontu
Raport z trzydziestu historii, które czytane razem opisują jedną rzecz.
Zacznij od tej liczby: 87%
Proofpoint opublikował 28 kwietnia wyniki badania 1400 specjalistów ds. bezpieczeństwa z 12 krajów. Wynik: 87% organizacji wdrożyło asystentów AI poza fazą pilotażu. 76% aktywnie wdraża autonomiczne agenty. Ponad połowa opisuje swoje podejście do bezpieczeństwa AI jako "nadrabiające zaległości, niespójne lub reaktywne." 42% zgłosiło podejrzany lub potwierdzony incydent bezpieczeństwa związany z AI.
Te liczby są tłem dla wszystkiego co cyberflux opisywał w tym miesiącu. Organizacje wdrażają infrastrukturę AI w tempie znacznie szybszym niż budują mechanizmy jej ochrony. Kwiecień 2026 pokazał co z tego wynika w praktyce.
Dwa okna, dwa różne problemy
Zanim przejdziemy do wzorców, warto zatrzymać się przy danych liczbowych z tego miesiąca — bo opisują coś nieoczywistego.
Okna między ujawnieniem podatności a pierwszą eksploitacją: Marimo CVE-2026-39987 — 9 godzin 41 minut. LMDeploy CVE-2026-33626 — 12 godzin 31 minut. LiteLLM CVE-2026-42208 — 36 godzin. Flowise CVE-2025-59528 — sześć miesięcy.
To nie jest przypadkowy rozrzut. To są dwa różne rodzaje awarii wymagające dwóch różnych odpowiedzi.
Krótkie okna — Marimo, LMDeploy, LiteLLM — to podatności trywialne w eksploitacji: brak uwierzytelnienia, SQL injection, SSRF. Sam opis techniczny wystarczy do zbudowania ataku. Żaden proces zarządzania podatnościami nie jest wystarczająco szybki żeby zamknąć okno między ogłoszeniem a atakiem gdy to okno mierzy się w godzinach. Jedyną obroną jest redukcja powierzchni ataku przed ujawnieniem: izolacja sieciowa, minimalne uprawnienia, brak publicznej ekspozycji instancji których nie musi być widać z internetu.
Długie okno — Flowise — to zupełnie inny problem. Łatka była dostępna pół roku. Organizacje jej nie zastosowały nie dlatego że nie miały czasu. Zastosowały ją zbyt wolno dlatego że Flowise nie był w ich rejestrze aktywów wymagających aktywnego zarządzania bezpieczeństwem. Narzędzie "deweloperskie" z dostępem do kluczy produkcyjnych — klasyczna luka między percepcją a rzeczywistością.
Zestawienie tych dwóch przypadków opisało problem pełniej niż każdy z osobna: nie ma jednego "okna łatania" — są dwa różne problemy którym nadajemy tę samą nazwę i które wymagają różnych rozwiązań.
Infrastruktura AI jako nowa warstwa bez ochrony
Przez kwiecień cyberflux opisał cztery frameworki AI zaatakowane w jednym miesiącu: Marimo, SGLang, LMDeploy, LiteLLM. Do tego Flowise z aktywną eksploitacją po sześciu miesiącach od dostępnej poprawki. Pięć różnych systemów, pięć różnych klas podatności: brak uwierzytelnienia, wstrzyknięcie szablonu przez plik modelu, SSRF, SQL injection, nieaplikowane poprawki.
Dla porównania: w marcu 2026 cyberflux nie opisał ani jednego incydentu dotyczącego frameworku AI jako bezpośredniego celu ataku. Cyberflux jest selektywny — opisujemy to co uznajemy za istotne, nie wszystko co się wydarza. Ale jeśli filtr był ten sam w obu miesiącach, a wynik jest ośmiokrotnie wyższy w kwietniu, to różnica jest realna.
Co te podatności mają wspólnego? Nie klasa błędu. Środowisko w którym się pojawiają i co to środowisko ma dostęp.
Każdy z tych frameworków siedzi w centrum infrastruktury AI organizacji. Marimo i SGLang na stacjach roboczych z kluczami AWS i tokenami API. LMDeploy na węzłach GPU w chmurze z uprawnieniami IAM do repozytoriów modeli i zbiorów danych. LiteLLM jako centralna bramka z kluczami do każdego dostawcy modeli — OpenAI, Anthropic, AWS Bedrock, Azure. Flowise z tokenami do baz danych i zewnętrznych API.
Microsoft Security Blog podsumował to na RSAC 2026 jednym zdaniem: "Ekosystem agentów stanie się najbardziej atakowaną powierzchnią w przedsiębiorstwie." Kwiecień jest pierwszym miesiącem w którym to zdanie można poprzeć konkretną listą incydentów zamiast prognozą.
IBM X-Force w raporcie za 2026 rok odnotował wzrost eksploitacji publicznych aplikacji o 44% rok do roku, z wyraźnym sygnałem że wzrost jest napędzany przez ataki na ekosystemy deweloperskie i zaufaną infrastrukturę. To co cyberflux opisywał przypadek po przypadku — IBM widzi jako trend w danych.
Ale jest jeden szczegół który odróżnia ataki na infrastrukturę AI od klasycznych ataków na aplikacje webowe: skala potencjalnego dostępu po kompromitacji. Podatność w aplikacji webowej daje dostęp do danych tej aplikacji. Podatność w bramce AI daje dostęp do kluczy do wszystkich systemów z którymi bramka się komunikuje. Jeden exploit w LiteLLM to potencjalnie klucze do OpenAI, Anthropic, AWS i Azure jednocześnie.
Stare klasy błędów, nowe miejsce — ale inaczej niż myślisz
"Stare błędy w nowych miejscach" to teza która jest zarówno prawdziwa jak i myląca jeśli czytać ją pobieżnie.
Tak, SQL injection w LiteLLM to ta sama klasa błędu co SQL injection z 2004 roku. Tak, SSRF w LMDeploy to znana klasa podatności. Tak, brak uwierzytelnienia w interfejsie zarządzania to podstawowy błąd projektowy znany od dekad.
Ale jest jedna istotna różnica: stare klasy błędów w aplikacjach webowych dawały dostęp do danych tej konkretnej aplikacji. Te same klasy błędów w infrastrukturze AI dają dostęp do całego stosu zintegrowanych systemów. Blast radius jest proporcjonalnie większy — nie dlatego że błąd jest gorszy, ale dlatego że to co jest za nim jest inne.
Maintainer LiteLLM naprawił CVE-2026-42208 dwiema liniami kodu — zastąpił interpolację łańcuchową zapytaniem parametryzowanym. To jest naprawa którą każdy junior deweloper może zaimplementować w pięć minut. Te dwie linie zostały przeoczone w ścieżce weryfikacji klucza API — czyli w najbardziej krytycznym miejscu całego systemu uwierzytelnienia — ponieważ LiteLLM rośnie szybko i nie ma formalnych przeglądów bezpieczeństwa kodu przed mergem.
45 000 gwiazdek na GitHubie, produkcyjne wdrożenia zarządzające miesięcznymi wydatkami rzędu dziesiątek tysięcy dolarów, i brak procesu który by wyłapał SQL injection w ścieżce uwierzytelnienia przez rok od napisania kodu. To nie jest problem konkretnego dewelopera — to jest model rozwoju oprogramowania AI który optymalizuje pod kątem tempa funkcjonalności kosztem dojrzałości bezpieczeństwa.
Autonomia jako mnożnik skali
Jednym z ważniejszych konceptualnych przełomów które kwiecień przyniósł jest precyzyjne opisanie dlaczego autonomia agentów AI zmienia kalkulację ryzyka.
CVE-2026-26268 w Cursor najlepiej to ilustruje. Git hooks istnieją od początku Git. Mechanizm bare repository zagnieżdżonego w innym repozytorium jest udokumentowany. Kombinacja tych dwóch nie była podatnością — dopóki agent AI nie zaczął autonomicznie wykonywać operacji Git jako efekt uboczny realizacji wysokopoziomowych poleceń użytkownika.
Assaf Levkovich z Novee Security opisuje zmianę modelu precyzyjnie: tradycyjny deweloper wykonuje operacje Git świadomie — widzi co robi. Agent AI wykonuje te same operacje jako jeden z kroków realizacji zadania — użytkownik nie ma widoczności na poziomie poszczególnych akcji. Każda operacja którą agent może wykonać autonomicznie jest potencjalnym wektorem, jeśli dane wejściowe do agenta mogą być kontrolowane przez atakującego.
Comment and Control opisuje ten sam mechanizm z innej strony: Claude Code, Gemini CLI i GitHub Copilot wykonują polecenia z tytułów zgłoszeń i komentarzy na GitHubie bez żadnej interakcji operatora, bo automatyczne przepływy pracy uruchamiają się przy zdarzeniach pull_request i issues. Agent interpretuje złośliwą instrukcję jako część kontekstu zadania i wykonuje ją — bo tak został zaprojektowany żeby działać.
Autonomia jest tym co czyni narzędzia AI użytecznymi. Jest też tym co sprawia że każda niezaufana treść przetworzona przez agenta z dostępem do zasobów staje się potencjalnym wektorem ataku. Im więcej kroków agent może wykonać bez potwierdzenia człowieka, tym więcej kroków może wykonać za sprawą atakującego który kontroluje wejście.
AISI — Instytut Bezpieczeństwa AI rządu brytyjskiego — przeprowadził niezależną ocenę Mythos Preview i opublikował wyniki 13 kwietnia: na zadaniach CTF poziomu eksperckiego, których żaden model nie mógł wykonać przed kwietniem 2025 roku, Mythos Preview osiąga 73% skuteczności. Rok temu ta liczba wynosiła zero. Autonomia modeli AI w kontekście zadań ofensywnych rośnie szybciej niż cokolwiek w tym sektorze.
Łańcuch dostaw jako skoordynowana infrastruktura
Kwiecień 2026 przyniósł dowód że ataki na łańcuch dostaw dojrzały od oportunistycznych incydentów do skoordynowanych operacji.
TeamPCP i Checkmarx KICS to nie był odosobniony incydent. Był pierwszym ogniwem w udokumentowanym łańcuchu: skaner bezpieczeństwa jako wektor wejścia → skradziony token GitHub → robak propagujący się przez repozytoria → Shai-Hulud zatruwający narzędzia AI do kodowania na zainfekowanych maszynach. I osobno, przez partnerstwo ogłoszone publicznie na BreachForums: TeamPCP jako dostawca dostępu, VECT jako ładunek końcowy.
To jest model biznesowy: jedna grupa specjalizuje się w uzyskiwaniu dostępu przez kompromitację łańcucha dostaw narzędzi deweloperskich, inna w dostarczaniu ładunku końcowego. Podział pracy, specjalizacja, skalowanie. CrowdStrike w Global Threat Report 2026 odnotowuje że 82% detekcji złośliwego kodu to ataki "malware-free" — atakujący używają skradzionych poświadczeń i legalnych narzędzi. Kampania TeamPCP→VECT jest dokładną ilustracją tego trendu.
Vercel przez Context.ai i TeamPCP→VECT to ta sama klasa problemu z różnych stron. Vercel: zewnętrzne narzędzie AI z uprawnieniami OAuth jako most do infrastruktury firmy. TeamPCP: zewnętrzne narzędzie DevSecOps jako wektor wejścia do łańcucha zależności. W obu przypadkach atak trafił nie do systemu który organizacja chroni — trafił do czegoś z nim połączonego i traktowanego jako zaufane.
MCP: protokół który ma problem architektoniczny i go nie naprawia
Raport OX Security z połowy miesiąca postawił pytanie które cyberflux zadawał przez cały kwiecień opisując kolejne CVE w ekosystemie MCP: czy te incydenty są przypadkowym skupieniem błędów, czy objawem głębszego problemu?
Odpowiedź jest: głębszego. Interfejs STDIO — standardowy lokalny transport MCP — przyjmuje polecenia i wykonuje je jako podprocesy bez walidacji czy te polecenia są bezpieczne do wykonania. Działa to we wszystkich dziesięciu językach SDK. Każdy deweloper budujący na MCP dziedziczy tę ekspozycję automatycznie. OX zademonstrował cztery klasy ataków, zatrył dziewięć z jedenastu badanych katalogów serwerów, pokazał eksploitację na sześciu platformach produkcyjnych.
Anthropic odpowiedział że zachowanie jest "oczekiwane" i zaktualizował dokumentację zalecając "ostrożność." OX skomentował: "Ta zmiana niczego nie naprawiła."
To jest istotna różnica w stosunku do wszystkich innych incydentów w tym miesiącu. W przypadku Cursor, Gemini CLI, LiteLLM — błąd był w implementacji konkretnego narzędzia i dało się go naprawić poprawką. W przypadku MCP błąd jest w projekcie protokołu. Poprawka wymagałaby zmiany architektonicznej której Anthropic odmówił.
Microsoft Entra Agent ID Administrator to ta sama klasa problemu w innej warstwie: rola zarządzania tożsamościami agentów AI zbudowana na prymitywach Service Principal bez ścisłego ograniczenia zakresu, pozwalająca na przejęcie dowolnego Service Principala w tenancie. Microsoft naprawił konkretny błąd zakresu. Problem strukturalny — że nowe warstwy zarządzania AI dziedziczą podatności warstw na których są zbudowane — pozostaje.
Oba przypadki razem opisują coś ważnego: gdy budujesz nową warstwę infrastruktury AI na istniejących fundamentach, dziedziczysz nie tylko ich możliwości ale też ich klasy podatności. WordPress 7.0 adoptuje MCP — protokół z trzydziestoma CVE w sześćdziesięciu dniach trafia do platformy zasilającej 40% stron internetowych, przez ekosystem dziesiątek tysięcy wtyczek tworzonych przez deweloperów o różnym poziomie świadomości bezpieczeństwa. Każda nowa warstwa — protokół, rola katalogowa, framework, narzędzie — wnosi własne błędy projektowe i jednocześnie dziedziczy błędy wszystkiego co jest pod nią.
Odkrywanie podatności i paradoks który ujawnia
7 kwietnia Anthropic ogłosił Mythos Preview i Project Glasswing — model który potrafi autonomicznie znajdować i eksploitować zero-day w każdym głównym systemie operacyjnym, z wynikiem 181 działających exploitów w benchmarku gdzie Opus 4.6 osiągnął dwa. 15 kwietnia NIST ogłosił że nie nadąża z uzupełnianiem Narodowej Bazy Podatności przy wzroście zgłoszeń CVE o 263% w pięć lat.
Oba zdarzenia w tym samym miesiącu opisują paradoks który jest centralnym problemem cyberbezpieczeństwa w erze AI: narzędzia które pomagają znajdować błędy szybciej i taniej są dostępne dla obrońców i atakujących jednocześnie. Jednocześnie infrastruktura zarządzania podatnościami którą obrońcy od dekad traktowali jako fundament właśnie oficjalnie przyznała że nie nadąża.
AISI potwierdził niezależnie: Mythos Preview osiąga 73% skuteczności na zadaniach CTF poziomu eksperckiego "których żaden model nie mógł wykonać przed kwietniem 2025 roku." Tempo wzrostu zdolności jest takie że ewaluacje muszą być przeprojektowywane żeby nadążyć za modelem.
Eksploit Chrome za 2283 dolary na standardowym Opus 4.6 pokazał że granica między "tajnym modelem dla wybranych" a "powszechnie dostępnym modelem z pomocą człowieka" jest płynna. Trzynastoletni błąd w Apache ActiveMQ znaleziony przez Claude w kilka dni pokazał że zdolności AI w szukaniu podatności są już w rękach każdego badacza z subskrypcją.
OpenAI z GPT-5.4-Cyber i Anthropic z Mythos podejmują tę samą fundamentalną decyzję w tym samym miesiącu: ograniczanie zdolności modeli nie jest opcją bo te zdolności rosną jako efekt uboczny ogólnych ulepszeń. Jedyną realną kontrolą jest zarządzanie dostępem. Obie firmy zakładają że za kilka miesięcy podobne zdolności trafią do ogólnodostępnych modeli — i że wyścig polega na tym żeby obrońcy dostali je pierwsi.
Alex Stamos — cytowany w materiałach z ogłoszenia Mythos Preview 7 kwietnia — szacował pół roku zanim modele open-weight dogonią modele frontierowe w znajdowaniu podatności. Licząc od 7 kwietnia, zostało nam pięć miesięcy.
Co oznacza VECT jako metafora
VECT 2.0 to ransomware który nie może odszyfrować własnych plików — przez błąd implementacyjny obecny od pierwszej wersji, nigdy nienaprawiony, bo nikt nie przetestował czy płatne deszyfrowanie faktycznie działa. Nota okupu przekonuje ofiarę żeby zapłaciła za klucz który przestał istnieć w momencie szyfrowania.
Check Point Research rozkłada błąd na części: jeden nadpisywany bufor w pętli czterech iteracji, jeden nonce zapisywany zamiast czterech. Dwie linie kodu które ktoś napisał raz i nigdy nie sprawdził czy system faktycznie potrafi coś odszyfrować.
Jest jeszcze jedna warstwa tej historii. VECT ogłosił partnerstwo z BreachForums i dostarczył klucze dostępowe do panelu każdemu zarejestrowanemu użytkownikowi forum. Demokratyzacja ransomware dla każdego kto chce spróbować. Niski próg wejścia plus słaba implementacja kryptograficzna plus open affiliate dla tysięcy użytkowników BreachForums to nie mniej ataków — to więcej chaotycznych ataków, z mniejszą szansą na jakiekolwiek odzyskanie danych, bez profesjonalnych negocjacji które czasem kończą się częściowym przywróceniem.
VECT jako metafora miesiąca: systemy działające dokładnie jak zostały zaprojektowane, produkujące skutki których nikt nie przewidział, bo nikt nie zadał pytania co się stanie gdy dwie właściwości systemu zetkną się w nieprzewidziany sposób.
Agent AI który ładuje Git hooks z niezaufanego repozytorium działa dokładnie jak zaprojektowany. Dependabot który pobiera zatrute zależności działa dokładnie jak zaprojektowany. Token OAuth który dziedziczy uprawnienia całego enterprise'u działa dokładnie jak skonfigurowany. Mythos który bez polecenia opublikował szczegóły exploita na publicznych stronach działał dokładnie jak zaprojektowany — agent który próbował udokumentować swój sukces.
Żaden z tych systemów nie był zepsuty. Każdy robił dokładnie to do czego go zbudowano.
Trzy wnioski operacyjne
Pierwszy: Infrastruktura AI wymaga własnej kategorii w rejestrze aktywów.
Marimo, SGLang, LiteLLM, Flowise, Cursor, Gemini CLI — żadne z tych narzędzi nie jest prawdopodobnie w rejestrze aktywów większości organizacji które ich używają. Są traktowane jako narzędzia deweloperskie. Ale mają dostęp do kluczy i poświadczeń produkcyjnych. Luka między "narzędzie deweloperskie" a "system wymagający aktywnego zarządzania bezpieczeństwem" to luka którą kwiecień opisał pięcioma incydentami.
IBM X-Force zgłasza pięciokrotny wzrost ataków na łańcuch dostaw w pięć lat. Microsoft Security Blog mówi wprost że ekosystem agentów stanie się najbardziej atakowaną powierzchnią. Proofpoint: połowa organizacji z wdrożonym AI opisuje swoje bezpieczeństwo jako "nadrabiające zaległości." Inwentaryzacja co jest wdrożone i co ma dostęp do czego to warunek konieczny — nie optymalizacja.
Drugi: Agenty AI wymagają modelu zaufania analogicznego do modelu zero trust dla tożsamości.
Każdy agent który przetwarza zewnętrzne wejście i ma jednocześnie dostęp do zasobów lub uprawnień do wykonywania poleceń jest potencjalnie podatny na wstrzyknięcie przez to wejście. Comment and Control, Cursor CVE-2026-26268, Gemini CLI GHSA-wpqr-6v78-jr5g — wszystkie opisują tę samą klasę problemu w różnych środowiskach. Pytania które warto zadać teraz: które agenty mają dostęp do czego? Jakie zewnętrzne wejście przetwarzają? Gdzie przebiega granica między "wejściem zaufanym" a "wejściem niezaufanym"?
Trzeci: Okno łatania nie działa tak jak zakładałeś.
NIST NVD to był sygnał strukturalny, nie administracyjny komunikat. System informowania o podatnościach który przez dwie dekady był fundamentem zarządzania ryzykiem nie nadąża za tempem odkrywania. Jednocześnie tempo eksploitacji po ujawnieniu skróciło się do godzin dla trywialnych podatności. Dla organizacji z formalnym programem zarządzania podatnościami: warto zweryfikować czy katalog KEV prowadzony przez CISA — jedyne źródło które NIST zobowiązał się uzupełniać w pełni — jest faktycznym sygnałem priorytetyzacyjnym w twoim procesie, a nie jednym ze źródeł spośród wielu.
Na koniec miesiąca
Kwiecień 2026 nie był miesiącem jednego przełomowego ataku. Był miesiącem w którym kilka strukturalnych zmian osiągnęło widoczny próg jednocześnie: infrastruktura AI jako regularny cel, autonomia agentów jako mnożnik ryzyka, łańcuch dostaw jako skoordynowana infrastruktura, odkrywanie podatności przez AI wyprzedzające zdolność systemu do ich katalogowania.
Żadna z tych zmian nie jest odwracalna. Każda będzie miała konsekwencje w maju.
Wszystkie incydenty opisane w tym podsumowaniu:
Mythos Preview i Project Glasswing · CVE-2026-32211 Azure MCP · Pierwsze CVE w ekosystemie MCP · GrafanaGhost stored prompt injection · Marimo CVE-2026-39987 · Marimo — ciąg dalszy, NKAbuse przez Hugging Face · CPUID STX RAT · ESET poradnik — pierwsze minuty po ataku · Flowise CVE-2025-59528 · Marimo + Flowise — dwa okna · WordPress 7.0 długi informatywny · WordPress 7.0 + MCP = nowa powierzchnia · Smart Slider i Essential Plugin · Fałszywy instalator Claude + PlugX · NIST NVD ogranicza uzupełnianie · Patch Tuesday kwiecień — dwa zero-days · CVE-2026-34197 Apache ActiveMQ + Claude · Opus 4.6 exploit Chrome za 2283 dolary · SGLang CVE-2026-5760 plik modelu jako złośliwe oprogramowanie · Comment and Control — Claude Code, Gemini, Copilot · Checkmarx KICS + Bitwarden — DevSecOps supply chain · Shai-Hulud + TeamPCP — narzędzia AI do kodowania · OX Security — architektoniczny błąd STDIO w MCP · Mythos — nieautoryzowany dostęp przez Discord · GPT-5.4-Cyber + OpenAI Trusted Access · LMDeploy CVE-2026-33626 · Vercel przez Context.ai + skrypt Roblox · Entra Agent ID Administrator · Gemini CLI GHSA-wpqr-6v78-jr5g · Cursor CVE-2026-26268 · LiteLLM CVE-2026-42208 · VECT 2.0 wiper
