# PHP2Shell: obraz sytuacji po pierwszym tygodniu

> PHP2Shell aktualnie: co jest udowodnione po tygodniu, jak sytuację oceniają BSI i zespoły CERT, co wiadomo o atakach i co operatorzy powinni teraz sprawdzić.

Źródło: https://phpsos.de/pl/blog/lagebild-erste-woche/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**Krótko:** Tydzień po pierwszej zaobserwowanej próbie ataku PHP2Shell jest aktualnie przede wszystkim kwestią wdrożenia: poprawki dla PHP od 8.2 do 8.5 są dostępne od 21 października, duże dystrybucje nadrobiły, a BSI ostrzega poziomem pomarańczowym. Zaobserwowano próby ataków, potwierdzonych udanych ataków na szeroką skalę BSI początkowo nie zgłosiło. Otwarte pozostają stare wersje, serwery bez restartu i pytanie, co działo się przed poprawką.

## Sytuacja w trzech zdaniach

PHP2Shell to dwie krytyczne luki w samym interpreterze PHP, CVE-2026-109618 i CVE-2026-109619, każda oceniona na 9,2 w skali CVSS v4.0. Umożliwiają one zdalne wykonanie kodu bez logowania, czyli przypadek, którego specjaliści od bezpieczeństwa obawiają się najbardziej. Dotknięte są PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed; największe ryzyko widzi zespół PHP przy mod_php.

