Tydzień temu Palo Alto Networks ogłosił 75 luk bezpieczeństwa w 26 CVE. Zazwyczaj ogłasza pięć miesięcznie. Microsoft zamknął Patch Tuesday z 120 podatnościami — jeden z największych w historii — z czego 16 znalazł własny system AI w jeden miesiąc. Mozilla wcześniej naprawiła 423 błędy Firefox w jednym cyklu, gdy miesięczna średnia z zeszłego roku wynosiła 21.
Tom Gallagher, VP of Engineering w Microsoft Security Response Center, powiedział wprost: "Oczekuję że AI-wspomagane polowanie na błędy będzie zwiększać wydania Patch Tuesday."
The Register ochrzcił to vulnpocalypse. To słowo jest ironiczne ale opisuje coś realnego. Żeby jednak zrozumieć czym ta rzecz naprawdę jest — trzeba najpierw odróżnić ją od tego czym nie jest.
Nie więcej dziur. Więcej widoczności.
Najtrudniejszą rzeczą do zakomunikowania w tej historii jest to że "więcej podatności" nie znaczy "gorszy kod." Palo Alto nie pisało przez ostatnie miesiące kiepskiego kodu który nagle stał się dziurawy. Mozilla nie zdegradowała Firefox do poziomu niezabezpieczonego produktu. Te podatności istniały wcześniej. Były niewidoczne.
AISLE — firma AI security — odkryła wszystkie 12 CVE w skoordynowanym wydaniu OpenSSL ze stycznia 2026, w tym rzadki high-severity stack buffer overflow w parsowaniu wiadomości CMS. OpenSSL to jeden z najbardziej przeanalizowanych projektów open source na świecie. Każdy poważny badacz bezpieczeństwa przez ostatnią dekadę miał OpenSSL na radarze. AISLE odkryła 13 z 14 CVE przypisanych OpenSSL w 2025 roku.
Depthfirst znalazł osiemnastoletni błąd w nginx w sześć godzin. Sunkavally znalazł trzynastoletni błąd w Apache ActiveMQ z pomocą Claude. Mythos znalazł 27-letni błąd w OpenBSD. Błąd w FFmpeg z 2010 roku. MDASH Microsoftu odtworzył 96-100% podatności znalezionych przez ludzkich badaczy przez ostatnie pięć lat — na komponentach które były "deeply audited."
Wzorzec jest konsekwentny. AI nie tworzy nowych dziur. Odkrywa zaległości bezpieczeństwa które nagromadziły się przez lata lub dekady w kodzie który wszyscy traktowali jako dość bezpieczny.
Dwie klasy odkryć i dlaczego to ma znaczenie
Ważne jest rozróżnienie między tym co AI znajduje a co znajdowały tradycyjne narzędzia.
Klasyczne skanery bezpieczeństwa — fuzzery, analizatory statyczne, SAST — są zoptymalizowane pod kątem znanych klas błędów: przepełnień buforów, use-after-free, SQL injection, format string. Szukają znanych wzorców w znanych miejscach. Są bardzo dobre w tym co robią. I przez lata tworzyły fałszywe poczucie bezpieczeństwa dla kodu który nie miał takich błędów.
LLM-y znajdują inną klasę. GTIG opisał to w raporcie o pierwszym AI zero-dayu: modele językowe czytają kod tak jak deweloper — rozumieją intencję, porównują ją z implementacją, i znajdują miejsca gdzie te dwie rzeczy się rozmijają. Hardcoded trust assumptions, logiczne sprzeczności między projektem a kodem, dormant logic errors które wyglądają funkcjonalnie poprawnie dla każdego automatycznego narzędzia ale są strategicznie zepsute z perspektywy bezpieczeństwa.
Tej klasy błędów tradycyjne narzędzia strukturalnie nie widzą. Właśnie dlatego siedziały w produkowanym przez dziesiątki lat kodzie bez wykrycia. I właśnie dlatego gdy AI zaczyna skanować — wyniki są tak dramatyczne: nie dlatego że AI jest "dobre," ale dlatego że skanuje obszar który wcześniej był praktycznie niemonitorowany.
Liczby które pokazują skalę zmiany
Barracuda prowadzi Mythos Hype Index — codzienny tracker porównujący wzrost CVE z 2026 z historycznymi wzorcami. Wynik: wzrost jest powyżej historycznej linii bazowej, ale nie dramatycznie. Mniej niż 200 CVE ma na dziś atrybucję AI lub LLM.
Ta liczba jest myląca. Atrybucja jest trudna i rzadka — większość organizacji które korzystają z AI do skanowania nie opisuje każdego CVE jako "znalezione przez AI." Palo Alto dopiero 14 maja powiedział publicznie że użył Mythos. Microsoft dopiero przy tym Patch Tuesday ujawnił MDASH. Ile wcześniejszych odkryć nigdy nie dostało etykiety "AI found"?
FIRST prognozuje 60 000 CVE w 2026 roku. Zero Day Clock — projekt śledzący MTTE — mówi że mean time-to-exploit spadło z 2.3 lat w 2018 roku do poniżej 20 godzin w 2026. Raporty z bugs per week w Linux kernel: wzrost z 2 do 10 tygodniowo w pierwszych miesiącach 2026.
Resilient Cyber wskazuje na drugie dno: GitHub przetworzył 1 miliard commitów w 2025 roku i jest na trajektorii 14 miliardów w 2026 — 14-krotny wzrost rok do roku, napędzony przez AI coding agents. Każdy commit to nowe zależności, nowe ścieżki kodu, nowa powierzchnia ataku. Tempo tworzenia nowego kodu rośnie szybciej niż tempo skanowania starego. Dług bezpieczeństwa rośnie po obu stronach jednocześnie.
Infrastruktura która nie nadąża
W kwietniu pisaliśmy o decyzji NIST — Narodowa Baza Podatności ogranicza uzupełnianie danych, bo przy 263% wzroście CVE w pięć lat i prognozowanych 60 000 w tym roku po prostu nie nadąża. Wtedy to wyglądało jak jeden sygnał strukturalny. Teraz ma swój pełny kontekst.
Dan Gibson, ekspert który przemawiał na VulnCon 2026, powiedział że nie zdziwiłby się gdyby Anthropic i OpenAI zostały CVE Numbering Authorities do końca roku. CISA wprost wskazała że firmy AI muszą odgrywać większą rolę w programie CVE — bo obecna baza uczestników nie obsłuży wolumenu generowanego przez AI. Oracle rozszerzył Critical Patch Updates z kwartalnych na miesięczne. Microsoft mówi że oczekuje dalszego wzrostu Patch Tuesday.
Sophos w Active Adversary Report 2026 dokumentuje trajektorię: median attacker dwell time to teraz trzy dni. Okno między ujawnieniem a eksploitacją kompresuje się od lat. Mandiant w M-Trends 2026 pokazał ujemną medianę: exploity pojawiają się przed łatkami dla 28.3% CVE. Sophos: "AI-generated exploit development nie tylko dalej kompresuje to okno — grozi jego całkowitą eliminacją. Gdy model może przeczytać diff łatki i wyprodukować działający exploit zanim większość organizacji zacznie swój proces change-control — tradycyjne cykle łatania stają się zobowiązaniem, nie obroną."
Thomas Ptacek i kontrowersja
W maju 2026 Thomas Ptacek, jeden z najbardziej szanowanych badaczy bezpieczeństwa, opublikował tekst zatytułowany "vulnerability research is cooked." Teza: AI agents zaraz utopią nas w stałym strumieniu zwalidowanych, exploitowalnych, high-severity podatności szybciej niż ktokolwiek zdoła je naprawić.
Intigriti i inne firmy crowdsourced security obserwują wzrost zgłoszeń przypisywanych AI — nie tylko przez wzrost produktywności, ale przez wzrost liczby badaczy i ich base klientów. XBOW, autonomiczny system AI offensive, w czerwcu 2025 trafił na czołówkę leaderboardu HackerOne — wyprzedzając każdego ludzkiego hakera na platformie.
Sophos, Barracuda, Resilient Cyber — wszyscy zgadzają się co do kierunku. Różnią się co do tempa i co do wniosku: czy to jest powód do paniki, czy do reorganizacji procesów.
Barracuda prezentuje ostrożniejszy pogląd: wzrost jest realny ale poniżej najbardziej dramatycznych prognoz na ten moment. Atrybucja AI jest rzadka. Patch prioritization, asset visibility i exposure reduction pozostają lepszymi wskaźnikami ryzyka niż surowy wolumen CVE.
To jest zdrowe zastrzeżenie. Ale "wzrost jest poniżej najdramatyczniejszych prognoz" nie jest zaprzeczeniem trendu — jest tylko informacją że jesteśmy na początku krzywej, nie na szczycie.
Asymetria która jest prawdziwym problemem
Jest jedna obserwacja która łączy wszystkie te dane w jeden wniosek.
Po stronie odkrywania: AI daje dramatyczną przewagę. Zarówno obrońcy jak i atakujący mają dostęp do tych samych możliwości — pisaliśmy o tym przy raporcie GTIG. Różnica polega na tym że obrońca musi naprawić wszystko co odkryje, a atakujący musi znaleźć tylko jeden exploit.
Po stronie naprawiania: ludzkie procesy, ludzkie tempo, ludzkie ograniczenia. Change management, testing, deployment pipelines, organizacyjna inercja. Sophos dokumentuje że 45% podatności w systemach dużych firm nigdy nie jest naprawianych.
Vulnpocalypse nie jest apokalipsą dlatego że nagle mamy za dużo dziur. Vulnpocalypse jest apokalipsą dlatego że tempo odkrywania oderwało się od tempa naprawiania — i AI przyspiesza stronę odkrywania znacznie szybciej niż może przyspieszyć stronę naprawiania.
Co to znaczy praktycznie
Tradycyjne zarządzanie podatnościami zakładało dwa etapy: skanowanie i patching. W momencie gdy skanowanie AI przynosi setki wyników z jednego produktu — priorytetyzacja staje się trudniejsza niż samo patching.
Praktyczne wnioski z tego tygodnia:
Dla organizacji które wdrażają AI scanning: wyniki będą dramatycznie wyższe niż z tradycyjnych narzędzi. To jest dobre — ale wymaga przygotowania procesów na wyższy wolumen niż dotychczas.
Dla wszystkich: zmiana filozofii patching — od "czy jest znana eksploitacja" do "czy jest podatność w krytycznym komponencie." Przy AI po stronie atakujących okno między disclosure a exploitation kurczy się do godzin. Czekanie na potwierdzoną eksploitację zanim zaczniemy łatać to coraz mniejszy bufor.
Dla CISO: Tom Gallagher z Microsoftu mówi że oczekuje dalszego wzrostu Patch Tuesday. Oracle rozszerza łatki z kwartalnych na miesięczne. Środowisko patch management musi być gotowe na obsługę wyższego wolumenu przy tym samym lub mniejszym zespole.
Dla deweloperów: AI code review jako standard — nie jako luxury feature. Jeśli te same modele które wchodzą na rynek jako narzędzia do skanowania dla atakujących są dostępne dla deweloperów, używanie ich do audytu przed producją to nie jest opcja, to jest higiena.
Podsumowanie
Vulnpocalypse to nie jest koniec bezpieczeństwa. To jest koniec jednego modelu bezpieczeństwa — tego który zakładał że "dobrze audytowany" kod jest bezpieczny, że ludzkie tempo patching'u nadąży za ludzkim tempem odkrywania podatności, i że narzędzia skanowania które używamy od lat pokrywają przestrzeń ryzyka w wystarczającym stopniu.
Żadne z tych założeń nie jest już prawdziwe.
75 luk w Palo Alto w pięć tygodni to nie jest katastrofa. To jest prawidłowy wynik gdy po raz pierwszy użyjesz narzędzia które widzi klasę błędów której poprzednie narzędzia nie widziały. Podobny wynik zobaczy każda organizacja która uruchomi te modele na własnym kodzie.
Pytanie nie brzmi czy to się stanie. Pytanie brzmi czy infrastruktura zarządzania ryzykiem — ludzie, procesy, narzędzia, budżety — jest gotowa na obsługę tej informacji zanim zrobi to ktoś inny.
Na podstawie tego co NIST powiedział w kwietniu, co Sophos dokumentuje w Active Adversary Report, i co Tom Gallagher z Microsoftu mówi o przyszłości Patch Tuesday: odpowiedź dla większości organizacji brzmi "jeszcze nie."

