# Quo vadis, AI - kiedy sami wyłączymy internet

> AI znajduje luki szybciej, niż je łatamy. PHP2Shell, Claude Mythos, kampania prowadzona przez AI i atak na polską energetykę - felieton o odłączaniu od sieci.

- Source: https://snok.ai/pl/aktualnosci/blog/quo-vadis-ai-kiedy-wylaczymy-internet/
- Author: Jacek Bugajski
- Published: 2026-10-29

---
W środę 21 października 2026 roku Centralny Ośrodek Informatyki czasowo wyłączył strony Biuletynu Informacji Publicznej działające w systemie scentralizowanym. Tego samego dnia francuskie Ministerstwo Spraw Wewnętrznych zdjęło strony prefektur, niemiecki ITZBund kilka stron rządowych, a Holandia i Finlandia część serwisów publicznych. Fundacja Wikimedia sama wyłączyła część usług pomocniczych. Nikt ich nie zaatakował. Wyłączyli je administratorzy, bo tak było bezpieczniej.

Powodem były dwie luki w rdzeniu PHP, nazwane PHP2Shell (CVE-2026-109618 i CVE-2026-109619). Zespół PHP ocenił obie na 9,2 w dziesięciostopniowej skali. Pozwalają zdalnie, bez logowania, wykonać kod na serwerze, który obsługuje żądania WWW w PHP. Według Euronews i AFP na PHP działa około 70% stron na świecie. Jedną z luk firma Calif znalazła w sierpniu podczas audytu PHP finansowanego przez OpenAI. Według OpenAI w tym badaniu użyto modelu GPT-5.6 Sol. Należąca do Google firma Wiz niezależnie znalazła i zgłosiła obie luki.

O tym, że AI zmienia bezpieczeństwo, mówimy w branży od dawna. W zeszłym tygodniu zobaczyliśmy, jak wygląda to w praktyce: państwa, zamiast bronić swoich stron, wyłączają je. Moja teza jest prosta i trochę niewygodna. Ciemność, jeśli przyjdzie, nie przyjdzie jako jeden wielki atak na sieć. Przyjdzie jako seria naszych własnych decyzji o odłączeniu, coraz częstszych i coraz szerszych. Że będziemy odcinać się od internetu i chmury, uważam za przesądzone. Otwarte zostaje, czy zrobimy to według planu, czy w panice.