To zestawienie porządkuje stan na 25 października 2026 według uczestników. Przebieg dzień po dniu znajdą Państwo w [chronologii PHP2Shell](https://phpsos.de/pl/ratgeber/php2shell-chronologie/), tu chodzi o obraz całości.

## Co jest udowodnione po tygodniu

Pewne są informacje projektu PHP: wydania 8.5.12, 8.4.27, 8.3.36 i 8.2.35 z 21 października zamykają obie luki. Dla PHP 7.4, 8.0 i 8.1 istnieją tylko minimalne backporty źródłowe, bez oficjalnych wydań. php.net podkreśla, że nie ma pełnych środków przejściowych, a aktualizacja jest jedyną bezpieczną drogą.

23 października doszła wskazówka dotycząca CVE-2026-115560. Dotyczy ona tylko nietypowej konfiguracji sesji; jako rozwiązanie php.net podaje `session.upload_progress.enabled=0` do następnego regularnego wydania z poprawkami błędów.

Także duże dystrybucje zajęły stanowisko. Sprawdziliśmy oficjalne komunikaty:

| Dostawca | Stan według oficjalnego komunikatu |
|---|---|
| Ubuntu | USN-8948-1 dla 22.04, 24.04, 26.04 i 26.10; USN-8948-2 dla 14.04 do 20.04 przez Ubuntu Pro |
| Debian | Poprawione pakiety dla bookworm (php8.2, DLA-4848-1) i trixie (php8.4, DSA-6574-1) |
| Red Hat | Biuletyn RHSB-2026-013 dla RHEL 7 do 10; niektóre aktualizacje dostępne, kolejne w przygotowaniu |

Red Hat klasyfikuje CVE-2026-109618 własną oceną jako „Important” i uzasadnia to wyższą złożonością ataku. To inna metoda oceny niż ta stosowana przez projekt PHP i nie jest powodem, by odkładać aktualizację.

## Jak urzędy oceniają sytuację

BSI ogłosiło poziom ostrzeżenia 3 / pomarańczowy. Zaleca natychmiastową aktualizację, a jeśli nie jest to możliwe od razu, czasowe odłączenie dotkniętych serwerów WWW od sieci. BSI spodziewało się szybkiego, szeroko zakrojonego wykorzystania. Co oznacza ta klasyfikacja, wyjaśnia strona [Co BSI zaleca w sprawie PHP2Shell](https://phpsos.de/pl/compliance/bsi-empfehlungen/).

Według doniesień CERT-EU uważa za możliwe, że dotknięte są wersje od PHP 5, i radzi izolować publicznie dostępne aplikacje, jeśli nie da się ich załatać w krótkim czasie. CERT-Bund (zespół reagowania na incydenty niemieckiej administracji federalnej) oraz firma zajmująca się bezpieczeństwem Huntress również ostrzegali.

Zalecenie, by w razie potrzeby wyłączać, zostało widocznie wdrożone. Według doniesień medialnych miasto Moguncja prewencyjnie odłączyło swój centralny portal internetowy od sieci; urzędy pozostały osiągalne telefonicznie i mailowo. W Hesji były według hessenschau czasowo offline strony rządu krajowego, BKA (niemieckiego Federalnego Urzędu Kryminalnego) oraz miast Kassel i Wiesbaden. Kancelaria premiera nie zgłosiła ataku, strony były wieczorem znów dostępne. Kolejne gminy, uczelnie i kliniki postąpiły według doniesień podobnie.

## Co wiadomo o atakach

Tu szczególnie ważne jest rozdzielenie obserwacji od potwierdzenia.

- **Zaobserwowane:** Według doniesień medialnych 17 października doszło do pierwszej próby ataku, którą zaobserwował Amazon. Cloudflare i Patchstack informowali o próbach ataków; Cloudflare widział ponadto zmienione wzorce ataków.
- **Odtworzone:** watchTowr odtworzył według doniesień CVE-2026-109618 według własnych informacji.
- **Niepotwierdzone:** BSI początkowo nie zgłosiło potwierdzonych udanych wykorzystań na szeroką skalę. Huntress w chwili swojego zgłoszenia nie widział ataków w środowiskach partnerów.
- **Nieznane:** Nie ma opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise). Kto chce sprawdzić, czy serwer został dotknięty, musi zwracać uwagę na wzorce zachowania.

O skali krążą dwie liczby. Badacze z Unit 42 w Palo Alto Networks doszli do ponad 22,6 miliona potencjalnie podatnych instancji osiągalnych z sieci. CybelAngel podaje około 2,24 miliona osiągalnych hostów PHP, z czego według własnej analizy 59 procent na wersjach bez nadchodzącej oficjalnej poprawki. Obie liczby mierzą różne rzeczy i nie są bezpośrednio porównywalne. Ocenę przedstawia artykuł [Jak właściwie ocenić liczby](https://phpsos.de/pl/blog/exponierte-instanzen-einordnen/).

## Co pozostaje otwarte

Trzy pytania określają najbliższe tygodnie:

1. **Stare wersje:** Duża część osiągalnych instalacji PHP działa według wspomnianych analiz na gałęziach bez oficjalnej poprawki. Czy komercyjne oferty długoterminowego wsparcia obejmują PHP2Shell, trzeba każdorazowo kazać potwierdzić dostawcy na piśmie.
2. **Niepełne aktualizacje:** Nowe pakiety działają dopiero po zrestartowaniu wszystkich procesów PHP. Red Hat wyraźnie wskazuje, że samo przeładowanie nie wystarcza.
3. **Czas przed poprawką:** Między 17 a 21 października serwery były podatne, podczas gdy trwały już próby ataków. Poprawka nie dowodzi, że w tym czasie nic się nie wydarzyło.

> **Ważne:**
> Proszę przechowywać logi serwera WWW i PHP od 20 października, jak zaleca prasa branżowa. Bez logów najważniejszego otwartego pytania dla Państwa serwera nie da się później rozstrzygnąć.

## Co operatorzy powinni teraz sprawdzić

Do własnej oceny sytuacji wystarczą cztery punkty kontrolne dla każdego serwera: Czy PHP jest w naprawionym stanie lub z potwierdzonym backportem? Czy wszystkie procesy działają od czasu aktualizacji? Czy `session.upload_progress.enabled` jest wyłączone po stronie serwera, dopóki nie ukaże się advisory do CVE-2026-115560? Czy od 17 października są jakieś nieprawidłowości?

Przy ostatnim punkcie pomaga strona [Czy już doszło do naruszenia?](https://phpsos.de/pl/php2shell/bin-ich-gehackt-anzeichen/). Proces serwera WWW uruchamiający powłokę, nowe pliki PHP w katalogach przesyłania, nieznane zadania cron lub klucze SSH to sygnały ostrzegawcze, które uzasadniają dokładniejsze badanie.

## Jak konkretnie pomaga PHP SOS?

- Oceniamy stan poprawek każdego serwera na podstawie stanu pakietów, changelogu i czasów startu procesów.
- Tam, gdzie poprawka nie jest dostępna, wdrażamy środki przejściowe z php.net i wyjaśniamy drogę do wspieranej wersji.
- Zabezpieczamy logi od 20 października i szukamy śladów z czasu przed poprawką.
- Dzięki [natychmiastowej pomocy przy PHP2Shell](https://phpsos.de/pl/leistungen/php2shell-soforthilfe/) łączymy te kroki dla firm, które potrzebują szybkiej jasności.


## Częste pytania

**Czy PHP2Shell jest już aktywnie wykorzystywane?**  
Cloudflare i Patchstack informowali o próbach ataków. Potwierdzonych udanych ataków na szeroką skalę BSI początkowo nie zgłosiło. Huntress w chwili swojego zgłoszenia nie widział ataków w środowiskach partnerów.

**Czy po poprawkach zagrożenie minęło?**  
Nie. Poprawki chronią tylko serwery, które je zainstalowały i zrestartowały wszystkie procesy PHP. Systemy z PHP 8.1 i starszym pozostają bez potwierdzonego backportu podatne, a poprawka nie usuwa wcześniej wprowadzonego złośliwego oprogramowania.

**Dlaczego strony urzędów były offline?**  
Według doniesień medialnych między innymi miasto Moguncja i kilka instytucji w Hesji prewencyjnie wyłączyło swoje strony. Odpowiada to zaleceniu BSI (niemieckiego Federalnego Urzędu ds. Bezpieczeństwa w Technice Informatycznej) dla serwerów, których nie da się od razu zaktualizować. Wyłączenie nie oznacza, że doszło do ataku.

**Czy istnieją cechy rozpoznawcze ataku PHP2Shell?**  
Opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise) dotąd nie ma. Wykrywanie opiera się na analizie zachowania, na przykład procesów PHP uruchamiających powłokę lub nowych plików PHP w katalogach przesyłania.

## Źródła

- [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)
- [BSI](https://www.bsi.bund.de/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [hessenschau: Behörden-Webseiten in Hessen abgeschaltet](https://www.hessenschau.de/panorama/sicherheitsluecke-zahlreiche-behoerden-webseiten-in-hessen-abgeschaltet-v2,sicherheitsprobleme-hacker-webseiten-100.html)
- [Ubuntu Security Notice USN-8948-1](https://ubuntu.com/security/notices/USN-8948-1)