Źródła
The Register — pierwotne użycie terminu "vulnpocalypse" i dane Palo Alto i Mozilla: https://www.theregister.com/patches/2026/05/14/welcome-to-the-vulnpocalypse-as-vendors-use-ai-to-find-bugs-and-patches-multiply-like-rabbits/
SecurityWeek — MDASH Microsoftu i wyniki Palo Alto z detalami: https://www.securityweek.com/microsoft-palo-alto-networks-find-many-vulnerabilities-by-using-ai-on-their-own-code/
Intigriti — analiza "Vulnpocalypse Now" z perspektywy bug bounty: https://www.intigriti.com/blog/business-insights/vulnpocalypse-now-how-ai-is-changing-vulnerability-discovery
Sophos — "The vulnerability flood is here" z Active Adversary Report 2026: https://www.sophos.com/en-us/blog/vulnerability-flood-is-here
Resilient Cyber — "The NVD Just Threw In The Towel" z analizą CVE systemu pod presją: https://www.resilientcyber.io/p/the-nvd-just-threw-in-the-towel-now
EMSI — "Zero-Day Every Day" z danymi AISLE i OpenSSL: https://www.emsi.me/tech/ai-ml/zero-day-every-day-the-vulnpocalypse-is-here/2026-03-29/123a25
Barracuda Mythos Hype Index — tracker CVE growth vs historyczne wzorce: https://blog.barracuda.com/2026/05/12/mythos-hype-index-ai-vulnerability-discovery
Security Boulevard — Zero Day Clock i mean time-to-exploit: https://securityboulevard.com/2026/05/the-ai-vulnerability-storm-is-here-is-your-security-program-breach-ready/
Help Net Security — forecast Patch Tuesday z perspektywą Oracle i FIRST: https://www.helpnetsecurity.com/2026/05/08/may-2026-patch-tuesday-forecast/
BleepingComputer — pełna lista Patch Tuesday maj 2026: https://www.bleepingcomputer.com/news/microsoft/microsoft-may-2026-patch-tuesday-fixes-120-flaws-no-zero-days/















































































































Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł