# php-cgi: stare obciążenie z ryzykiem

> Luka bezpieczeństwa php-cgi (PHP2Shell): znajdź konfiguracje CGI i FastCGI, załataj je, zakończ wszystkie stare procesy i zaplanuj przejście na PHP-FPM.

Źródło: https://phpsos.de/pl/server/php-cgi/  
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:** php-cgi to najstarszy sposób uruchamiania PHP za serwerem WWW i nadal działa na wielu serwerach, często niezauważone. Luka bezpieczeństwa php-cgi z PHP2Shell dotyczy tego trybu pracy wprost. Proszę załatać, zakończyć wszystkie działające procesy php-cgi i zaplanować przejście na PHP-FPM.

## Czym jest php-cgi i gdzie nadal działa

PHP występuje w kilku wariantach: jako program wiersza poleceń, jako moduł Apache, jako PHP-FPM i jako php-cgi. php-cgi to program, który uruchamia serwer WWW i któremu przekazuje żądania przez CGI lub FastCGI. Bez własnego zarządzania procesami jest prostszy niż PHP-FPM, ale też trudniejszy do kontrolowania.

Typowe miejsca to starsze panele hostingowe, Apache z `mod_fcgid`, własne skrypty opakowujące (wrappery) dla kilku wersji PHP oraz PHP w Windows z IIS przez FastCGI. W agencjach i urzędach spotyka się ponadto serwery skonfigurowane przed laty i od tamtej pory tylko eksploatowane.

## Luka bezpieczeństwa php-cgi w PHP2Shell

PHP2Shell obejmuje luki CVE-2026-109618 i CVE-2026-109619 w samym PHP, każdą z oceną CVSS v4.0 9.2. Obie umożliwiają wykonanie szkodliwego kodu bez logowania. Projekt PHP wprost wymienia php-cgi wśród dotkniętych trybów pracy, obok PHP-FPM, mod_php, FrankenPHP i LiteSpeed.

Usunięte są PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dla PHP 8.1 i starszych nie ma już oficjalnych aktualizacji, tylko minimalne backporty źródeł dla 7.4, 8.0 i 8.1. Właśnie konfiguracje php-cgi działają ponadprzeciętnie często na starych wersjach. php-cgi nie jest przy tym dotknięte po raz pierwszy: już w 2024 roku luka w php-cgi w Windows (CVE-2024-4577) wzbudziła duże zainteresowanie. Takie stare obciążenia zasługują więc na szczególną uwagę.

## Znalezienie php-cgi na serwerze

Poniższe polecenia tylko odczytują i pomagają wytropić php-cgi. Ścieżki i nazwy modułów to przykłady.

```bash
# Działające procesy php-cgi z czasem startu i użytkownikiem
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep

# Zainstalowane programy php-cgi
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null

# Apache: czy załadowany jest mod_fcgid lub mod_cgi?
apache2ctl -M 2>/dev/null | grep -Ei 'fcgid|cgi'
grep -RniE 'FcgidWrapper|AddHandler.*php|Action.*php' /etc/apache2 /etc/httpd 2>/dev/null
```

Jeśli znajdą Państwo wpisy `FcgidWrapper` lub handlery wskazujące na program php-cgi, ten tryb pracy jest używany. Dla każdego znalezionego programu proszę sprawdzić wersję przez `-v`. W pakietach dystrybucji poprawkę potwierdza dziennik zmian z numerami CVE, ponieważ backporty często nie zmieniają numeru wersji.

## Łatanie i kończenie wszystkich procesów

Proszę zainstalować aktualizację przez menedżer pakietów lub źródło, z którego pochodzi php-cgi. Potem wszystkie działające procesy php-cgi muszą zniknąć. W `mod_fcgid` Apache przez jakiś czas utrzymuje procesy w gotowości; pełny restart Apache je kończy.

```bash
# Pełny restart Apache (Debian/Ubuntu lub rodzina RHEL)
systemctl restart apache2   # lub: systemctl restart httpd

# Kontrola: czy są jeszcze procesy php-cgi starsze niż aktualizacja?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep
```

Jeśli php-cgi działa przez własnego menedżera procesów lub usługę panelu, proszę zrestartować ją. W Windows z IIS proszę zrecyklować pule aplikacji, zob. [PHP w Windows i IIS](https://phpsos.de/pl/server/windows-iis-php/).

> **Działać natychmiast:**
> Jeśli php-cgi działa z PHP 8.1 lub starszym na serwerze osiągalnym publicznie, oficjalnej poprawki brak. Proszę natychmiast ustawić środki przejściowe i rozważyć, zgodnie z zaleceniem BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej), czasowe odłączenie serwera od sieci.

