# Czym jest PHP2Shell? Luka wyjaśniona prosto

> PHP2Shell prosto wyjaśnione: co kryje się za dwiema krytycznymi lukami w PHP, które serwery są dotknięte i jakie kroki należy teraz podjąć w firmie.

Źródło: https://phpsos.de/pl/php2shell/was-ist-php2shell/  
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:** PHP2Shell to nazwa dwóch krytycznych luk bezpieczeństwa w samym PHP, CVE-2026-109618 i CVE-2026-109619. Przez nie atakujący mogą na podatnych serwerach WWW wykonać złośliwy kod bez logowania. Pomoże tylko aktualizacja do naprawionej wersji PHP z następującym po niej restartem wszystkich procesów PHP.

## Czym jest PHP2Shell?

PHP to język programowania, na którym działa duża część wszystkich stron internetowych: strony firmowe z WordPressem lub TYPO3, sklepy internetowe z Shopware lub WooCommerce, portale wewnętrzne i rozwiązania własne. 21 października 2026 projekt PHP opublikował aktualizacje bezpieczeństwa dla dwóch luk, które stały się znane pod nazwą PHP2Shell.

Obie luki mają w skali CVSS v4.0 ocenę 9,2, czyli są krytyczne. Skutek w obu przypadkach jest ten sam: zdalne wykonanie złośliwego kodu bez konieczności logowania się atakującego. Specjaliści mówią o „unauthenticated Remote Code Execution”. Kto może wykonywać kod na serwerze, może w najgorszym razie odczytywać dane, instalować tylne furtki lub wykorzystywać serwer do dalszych ataków.

Ważne dla zrozumienia: luka nie tkwi w konkretnym CMS ani wtyczce, lecz w PHP. Aktualizacja WordPressa, Shopware lub TYPO3 jej więc nie zamyka.

## Dlaczego luka jest tak poważna?

Trzy punkty sprawiają, że PHP2Shell jest z punktu widzenia organów bezpieczeństwa szczególnie niebezpieczne:

- **Szeroki zasięg:** Dotknięte są powszechne tryby pracy PHP, czyli PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Palo Alto Networks (Unit 42) naliczyło ponad 22,6 miliona wystawionych na dostęp, potencjalnie podatnych instancji.
- **Logowanie niepotrzebne:** Atakujący nie potrzebuje ani hasła, ani konta użytkownika.
- **Wczesny moment:** W przypadku Apache z mod_php według zespołu PHP pokazano exploit, zanim w ogóle uruchomi się kod aplikacji. Funkcje ochronne wewnątrz strony nie działają wtedy.

BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji) ogłosił 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.

## Które serwery są dotknięte przez PHP2Shell?

