Wczoraj razem z zespołem aktualizowaliśmy serwery naszych klientów. Powód nazywa się PHP2Shell i jeśli Twój sklep albo strona firmowa działa na PHP, ta historia dotyczy też Ciebie. A szanse są duże, bo na PHP działa większość stron w internecie.

9,2na 10 punktów w ocenie powagi luki według zespołu PHP
5.4od tej wersji PHP, czyli od około 14 lat, podatny jest kod
45 minpo publikacji luki Cloudflare liczył już dziesiątki tysięcy prób ataku

Co się właściwie stało

Zacznijmy od podstaw. PHP to język, w którym napisane są Magento, WordPress, Drupal i wiele sklepów i systemów dla firm. PHP2Shell to dwie luki w samym PHP, oznaczone jako CVE-2026-109618 i CVE-2026-109619. Pozwalają uruchomić na serwerze dowolny kod bez logowania1. Mówiąc prościej: obcy człowiek może przejąć serwer, na którym działa Twój sklep.

Ta historia ma kilka zwrotów akcji:

  1. Sierpień 2026Dwa zespoły, Calif i Wiz Research, niezależnie od siebie znajdują błędy w PHP z pomocą modeli AI. Wiz zgłasza je twórcom PHP 24 sierpnia2,3.
  2. 17 październikaAmazon odnotowuje pierwszą próbę ataku, cztery dni przed publikacją łatki4.
  3. 20 październikaInformacja o lukach wycieka na Hacker News, zanim kończy się okres poufności5.
  4. 21 października, 14:00 UTCTwórcy PHP publikują poprawione wersje dzień wcześniej, niż planowali, i apelują: zaktualizujcie teraz1.
  5. 21 i 22 październikaWedług szefa Cloudflare liczba prób ataku rośnie od dziesiątek tysięcy w pierwszych 45 minutach do milionów6.

Dlaczego to takie poważne

Większość luk, o których czytamy, dotyczy jednej wtyczki albo jednego programu. Tu problem siedzi pod spodem, w silniku, na którym stoi cała strona. Dlatego aktualizacja Magento niczego nie zmienia. Firma Sansec, która specjalizuje się w bezpieczeństwie sklepów, potwierdziła, że da się w ten sposób przejąć sklep na Magento 2.4.9, nawet gdy jego własny kod jest bez zarzutu7.

Druga zła wiadomość: jedna z luk pozwala odczytać fragmenty pamięci serwera, a w nich mogą być hasła, tokeny sesji i klucze API2,7. Kto przejmie sklep, może więc dostać się dalej, na przykład do systemu płatności albo magazynu.

CERT Polska pisze wprost, że podatne są wszystkie wersje PHP od 5.4 w górę, a jedyną skuteczną ochroną jest instalacja poprawionej wersji8. Skala była taka, że w Polsce część serwisów publicznych na chwilę wyłączono9.

Jedyną skuteczną metodą ochrony jest instalacja poprawionej wersji PHP. CERT Polska, komunikat 196/2026

Dlaczego takich luk przybywa

Ten błąd siedział w PHP od kilkunastu lat. Znaleźli go dopiero badacze, którzy przeszukiwali kod z pomocą modeli AI. Wiz napisał, że jeden badacz z pomocą AI zrobił w tydzień to, co wcześniej zajęłoby miesiące pracy zespołu światowej klasy2.

Spójrzmy, jak to wygląda w liczbach:

48 185nowych luk z numerem CVE w 2025 roku, o 20,6% więcej niż rok wcześniej
−7 dniśredni czas do ataku w 2025 roku według Mandiant: atak zaczyna się przed łatką
23,43%wykorzystanych luk zaatakowano najpóźniej w dniu ich publikacji (1. połowa 2026)

Liczba zgłoszonych luk rośnie z roku na rok12. Według raportu Mandiant w 2018 roku od publikacji luki do pierwszego ataku mijały średnio 63 dni, a w 2025 roku atakujący zaczynali szacunkowo 7 dni przed publikacją łatki10. VulnCheck policzył, że prawie co czwarta wykorzystana luka była atakowana najpóźniej w dniu, w którym dostała numer CVE11. Już w 2025 roku systemy AI w konkursie DARPA znalazły 54 z 63 podłożonych błędów i do tego 18 prawdziwych, nieznanych wcześniej13.

AI pomaga obu stronom. Te same narzędzia, które znalazły PHP2Shell, pozwalają atakującym szybciej budować exploity, i OpenAI mówi o tym otwarcie3. Dla właściciela sklepu oznacza to, że czas między publikacją luki a atakiem liczy się dziś w godzinach. Przy PHP2Shell próby ataku ruszyły w ciągu kilkudziesięciu minut6.

Co zrobiliśmy dla naszych klientów

Komunikaty o bezpieczeństwie śledzimy na bieżąco. Gdy twórcy PHP opublikowali poprawione wersje, zaktualizowaliśmy PHP u naszych klientów jeszcze tego samego dnia.

Potem przejrzeliśmy wszystkie sklepy i serwery, którymi się opiekujemy, żeby żaden nie został na podatnej wersji. Klienci dostali od nas wiadomość, czy luka ich dotyczyła i co zrobiliśmy, zanim zdążyli zapytać.

Tak według mnie powinna wyglądać opieka nad sklepem. Gdy w internecie robi się gorąco, właściciel nie musi szukać programisty i tłumaczyć mu, o co chodzi.

Co zrobić, jeśli nie jesteś naszym klientem

Jeśli Twoim sklepem zajmuje się ktoś inny albo sam dbasz o serwer, oto lista na dziś, oparta na zaleceniach twórców PHP, CERT Polska i amerykańskiej CISA1,8,15:

  1. Zaktualizuj PHP. Bezpieczne są wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Po aktualizacji trzeba zrestartować procesy PHP.
  2. Poproś hosting o potwierdzenie na piśmie. Zapytaj, jaka wersja PHP działa na Twoim serwerze i kiedy ją zaktualizowano.
  3. Nie polegaj tylko na zaporze. Reguły Cloudflare pomagają, ale atakujący już je obchodzą14.
  4. Sprawdź logi od 17 października. Wtedy odnotowano pierwszą próbę ataku4.
  5. Zmień hasła i klucze API. Mogły wyciec z pamięci serwera, zanim zainstalowano łatkę2.
  6. Jeśli PHP nie da się zaktualizować, wyłącz stronę albo schowaj ją za zaporą. Tak radzi CISA dla systemów, których nie da się od razu załatać15.

Jak bezpiecznie przejść przez czasy AI

Amerykańska CISA skróciła w tym roku terminy na łatanie najgroźniejszych luk do 3 dni i jako powód podała właśnie AI16. Sklep aktualizowany raz na kilka miesięcy przy takim tempie zostaje bez ochrony na długie tygodnie.

U nas bezpieczeństwo to stały element opieki nad projektem. Śledzimy komunikaty o lukach, aktualizujemy serwery od razu, gdy pojawia się poprawka, i informujemy klientów, zanim zaczną się martwić. Sami też pracujemy z agentami AI, ale w odizolowanych środowiskach, bez dostępu do danych, a na produkcji nie robią nic bez nadzoru programisty. Więcej o tym piszę na stronie Przewaga AI.

Jeśli zapamiętasz z tego wpisu jedną rzecz, niech to będzie ta: w czasach AI liczy się to, jak szybko ktoś zareaguje za Ciebie.