# Luki PHP php2shell: co muszą wiedzieć serwisy wideo

**Source:** https://vodlix.com/pl/blog/php2shell-php-vulnerability-october-2026  
**Summary:** php2shell dla biznesu wideo: dwie luki w PHP usunięte 21 października 2026 r., które wersje zainstalować i jak Vodlix zadbał o bezpieczeństwo swoich klientów.  
**Published:** 2026-11-02  
**Publisher:** Vodlix

---

## Key takeaways

21 października 2026 r. PHP wydało wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35, aby usunąć php2shell, dwie krytyczne luki, które mogą pozwolić nieuwierzytelnionemu atakującemu uruchomić kod na serwerze PHP. Vodlix załatał systemy, zanim luki stały się publiczne, a jego klienci nie musieli nic robić.

- Jeśli jakakolwiek część Twojego biznesu wideo działa na PHP na własnych serwerach lub hostingu, zaktualizuj ją teraz do poprawionej wersji albo poproś o to swój hosting.
- PHP 8.1 i starsze nie są już wspierane, więc te serwisy potrzebują upgrade'u, a nie tylko łatki.
- Przeczytaj komunikaty swojego hostingu i dostawców: AWS opublikował biuletyn 2026-143-AWS 21 października 2026 r.
- Na zarządzanej platformie dostawca wdraża takie aktualizacje za Ciebie; w Vodlix tylko middleware używa PHP i zostało załatane.

21 października 2026 r. projekt PHP wydał PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Wydania te usuwają dwie krytyczne luki, CVE-2026-109618 i CVE-2026-109619, znane łącznie jako php2shell. W odpowiednich warunkach pozwalają one nieuwierzytelnionemu atakującemu uruchomić kod na serwerze z PHP. [PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) ujmuje to wprost: jeśli używasz PHP, aktualizuj teraz.

Vodlix załatał swoje systemy, zanim luki zostały upublicznione. Klienci Vodlix nie musieli nic robić.

Łatka nikogo nie chroni, dopóki nie znajdzie się na Twoim serwerze. Dla biznesu wideo to właśnie sedno php2shell.

## Czym jest php2shell? {#czym-jest-php2shell}

php2shell to nazwa dwóch powiązanych luk zdalnego wykonania kodu w PHP, CVE-2026-109618 i CVE-2026-109619. Obie tkwią w zarządzaniu pamięcią i obsłudze błędów, czyli w częściach PHP, przez które przechodzi niemal każde żądanie. Komunikaty bezpieczeństwa projektu PHP oceniają je jako krytyczne, a poprawione wersje ukazały się 21 października 2026 r.

PHP Foundation i komunikaty projektu PHP odwołują się do luk za pomocą numerów CVE, więc używaj ich, przeszukując komunikaty swoich dostawców i firm hostingowych.

### CVE-2026-109618: uszkodzenie pamięci, gdy PHP wyczerpuje pamięć {#cve-2026-109618-uszkodzenie-pamięci-gdy-php-wyczerpuje-pamięć}

Jeśli żądanie osiągnęło memory\_limit PHP dokładnie w niewłaściwym momencie, PHP mogło pozostawić częściowo zainicjalizowane dane wewnętrzne i później traktować je jako poprawne. Na Apache z mod\_php nieuwierzytelnione żądanie może to wywołać, zanim uruchomi się jakikolwiek kod aplikacji, a PHP Foundation podaje, że pełne zdalne wykonanie kodu wykazano przy ustawieniach domyślnych. Zdalne wykonanie kodu potwierdzono także na PHP-FPM poprzez ścieżki kodu aplikacji.

### CVE-2026-109619: nieaktualny stan pozostały po wcześniejszym żądaniu {#cve-2026-109619-nieaktualny-stan-pozostały-po-wcześniejszym-żądaniu}