Luki są naprawione w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Starsze stany tych gałęzi są dotknięte. Dla PHP 8.1 i starszego nie ma już oficjalnych aktualizacji; według prasy branżowej dotknięte są niemal wszystkie wersje aż do PHP 5.4. Pełne zestawienie znajdą Państwo na stronie [Które wersje PHP są podatne?](https://phpsos.de/pl/php2shell/betroffene-php-versionen/).

Osobliwość: dystrybucje Linuxa i dostawcy hostingu wprowadzają poprawki częściowo jako backport. Wtedy na przykład Plesk nadal pokazuje 8.2.34, choć błąd jest naprawiony. Miarodajne są stan pakietów i potwierdzenie dostawcy. Jak to sprawdzić, wyjaśniamy na stronie [Jak prawidłowo sprawdzić wersję PHP i stan poprawek](https://phpsos.de/pl/php2shell/php-version-pruefen/).

## Co jest udowodnione, a co otwarte?

**Udowodnione** są oba numery CVE, naprawione wersje i środki przejściowe opublikowane przez php.net. 23 października doszła wskazówka dotycząca kolejnej luki, CVE-2026-115560, która działa tylko przy nietypowej konfiguracji.

**Prawdopodobne** jest, że atakujący nadal aktywnie szukają niezałatanych serwerów. Według doniesień medialnych pierwszą próbę ataku zaobserwowano już 17 października, czyli przed publikacją poprawek. Cloudflare zgłosił próby ataków i wdrożył reguły ochronne, zwraca jednak uwagę, że same reguły oparte na danych żądania nie wystarczają.

**Otwarte** jest, ile serwerów zostało już skutecznie zaatakowanych. Według BSI potwierdzone, udane ataki na szeroką skalę początkowo nie były znane. Nie ma opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise). Czy serwer był dotknięty, można więc ocenić tylko przez analizę zachowania. Przebieg w czasie podsumowuje [chronologia od 17 do 25 października](https://phpsos.de/pl/ratgeber/php2shell-chronologie/).

## Co firmy powinny teraz zrobić

1. **Ustalić, kto odpowiada:** własny serwer, serwer zarządzany czy dostawca hostingu.
2. **Zaktualizować PHP** do naprawionej wersji lub potwierdzonego backportu.
3. **Zrestartować wszystkie procesy PHP.** Same nowe pliki nie wystarczą, dopóki stare procesy działają w pamięci.
4. **Zabezpieczyć logi,** i to od 20 października. Prasa branżowa radzi zachować te dane.
5. **Sprawdzić ślady.** Poprawka nie usuwa wprowadzonego już złośliwego oprogramowania i nie dowodzi, że wcześniej nic się nie stało. Wskazówki podaje strona [Czy już doszło do naruszenia?](https://phpsos.de/pl/php2shell/bin-ich-gehackt-anzeichen/).

> **Ważne:**
> Aktualizacja zamyka drzwi, ale nie sprząta. Jeśli Państwa serwer był dostępny między 17 października a poprawką, sprawdzenie pod kątem śladów jest obowiązkiem, a nie dodatkiem.

## Jak konkretnie pomaga PHP SOS?

Dzięki [natychmiastowej pomocy przy PHP2Shell](https://phpsos.de/pl/leistungen/php2shell-soforthilfe/) przejmujemy kroki, których wiele firm nie jest w stanie szybko pokryć wewnętrznie:

- **Inwentaryzacja:** Ustalamy wersję PHP, tryb pracy i stan pakietów każdego dotkniętego serwera.
- **Poprawka lub rozwiązanie przejściowe:** Instalujemy aktualizację lub, tam gdzie jeszcze się nie da, wdrażamy środki przejściowe z php.net i wyjaśniamy pytanie, czy serwer musi zostać czasowo odłączony od sieci.
- **Restart i dowód:** Restartujemy wszystkie procesy PHP i dokumentujemy stan przed i po.
- **Sprawdzenie śladów:** Zabezpieczamy logi od 20 października i sprawdzamy nieprawidłowości, aż incydent zostanie zamknięty i udokumentowany.


## Częste pytania

**Czy PHP2Shell to luka w WordPressie?**  
Nie. Luki tkwią w PHP, czyli w języku programowania, na którym działają WordPress, Shopware, TYPO3 i wiele innych systemów. Aktualizacja CMS ich więc nie zamyka. Decydujący jest stan PHP na serwerze.

**Czy jako klient dostawcy hostingu muszę coś zrobić sam?**  
Przy hostingu współdzielonym aktualizację PHP zwykle instaluje dostawca. Mimo to należy kazać sobie potwierdzić na piśmie, że używana przez Państwa wersja PHP została załatana i zrestartowana. Czy przed poprawką coś się wydarzyło, aktualizacja nie rozstrzyga.

**Skąd wzięła się nazwa PHP2Shell?**  
Nazwa opisuje skutek: przez PHP atakujący może w najgorszym razie uzyskać na serwerze wiersz poleceń, czyli powłokę (shell). Oficjalne oznaczenia to numery CVE-2026-109618 i CVE-2026-109619.

**Czy moja strona została już zaatakowana, jeśli została wyłączona?**  
Niekoniecznie. Niektórzy dostawcy z ostrożności odłączyli strony od sieci, tak jak zaleca BSI, gdy aktualizacja nie jest możliwa od razu. Jest to środek ochronny, a nie dowód ataku.

## Źródła

- [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Federalny Urząd ds. Bezpieczeństwa Informacji (Niemcy)](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)