![Ręka wyjmująca kabel sieciowy z przełącznika w szafie serwerowej](https://snok.ai/images/blog/quo-vadis-ai-kabel.webp)

*Okładkę wygenerowała AI na podstawie zdjęcia autora, pozostałe zdjęcia w tym wpisie również wygenerowała AI.*

## PHP2Shell - cztery dni przewagi atakującego

Oś czasu jest ważniejsza od samych luk. Amazon Threat Intelligence zaobserwował próbę ataku w swoich pułapkach sieciowych 17 października, cztery dni przed publikacją poprawek. 20 października identyfikatory luk wyciekły publicznie, więc zespół PHP przyspieszył wydanie o dzień. Poprawki ukazały się 21 października, razem z komunikatami CERT Polska, CISA i CERT-EU. Amerykańska NSA zaleciła wyłączenie systemów, których nie da się załatać od razu.

W dniu publikacji poprawek CISA pisała jeszcze, że nie zaobserwowała wykorzystania luk, a wyłączenia były prewencyjne, co COI i niemieccy urzędnicy mówili wprost. Pięć dni później, 26 października, CISA wpisała obie luki do katalogu podatności wykorzystywanych w atakach (KEV). 28 października SecurityWeek opisał, za firmą Dream, operację o powiązaniach z Chinami: atakujący wyszukali w internecie 19 tys. zapór sieciowych jednego producenta, wybrali 240 celów w USA, Japonii, na Tajwanie i w Korei Południowej, a 23 i 24 października zaatakowali 25 urządzeń i na 24 z nich zostawili web shell z uprawnieniami roota. W jednym przypadku, w środowisku powiązanym z rządem USA, przeszli z zapory do serwera zarządzającego wszystkimi zaporami organizacji, a dalej do Active Directory. Urządzenie, które miało chronić sieć, stało się do niej wejściem.

To na razie relacja jednej firmy. Wiz 27 października napisał, że we własnej telemetrii nie widział jeszcze udanego ataku od początku do końca, choć partnerzy przekazali mu prywatnie działające exploity. Według Wiz tydzień po ujawnieniu podatnych pozostawało mniej niż 53% organizacji, których luka początkowo dotyczyła.

Najbardziej zaskoczyło mnie jedno zdanie z alertu CISA: obecność PHP w produkcie może nie być bezpośrednio widoczna. Innymi słowami, wiele organizacji nie wiedziało, czy ma się czego bać. Te, które miały aktualną inwentaryzację, łatały. Te, które jej nie miały, wyłączały wszystko, co mogło mieć PHP pod spodem. Według CNN wiele dużych platform działało dalej, bo opiera się na innych językach albo potrafi wdrożyć poprawkę w kilka godzin.

Szerzej o tygodniu, w którym PHP2Shell zbiegł się z poprawkami Node.js i Oracle, pisaliśmy w [Weekly Digest W43](https://snok.ai/pl/aktualnosci/blog/snok-weekly-digest-w43-ogien-w-fundamentach/).

![Polski zespół IT w warszawskim biurze wieczorem, przy laptopie i wydrukowanej liście systemów](https://snok.ai/images/blog/quo-vadis-ai-war-room.webp)

## AI czyta kod szybciej, niż zdążymy go poprawić

PHP2Shell wpisuje się w trend, który obserwujemy od wiosny. 7 kwietnia 2026 roku Anthropic opisał model Claude Mythos Preview. Według firmy model znalazł i potrafił wykorzystać podatności typu zero-day we wszystkich głównych systemach operacyjnych i przeglądarkach, w tym błąd w OpenBSD, który przetrwał 27 lat. Anthropic napisał, że ponad 99% znalezionych podatności nie było jeszcze załatanych, i nie udostępnił modelu publicznie. Dostęp dostali wybrani operatorzy krytycznego oprogramowania w ramach Project Glasswing. To są deklaracje producenta, większości znalezisk nie da się dziś sprawdzić, a Bruce Schneier publicznie studził przekonanie, że ten model wyraźnie przewyższa inne.

Bliżej naszej codzienności jest przykład z SAP. Według SecurityBridge Research Lab działający exploit na lukę w SAP Message Server (CVE-2026-58240, ocena 9,8) powstał 96 godzin po SAP Security Patch Day z 8 września, a asystent AI przyspieszył najżmudniejszą część pracy, czyli dopasowanie formatu bajtowego. Jeszcze kilka lat temu w świecie SAP liczyliśmy okno łatania w tygodniach. Dziś bezpieczniej liczyć je w dniach.

Zmienia się charakter tej pracy. Znalezienie luki w dojrzałym, wielokrotnie audytowanym kodzie było kiedyś pracą wąskiej grupy specjalistów. Teraz staje się kosztem obliczeniowym. Anthropic sam podaje, że ponad tysiąc przebiegów skanera na OpenBSD kosztowało mniej niż 20 tys. USD.

## Prospekt Anthropic - 94 strony ryzyk

26 października 2026 roku Anthropic złożył w amerykańskiej komisji papierów wartościowych SEC prospekt emisyjny (formularz S-1). Sekcja czynników ryzyka zajmuje w nim 94 strony, od 26. do 119. To lektura, którą polecam każdemu, kto wciąż uważa zagrożenia AI za wymysł publicystów, bo tym razem pisze je producent modelu, pod odpowiedzialnością prawną wobec inwestorów.

Anthropic pisze tam wprost, że jego modele były i mogą nadal być wykorzystywane albo manipulowane do generowania szkodliwych treści i wykonywania szkodliwych działań, w tym do prowadzenia cyberataków, a atakujący obchodzą zabezpieczenia m.in. przez prompt injection. Przyznaje też, że jego zabezpieczenia i systemy monitorowania bywały źle skonfigurowane albo przypadkiem wyłączone. Ostrzega też, że ze względu na zdolności wykrywania podatności podmioty państwowe mogą atakować sam model Mythos, a grupy dysponujące technologią AI o podobnych zdolnościach ofensywnych mogą przerosnąć jego własne zabezpieczenia. Jeżeli firma, która zbudowała jedno z najsilniejszych dziś narzędzi do szukania luk, pisze inwestorom, że jej zabezpieczenia mogą nie wystarczyć przeciw atakującym z podobną technologią, to reszta z nas powinna przestać udawać, że u nas jest inaczej.

## Człowiek przestaje być wąskim gardłem ataku

Najbardziej niepokojący dokument ostatniego roku w tej dziedzinie dotyczy sposobu działania atakujących. 13 listopada 2025 roku Anthropic opisał kampanię szpiegowską grupy, którą z wysoką pewnością ocenił jako sponsorowaną przez państwo chińskie. AI wykonała według firmy 80-90% kampanii wobec około trzydziestu celów: firm technologicznych, instytucji finansowych, producentów chemikaliów i agencji rządowych. Człowiek podejmował cztery do sześciu kluczowych decyzji na kampanię. W szczycie AI wysyłała tysiące żądań, często kilka na sekundę. Włamania udały się w niewielkiej liczbie przypadków.

Z tego opisu wyciągam dla siebie jeden wniosek. Atakujący nie musi już być lepszy od obrońcy w każdym kroku. Wystarczy, że zdefiniuje cel i zatwierdzi kilka decyzji, a resztę wykona maszyna, która nie męczy się o trzeciej w nocy. Ludzie przyspieszają to na dwa sposoby: ci po złej stronie wyznaczają cele i omijają zabezpieczenia modeli, a ci po dobrej stronie wdrażają systemy szybciej, niż zdążą je zinwentaryzować. Podejrzewam, że ta druga grupa jest liczniejsza, a jej udział rzadziej trafia do raportów. Pisaliśmy o tym niedawno w Bezpiecznym Wtorku o [shadow AI i agentach poza kontrolą działu IT](https://snok.ai/pl/aktualnosci/blog/shadow-ai-agenci-ai-kontrola-uipath/).

Ten sam model, który pomaga znaleźć lukę w PHP przed przestępcą, w innych rękach skraca drogę do exploita. Dlatego o wyniku tego wyścigu decyduje szybkość przejścia od wiedzy do działania: od zgłoszenia do poprawki po jednej stronie, od poprawki do ataku po drugiej. Jakość samego modelu jest drugorzędna.

![Stacja elektroenergetyczna i maszt telefonii komórkowej o zmierzchu, za nimi panorama Warszawy z jedną ciemną dzielnicą](https://snok.ai/images/blog/quo-vadis-ai-siec.webp)

## Od strony WWW do kaloryfera

Strona BIP to najmniejszy problem. 29 grudnia 2025 roku doszło do skoordynowanego cyberataku na polską energetykę: co najmniej 30 farm wiatrowych i fotowoltaicznych oraz elektrociepłownię, która dostarcza ciepło prawie pół milionowi odbiorców. Według Ministerstwa Cyfryzacji i CERT Polska atak był długo przygotowywany i miał charakter państwowy, a złośliwe oprogramowanie miało trwale niszczyć dane i blokować urządzenia przemysłowe. Do przerw w dostawach energii nie doszło. Ten atak nie był przypisany AI i nie chcę tego sugerować. Pokazuje jednak, gdzie leży stawka: miesiące cierpliwego przygotowania w sieciach przemysłowych. Moja obawa jest taka, że AI te miesiące skróci.

Druga lekcja dotyczy zależności. 20 października 2025 roku błąd w systemie DNS usługi DynamoDB w regionie AWS us-east-1 zatrzymał na wiele godzin dziesiątki popularnych usług na całym świecie. 18 listopada 2025 roku Cloudflare przez około trzy godziny nie obsługiwał dużej części ruchu, a przyczyną była zmiana uprawnień w bazie danych, nie atak. Skoro wystarczył do tego zwykły błąd konfiguracji, łatwo sobie wyobrazić, ile mógłby osiągnąć ktoś, kto szuka takiego miejsca celowo.

Energetyka, telefonia komórkowa, płatności i chmura zależą od siebie nawzajem. Stacja bazowa bez zasilania działa tak długo, jak jej akumulatory. Terminal płatniczy bez łączności nie przyjmie karty. Chmura bez sieci jest dla użytkownika niedostępna, nawet jeśli w centrum danych wszystko działa. W takim łańcuchu najsłabszym ogniwem bywa system, którego nikt nie potrafi odłączyć i uruchomić osobno, nawet jeśli nikt go nie zaatakował.

## Kiedy odłączymy internet

Kiedy robiłem testy penetracyjne systemów SAP, zdarzyło mi się, że administrator klienta, gdy zobaczył, że mam uprawnienia roota na systemie produkcyjnym, po prostu wyjął kabel sieciowy z mojego notebooka. Najprostsza możliwa reakcja na intruza: odciąć go od sieci. Myślę, że wracamy do tego odruchu, tylko w innej skali. Za chwilę będziemy wyjmować kabel nie pentesterowi, ale całej organizacji, żeby roje agentów AI nie mogły dosięgnąć naszych zasobów.

<div style="background:#F5F1E8; color:#14141F; border-radius:16px; padding:36px 32px; margin:2.5rem 0;">
  <p style="margin:0 0 6px; font-size:0.85em; letter-spacing:0.04em; color:#5A5A6E;">SNOK Press · książka do pobrania</p>
  <p style="margin:0 0 14px; font-family:Georgia,'Times New Roman',serif; font-size:1.5em; line-height:1.25; color:#0D0D1A;">Cyberbezpieczeństwo SAP od&nbsp;A&nbsp;do&nbsp;Z</p>
  <p style="margin:0 0 24px; color:#3A3A4E;">Ścieżki ataku na systemy SAP, uprawnienia, agenci AI jako zagrożenie i wsparcie obrony, własne laboratorium red team oraz gotowe listy kontrolne do audytu. 304 strony, wydanie polskie i angielskie, do pobrania po podaniu adresu służbowego.</p>
  <a href="/pl/materialy/cyberbezpieczenstwo-sap-od-a-do-z/" style="display:inline-block; background:#DB1620; color:#FFFFFF; padding:14px 28px; border-radius:9999px; font-weight:600; text-decoration:none;">Pobierz książkę</a>
</div>

Dalej piszę o prognozie, nie o faktach. Uważam, że w ciągu kilku najbliższych lat kontrolowane odłączanie się od internetu stanie się w firmach i administracji zwykłą procedurą, tak jak dziś jest nią odtwarzanie z kopii zapasowej. Kilka razy w roku, na godziny albo dni, gdy pojawi się luka w czymś, co mamy wszędzie, a poprawki jeszcze nie ma.

Nie wierzę natomiast w masową ucieczkę z chmury. Tydzień PHP2Shell pokazał coś odwrotnego: najszybciej łatali ci, którzy mają automatyzację i duże zespoły, czyli właśnie operatorzy chmur i platform. Zostaniemy w chmurze i jednocześnie będziemy uczyć się działać bez niej. Uważam to za dojrzałą architekturę.

Taka architektura zaczyna się od kilku decyzji, które dziś podejmuje niewiele zarządów. Pierwsza to pełna inwentaryzacja oprogramowania wystawionego do internetu, łącznie z tym, co siedzi w środku kupionych produktów. Bez niej każda luka w powszechnym komponencie kończy się wyłączaniem wszystkiego na ślepo.

Druga to umocowanie. Dyżurny administrator, który o drugiej w nocy odcina system, musi działać na podstawie zasad przyjętych przez zarząd wcześniej, a nie zgody zdobywanej telefonicznie w trakcie incydentu.

Trzecia to tryb wyspowy dla procesów krytycznych: lokalne kopie danych, procedury na papierze, łączność zapasowa i zasilanie awaryjne liczone w godzinach pracy firmy, nie w minutach. Czwarta jest najprostsza i najczęściej pomijana - trzeba to ćwiczyć. Plan, którego nikt nie przećwiczył, sprawdza się wyłącznie w czasie audytu.

![Segregator z procedurami, radiotelefon, zamknięty laptop i powerbank na stole w sali kryzysowej](https://snok.ai/images/blog/quo-vadis-ai-tryb-offline.webp)

## Czego jeszcze nie wiem

Nie wiem, czy w zeszłym tygodniu wyłączyliśmy za dużo, czy za mało. 21 października nikt publicznie nie potwierdził udanego ataku, więc wyłączenia wyglądały na nadmiar ostrożności. Pięć dni później luki były w katalogu KEV, a zapory w środowisku rządowym miały już web shell. Przy następnej luce, z działającym exploitem pierwszego dnia, ta sama ostrożność może okazać się zbyt wolna.

Nie wiem też, kto pierwszy przekroczy próg, za którym AI znajduje luki szybciej, niż ludzie są w stanie je zrozumieć, nie mówiąc o poprawieniu. Anthropic przy rozszerzeniu Project Glasswing zakładał, że modele tej klasy w ciągu 6-12 miesięcy pojawią się także w innych laboratoriach. Jeżeli to prawda, okno między ujawnieniem a atakiem będzie się kurczyć dalej, a ruch się przeniesie: z łatania na ograniczanie skutków i na umiejętność czasowego zniknięcia z sieci.

Wiem natomiast, gdzie zacząć. Od listy systemów, które mamy, i od odpowiedzi na pytanie, które z nich potrafimy wyłączyć w godzinę bez zatrzymania firmy. Drugi krok to sprawdzenie własnej infrastruktury tymi samymi metodami, których użyje atakujący. Dlatego w SNOK oferujemy już komercyjnie autorskie black-boxy do testów penetracyjnych: urządzenia z lokalnymi modelami językowymi bez filtrów odmowy (uncensored) i zestawem narzędzi znanych każdemu pentesterowi, zamknięte w odpowiednie ramy organizacyjne i zabezpieczenia. Model pracuje wyłącznie na urządzeniu, bez chmury dostawcy, więc atak z udziałem AI możemy przećwiczyć w sieci klienta, zanim zrobi to ktoś inny.

W SNOK pomagamy też przy [audytach zgodności z NIS2 i DORA](https://snok.ai/pl/oferta/bezpieczenstwo-sap/audyt-nis2-dora/), w usługach [cyberbezpieczeństwa](https://snok.ai/pl/oferta/cyberbezpieczenstwo/) i w [bezpieczeństwie wdrożeń AI](https://snok.ai/pl/oferta/automatyzacja-ai/ai-security/). W sierpniu pytałem w [Quo vadis, inżynierze](https://snok.ai/pl/aktualnosci/blog/quo-vadis-inzynierze/), dokąd AI prowadzi nasz zawód. Dziś to samo pytanie zadaję samej technologii, a odpowiedź zależy bardziej od nas niż od niej.

## Źródła

- [CERT Polska - Krytyczne podatności w PHP umożliwiające zdalne wykonanie kodu (21.10.2026)](https://moje.cert.pl/komunikaty/2026/195/krytyczne-podatnosci-w-php-umozliwiajace-zdalne-wykonanie-kodu/)
- [CISA - Critical Vulnerabilities in PHP Require Immediate Patching (21.10.2026)](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching)
- [Euronews - Websites go dark after AI exposes major programming language security flaw (22.10.2026)](https://www.euronews.com/2026/10/22/websites-go-dark-after-ai-exposes-major-programming-language-security-flaw)
- [Rzeczpospolita - Miliony stron internetowych zagrożone, rządy wyłączają serwisy (22.10.2026)](https://cyfrowa.rp.pl/it/art45376571-miliony-stron-internetowych-zagrozone-rzady-wylaczaja-serwisy-luki-pomogla-wykryc-ai)
- [CISA - CISA Adds Two Known Exploited Vulnerabilities to Catalog (26.10.2026)](https://www.cisa.gov/news-events/alerts/2026/10/26/cisa-adds-two-known-exploited-vulnerabilities-catalog)
- [SecurityWeek - China-linked hackers exploit PHP2Shell to root firewalls (28.10.2026)](https://www.securityweek.com/china-linked-hackers-exploit-php2shell-to-root-firewalls/)
- [Wiz - PHP2Shell: exploitation so far (27.10.2026)](https://www.wiz.io/blog/php2shell-exploitation-so-far)
- [Tenable - PHP2Shell, najczęściej zadawane pytania (21.10.2026)](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote)
- [Anthropic - Claude Mythos Preview (7.04.2026)](https://www.anthropic.com/research/mythos-preview)
- [Anthropic - Expanding Project Glasswing (06.2026)](https://www.anthropic.com/news/expanding-project-glasswing)
- [Bruce Schneier - Anthropic's Project Glasswing Update (06.2026)](https://www.schneier.com/blog/archives/2026/06/anthropics-project-glasswing-update.html)
- [Anthropic, PBC - prospekt emisyjny, formularz S-1, SEC (26.10.2026), sekcja Risk Factors s. 26-119](https://www.sec.gov/Archives/edgar/data/2130357/000162828026067168/anthropicpbc-sx1.htm)
- [Anthropic - Disrupting the first reported AI-orchestrated cyber espionage campaign (13.11.2025)](https://www.anthropic.com/news/disrupting-AI-espionage)
- [Ministerstwo Cyfryzacji - Cyberatak na infrastrukturę sektora energii w Polsce, raport CERT Polska (30.01.2026)](https://www.gov.pl/web/cyfryzacja/cyberatak-na-infrastrukture-sektora-energii-w-polsce-opublikowano-szczegolowy-raport-cert-polska)
- [The Register - Cloudflare coughs, half the internet catches a cold (18.11.2025)](https://www.theregister.com/2025/11/18/cloudflare_outage)
- [InfoQ - analiza awarii AWS us-east-1 z 20.10.2025 (11.2025)](https://www.infoq.com/news/2025/11/aws-disruption-cloud)