Błąd krytyczny w niewłaściwym momencie mógł pozostawić stan wewnętrzny wskazujący na pamięć należącą do poprzedniego żądania. Kolejne żądanie na tym samym workerze mogło wtedy skorzystać z tej zwolnionej pamięci. Według PHP Foundation zgłaszający wykazał zdalne wykonanie kodu na rzeczywistej aplikacji działającej na Apache z mod\_php.

## Które wersje PHP usuwają lukę php2shell? {#które-wersje-php-usuwają-lukę-php2shell}

Poprawione wersje to PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, wszystkie wydane 21 października 2026 r. Według [komunikatu projektu PHP dotyczącego CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) podatne jest każde wcześniejsze wydanie w tych czterech gałęziach. Jeśli używasz PHP 8.1 lub starszego, dla Twojej gałęzi nie ma łatki.

| Twoja gałąź PHP | Podatne | Zaktualizuj do |
| --- | --- | --- |
| 8.5 | Poniżej 8.5.12 | 8.5.12 |
| 8.4 | Poniżej 8.4.27 | 8.4.27 |
| 8.3 | Poniżej 8.3.36 | 8.3.36 |
| 8.2 | Poniżej 8.2.35 | 8.2.35 |
| 8.1 i starsze | Brak wsparcia | Wspierana gałąź, np. 8.5.12 |