## Środki przejściowe przy php-cgi

php.net zaleca środki przejściowe, które nie dają pełnej ochrony. W php-cgi wartości należą do pliku php.ini, który ładuje dany program, lub do konfiguracji serwera. Pliki `.user.ini` i `ini_set()` według php.net nie wystarczają dla `session.upload_progress.enabled`.

```ini
; php.ini instalacji php-cgi
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
```

Przy funkcji uploadu php.net podaje `post_max_size = 32M`. W PHP 8.5 dochodzi `fatal_error_backtraces=0`. Limity pamięci proszę ustawiać przez cgroups dla usługi serwera WWW, a nie przez `RLIMIT_AS` czy `RLIMIT_DATA`. Potem zrestartować wszystkie procesy.

## Droga do PHP-FPM

Na dłuższą metę php-cgi nie jest dobrym wyborem. PHP-FPM oferuje pule dla każdej strony, osobnych użytkowników, limity dla każdej puli, strony statusu i kontrolowane restarty. Przejście jest zwykle dobrze planowalne: zainstalować PHP-FPM, utworzyć pule, przełączyć serwer WWW na FastCGI do PHP-FPM, usunąć skrypty opakowujące. Jak wygląda poprawna konfiguracja, pokazuje artykuł [Zabezpieczenie Nginx z PHP-FPM](https://phpsos.de/pl/server/nginx-php-fpm/). Jeśli dodatkowo działa stara wersja PHP, proszę połączyć zmianę z aktualizacją wersji.

Do czasu przejścia proszę krytycznie sprawdzić istniejącą konfigurację. Serwer WWW powinien przekazywać do php-cgi tylko pliki z rozszerzeniem `.php`, a nie ścieżki wskazujące na nieistniejące pliki. W katalogach uploadu wykonywanie PHP nie może być możliwe. W skryptach opakowujących, które dla każdej strony ładują własny php.ini, proszę sprawdzić, czy te pliki nie znoszą wartości przejściowych. Jeśli program php-cgi leży bezpośrednio w publicznie dostępnym katalogu takim jak `cgi-bin`, należy go stamtąd usunąć. Takie stare obciążenia pochodzą często z instrukcji instalacji z minionych lat i przy późniejszych przebudowach po prostu się je zapomina. Proszę udokumentować każde znalezisko ze ścieżką i przeznaczeniem, aby późniejsza przebudowa niczego nie pominęła.

Pozostaje ważne: poprawka nie usuwa szkodliwego oprogramowania wprowadzonego wcześniej. Proszę zachować logi od 20.10.2026.

## Jak konkretnie pomaga PHP SOS?

- Wytropimy instalacje php-cgi, wrappery i handlery i przypiszemy je do stron.
- Łatamy, kończymy wszystkie stare procesy i dokumentujemy stan.
- Dla PHP 8.1 i starszych planujemy z Państwem [migrację na obsługiwaną wersję PHP](https://phpsos.de/pl/leistungen/php-migration-legacy/).
- W ramach [utwardzania serwerów](https://phpsos.de/pl/leistungen/server-haertung/) zastępujemy php-cgi przez PHP-FPM z oddzielnymi pulami.


## Częste pytania

**Czy używam php-cgi, nie wiedząc o tym?**  
To częstsze, niż się sądzi. Starsze panele, konfiguracje FastCGI z mod_fcgid i PHP w Windows z IIS często uruchamiają PHP jako php-cgi. Lista procesów lub Server API w phpinfo pokazuje to wiarygodnie.

**Czy FastCGI to to samo co php-cgi?**  
Nie do końca. FastCGI to protokół. Zarówno PHP-FPM, jak i php-cgi potrafią komunikować się przez FastCGI, ale php-cgi to starszy, prostszy program bez pul i zarządzania procesami. PHP2Shell dotyczy php-cgi wprost.

**Co oznacza klasyczne CGI w PHP?**  
W klasycznym CGI serwer WWW uruchamia dla każdego żądania nowy proces PHP. Jest to wolne i dziś rzadkie. Częściej spotyka się php-cgi za mod_fcgid lub FastCGI, gdzie procesy obsługują wiele żądań.

**Czy po aktualizacji muszę coś zrestartować?**  
Tak. W konfiguracjach FastCGI procesy php-cgi działają jeszcze przez pewien czas. Proszę zrestartować serwer WWW lub menedżera procesów i sprawdzić, że żaden proces php-cgi nie jest starszy niż aktualizacja.

## Źródła

- [php.net: komunikaty bezpieczeństwa](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: obsługiwane wersje](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)