# CVE-2026-109619: RCE przez przestarzały stan globalny

> CVE-2026-109619 zrozumiale: dlaczego stan wewnętrzny między żądaniami staje się groźny, które wersje PHP są naprawione i jak się zabezpieczyć.

Źródło: https://phpsos.de/pl/php2shell/cve-2026-109619/  
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:** CVE-2026-109619 to druga luka kryjąca się za PHP2Shell. Stan wewnętrzny należący do żądania może pozostać po zwolnieniu pamięci; późniejsze żądanie w tym samym workerze może go wykorzystać, zanim zostanie zresetowany. Skutkiem jest wykonanie kodu bez logowania. Środek zaradczy: aktualizacja do PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 i restart wszystkich workerów.

## Czym jest CVE-2026-109619?

CVE-2026-109619 (identyfikator GitHub GHSA-6wmf-4rv5-p3rp) ma ocenę CVSS v4.0 9,2. Wraz z [CVE-2026-109618](https://phpsos.de/pl/php2shell/cve-2026-109618/) tworzy PHP2Shell. Obie luki tkwią w samym PHP, a nie w aplikacji.

Skutek jest taki sam jak przy siostrzanej luce: atakujący może zdalnie, bez hasła i bez konta użytkownika, wykonać kod na serwerze. Przyczyna jest jednak inna.

## Dlaczego przestarzały stan w workerze jest groźny

Serwer WWW z PHP nie uruchamia nowego procesu dla każdego żądania. W PHP-FPM, Apache z mod_php, LiteSpeed lub FrankenPHP jeden worker obsługuje kolejno wiele żądań. Między dwoma żądaniami PHP resetuje swój stan wewnętrzny, aby nic z żądania A nie trafiło do żądania B.

W przypadku CVE-2026-109619 to resetowanie nie udaje się w pełni. Według php.net należący do żądania stan wewnętrzny może pozostać po zwolnieniu pamięci. Późniejsze żądanie w tym samym workerze może wykorzystać ten przestarzały stan, zanim zostanie zresetowany. Upraszczając: coś jest nadal używane, co właściwie już nie jest ważne.

Z punktu widzenia eksploatacji jest to godne uwagi. Ponowne wykorzystanie workerów jest zamierzone, ponieważ przyspiesza serwery WWW: worker nie musi przy każdym żądaniu startować od nowa, ładować rozszerzeń i alokować pamięci. Luka trafia więc w cechę, którą ma praktycznie każda produkcyjna instalacja PHP. php.net nie podaje konfiguracji, która całkowicie omija problem; dlatego droga prowadzi przez aktualizację.

Szczegółów wykorzystania nie publikujemy. Dla operatorów liczy się to, że należy mieć na oku każdy tryb pracy, w którym worker obsługuje kilka żądań, a właśnie takie tryby są zwykłe.

## Obie luki PHP2Shell w porównaniu

| Cecha | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Identyfikator GitHub | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Ocena | CVSS v4.0 9,2 | CVSS v4.0 9,2 |
| Wyzwalacz | Out-of-memory podczas inicjalizacji danych żądania | Stan wewnętrzny pozostaje po zwolnieniu |
| Skutek | Wykonanie kodu bez logowania | Wykonanie kodu bez logowania |
| Naprawione w | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |

Dotknięte są PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Najwyższe ryzyko widzi zespół PHP przy mod_php; dlaczego, wyjaśniamy na stronie [Dlaczego mod_php niesie najwyższe ryzyko](https://phpsos.de/pl/php2shell/mod-php-risiko/).

## Zamknięcie CVE-2026-109619: aktualizacja, potem restart wszystkich workerów

Szczególnie przy tej luce restart jest decydujący. Dopóki stare workery działają w pamięci, serwer nadal pracuje z błędnym kodem, nawet jeśli nowe pliki dawno leżą na dysku.

Proszę sprawdzić wersję i stan pakietów. Nazwy pakietów różnią się zależnie od dystrybucji i interfejsu dostawcy hostingu:

```bash
php -v
php-fpm8.3 -v                  # binarka FPM może mieć inną wersję niż CLI
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # rodzina RHEL
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
```

Następnie zrestartować wszystkie dotknięte usługi:

```bash
sudo systemctl restart php8.3-fpm     # zależnie od zainstalowanej wersji PHP
sudo systemctl restart apache2        # przy mod_php; w RHEL usługa nazywa się httpd
```

Jeśli Państwa dystrybucja lub dostawca hostingu wprowadza backport, wyświetlany numer wersji może pozostać taki sam. Wtedy liczą się changelog pakietu i pisemne potwierdzenie dostawcy. Sprawdzenie krok po kroku znajdą Państwo na stronie [Restart PHP-FPM i wszystkich workerów](https://phpsos.de/pl/php2shell/php-fpm-neustart/).

> **Wskazówka:**
> Proszę zanotować datę i godzinę restartu. Dla późniejszej oceny, czy atak nastąpił przed czy po poprawce, ten moment jest najważniejszym punktem odniesienia.

## Co po poprawce nadal pozostaje do zrobienia

Poprawka nie dowodzi, że wcześniej nic się nie stało. Według doniesień medialnych pierwszą próbę ataku zaobserwowano 17 października, cztery dni przed poprawkami. Proszę zachować logi serwera od 20 października, jak zaleca prasa branżowa, i sprawdzić serwer pod kątem nieprawidłowości. Wskazówki podaje strona [Czy już doszło do naruszenia?](https://phpsos.de/pl/php2shell/bin-ich-gehackt-anzeichen/).

Proszę przy tym pamiętać o zasięgu: przy skutecznym wykonaniu kodu atakujący ma uprawnienia procesu PHP. Może czytać to, co aplikacja może czytać, na przykład pliki konfiguracyjne z dostępami do bazy danych lub klucze API. Jeśli incydent się potwierdzi, dane dostępowe te należy po oczyszczeniu odnowić.

## Jak konkretnie pomaga PHP SOS?

Dzięki [usłudze łatania PHP](https://phpsos.de/pl/leistungen/php-patch-service/) wdrażamy poprawkę w sposób możliwy do prześledzenia:

- **Rejestracja:** Jakie wersje PHP i tryby pracy działają na którym serwerze i jakie źródło pakietów je dostarcza?
- **Łatanie:** Aktualizacja z właściwego źródła lub środki przejściowe wg php.net, gdzie aktualizacja jest jeszcze zablokowana.
- **Kontrola restartu:** Sprawdzamy proces po procesie, że działa już tylko naprawiona wersja.
- **Dokumentacja:** Wersje, stany pakietów i czasy restartów, abyście Państwo mogli udowodnić stan.


## Częste pytania

**Czym różni się CVE-2026-109619 od CVE-2026-109618?**  
CVE-2026-109618 powstaje, gdy stan out-of-memory przerywa żądanie w trakcie inicjalizacji. CVE-2026-109619 dotyczy stanu, który po zakończeniu żądania pozostaje w workerze. Obie prowadzą do wykonania kodu bez logowania i są naprawione w tych samych wersjach PHP.

**Czy pomaga częstsze restartowanie workerów PHP-FPM?**  
Nie nadaje się to jako zamiennik aktualizacji. php.net nie podaje częstszych restartów workerów jako środka przejściowego. Zrestartować workery trzeba jednak po aktualizacji, aby naprawiona wersja w ogóle działała.

**Czy jestem chroniony przed CVE-2026-109619 przez aktualizację CMS?**  
Nie. Luka leży w PHP, a nie w WordPressie, Shopware, TYPO3 ani innym systemie. Zamyka ją tylko aktualizacja PHP lub potwierdzony backport dostawcy.

**Czy są znane ślady ataku przez CVE-2026-109619?**  
Potwierdzone wskaźniki naruszenia (Indicators of Compromise) nie zostały dotąd opublikowane. Wykrywanie opiera się na analizie zachowania, na przykład nowych plikach PHP, nietypowych połączeniach wychodzących lub nieznanych zadaniach cron.

## Ź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/)