[TechCrunch](https://techcrunch.com/2026/10/21/php-armageddon-openai-googles-wiz-find-ancient-holes-panicking-the-internet/) donosi, że luki istniały w każdej wersji PHP od PHP 5 wydanego w 2004 r., a PHP 8.1 i starsze nie są już wspierane. Serwisy na tych wersjach mają przed sobą więcej pracy niż drobna aktualizacja.

## Kto i kiedy odkrył luki? {#kto-i-kiedy-odkrył-luki}

Badacz Ryan A z firmy bezpieczeństwa Calif zgłosił PHP pierwsze zdalne wykonanie kodu 11 sierpnia 2026 r., podczas audytu rozpoczętego 30 lipca 2026 r. Następnie Wiz i OpenAI zgłosiły kolejne ścieżki ataku. Pierwotna przyczyna sięga problemu z pamięcią, który zespół PHP po raz pierwszy zauważył w 2024 r.

Własna relacja PHP Foundation przedstawia kolejność zdarzeń:

1. **2024:** podczas pierwszego od lat zewnętrznego audytu bezpieczeństwa PHP jeden z głównych deweloperów znalazł pierwsze oznaki problemu z wyczerpaniem pamięci. Nie znaleziono wtedy konkretnej ścieżki ataku, a poprawka utknęła.
2. **30 lipca 2026:** Calif rozpoczął audyt PHP w ramach programu Patch the Planet.
3. **11 sierpnia 2026:** Ryan A z Calif zgłosił bezwarunkowe zdalne wykonanie kodu o tej samej pierwotnej przyczynie. OpenAI niezależnie zgłosiło tę samą przyczynę.
4. **24 sierpnia 2026:** Wiz zgłosił kolejne wektory ataku.
5. **18 września 2026:** OpenAI zgłosiło kolejne wektory ataku.
6. **21 października 2026:** PHP wydało poprawione wersje.

Foundation mówi o tej luce czasowej otwarcie: opóźnienie po 2024 r. nazywa „strukturalną porażką” procesu decyzyjnego zespołu bezpieczeństwa i braku zasobów, a także zapowiada, że zespół zmienia sposób pracy.

## Jak poważny jest php2shell i jak zareagował internet? {#jak-poważny-jest-php2shell-i-jak-zareagował-internet}

Jest poważny, bo PHP jest wszędzie, a najgorszy scenariusz to atakujący uruchamiający kod na Twoim serwerze. TechCrunch donosi, że PHP napędza około 70% stron internetowych, a amerykańska Agencja Bezpieczeństwa Narodowego zaleciła wyłączenie serwisu, jeśli nie można go od razu załatać.

TechCrunch donosi również, że luki mogą dać atakującym dostęp do systemu plików serwera lub bazy danych używanej przez aplikację webową. W chwili publikacji artykułu 21 października OpenAI podało, że luki zostały odkryte przez badaczy przed atakującymi i nie było doniesień o ich wykorzystaniu. Ujawnienie to zmienia, bo szczegóły są teraz publiczne.

Dostawcy chmury zareagowali tego samego dnia. [AWS opublikował biuletyn bezpieczeństwa 2026-143-AWS](https://aws.amazon.com/security/security-bulletins/2026-143-aws/) 21 października 2026 r., oznaczony jako „Important (requires attention)”, dla środowisk uruchomieniowych PHP dotkniętych obiema lukami CVE.

## Co php2shell oznacza dla platformy streamingowej lub serwisu wideo? {#co-php2shell-oznacza-dla-platformy-streamingowej-lub-serwisu-wideo}

Oznacza sprawdzenie każdej części Twojego biznesu wideo, która działa na PHP, nie tylko odtwarzacza. Serwis streamingowy to sklep, logowanie, ścieżka płatności i często także strona marketingowa lub blog. Jeśli którykolwiek z tych elementów działa na PHP na serwerze zarządzanym przez Ciebie lub Twój hosting, potrzebuje poprawionej wersji.

Bezpieczeństwo nie jest tu wyłącznie zadaniem IT. To kwestia biznesowa. Serwis wideo, który zostaje wyłączony w oczekiwaniu na łatkę, przez cały czas przestoju nie sprzedaje subskrypcji ani wypożyczeń.

WordPress to częsty przypadek. TechCrunch donosi, że WordPress oświadczył, iż luka nie jest specyficzna dla WordPressa, a serwisy na nim oparte muszą załatać swoje serwery i współpracować z firmami hostingowymi.

Łatanie to jedna warstwa ochrony. Nasz przewodnik po [podstawach bezpieczeństwa OTT dla Twoich treści i widzów](https://vodlix.com/pl/blog/ott-security-essentials-safeguarding-your-content-and-viewers) omawia pozostałe, a nasza strona o [bezpieczeństwie logowania na platformach streamingowych](https://vodlix.com/pl/features/login-security) dotyczy kont widzów.

## Jak Vodlix poradził sobie z php2shell? {#jak-vodlix-poradził-sobie-z-php2shell}

Vodlix załatał swoje systemy przeciwko CVE-2026-109618 i CVE-2026-109619, zanim luki zostały upublicznione 21 października 2026 r. W Vodlix tylko middleware używa PHP i to właśnie ono zostało załatane. Klienci Vodlix nie musieli podejmować żadnych działań.

Na zarządzanej platformie takiej jak Vodlix aktualizacje bezpieczeństwa, takie jak ta, są wdrażane za Ciebie. Jeśli chcesz zgłosić problem bezpieczeństwa dotyczący Vodlix, napisz na security@vodlix.com.

## Co zrobić, jeśli prowadzisz własne serwisy PHP? {#co-zrobić-jeśli-prowadzisz-własne-serwisy-php}

Zaktualizuj każdą instalację PHP, którą prowadzisz, do poprawionej wersji lub poproś o to swój hosting, i przeczytaj komunikaty swoich dostawców. Jeśli nie możesz zaktualizować od razu, zastosuj się do zaleceń NSA, o których pisze TechCrunch, i wyłącz serwis, dopóki nie będzie to możliwe.

1. **Spisz wszystko, co działa na PHP.** Uwzględnij stronę główną, każdą stronę lub blog na WordPressie, landing page'e i narzędzia administracyjne.
2. **Sprawdź każdą wersję.** Porównaj ją z powyższą tabelą.
3. **Zaktualizuj lub poproś swój hosting.** Przejdź na 8.5.12, 8.4.27, 8.3.36 lub 8.2.35. W przypadku hostingu zarządzanego poproś o potwierdzenie daty aktualizacji.
4. **Zaplanuj upgrade starych gałęzi.** PHP 8.1 i starsze nie są już wspierane, więc łatka dla nich nie powstanie.
5. **Przeczytaj komunikaty swoich dostawców.** Zacznij od hostingu i dostawcy chmury. AWS już opublikował swój.
6. **Potwierdź, że nowa wersja działa.** Sprawdź ponownie po aktualizacji, na każdym serwerze.

## Co dalej {#co-dalej}

Jeśli jesteś klientem Vodlix, nie musisz nic robić w związku z php2shell. W razie pytań odwiedź [centrum pomocy Vodlix](https://vodlix.com/pl/help) lub [skontaktuj się z zespołem Vodlix](https://vodlix.com/pl/contact).

Jeśli rozważasz zarządzaną platformę, na której takie aktualizacje są wykonywane za Ciebie, zobacz [funkcje platformy Vodlix](https://vodlix.com/pl/features) lub [poproś o demo Vodlix](https://vodlix.com/pl/demo).

## Najczęściej zadawane pytania

**Q: Czym jest php2shell?**

php2shell to potoczna nazwa dwóch krytycznych luk w PHP, CVE-2026-109618 i CVE-2026-109619. Oficjalne komunikaty, na przykład PHP Foundation, używają numerów CVE. Obie to luki w zarządzaniu pamięcią i obsłudze błędów PHP, które w odpowiednich warunkach pozwalają nieuwierzytelnionemu atakującemu uruchomić kod na serwerze. PHP usunęło je 21 października 2026 r.

**Q: Które wersje PHP usuwają CVE-2026-109618 i CVE-2026-109619?**

PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35 usuwają obie luki. Zostały wydane 21 października 2026 r. Każde wcześniejsze wydanie w gałęziach 8.5, 8.4, 8.3 i 8.2 jest podatne. PHP 8.1 i starsze nie są już wspierane, więc serwisy na tych wersjach muszą przejść na wspieraną gałąź.

**Q: Czy klienci Vodlix muszą coś zrobić w związku z php2shell?**

Nie. W Vodlix tylko middleware używa PHP, a Vodlix załatał je, zanim luki zostały upublicznione 21 października 2026 r. Klienci nie musieli podejmować żadnych działań. Jeśli chcesz zgłosić problem bezpieczeństwa dotyczący Vodlix, możesz napisać na security@vodlix.com.

**Q: Czy WordPress jest dotknięty luką w PHP z października 2026?**

WordPress działa na PHP, więc serwisy WordPress są narażone poprzez wersję PHP na serwerze. TechCrunch donosi, że WordPress oświadczył, iż luka nie jest specyficzna dla WordPressa, a serwisy na nim oparte muszą załatać swoje serwery i współpracować z firmami hostingowymi. Aktualizacja samego WordPressa nie zastępuje aktualizacji PHP.

**Q: Czy php2shell był wykorzystywany przed wydaniem poprawki?**

TechCrunch podał 21 października 2026 r., że według OpenAI luki zostały odkryte przez badaczy przed atakującymi i w tamtym momencie nie było doniesień o ich wykorzystaniu. Teraz, gdy szczegóły są publiczne, niezaktualizowane serwery są bardziej zagrożone, dlatego NSA zaleciła wyłączenie serwisów, których nie da się załatać.

**Q: Co zrobić, jeśli nie mogę od razu zaktualizować PHP?**

TechCrunch donosi, że amerykańska Agencja Bezpieczeństwa Narodowego zaleciła, aby stronę, której nie można natychmiast załatać, wyłączyć do czasu, aż będzie to możliwe. Zapytaj swój hosting, kiedy wdroży PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35, i przeczytaj jego komunikat oraz komunikat swojego dostawcy chmury, na przykład biuletyn AWS 2026-143-AWS.