Wykryte przez AI podatności w PHP oznaczono kodem: CVE-2026-109618 i CVE-2026-109619. Dwie krytyczne podatności w samym silniku PHP, które zostały ocenione przez twórców na 9,2 w 10-stopniowej skali (to bardzo wysoki poziom zagrożenia). Media dziś (22.10.2026) szeroko rozpisywały się na ten temat. Rządy niektórych krajów postanowiły wyłączyć część najbardziej narażonych stron. Stało się tak min. w Niemczech, Finlandii i w Polsce. Oczywiście sporo mediów wykorzystało to do typowo clickbaitowych newsów. Jednak zagrożenie jest rzeczywiste. PHP jest wszechobecnym oprogramowaniem używanym do tworzenia stron internetowych. Szacunki mówiły o około 1,3 mln serwerów zagrożonych na ataki. Rzecz jasna nie od razu takie ataki się pojawią i nie znaczy to, że ktoś zaatakuje wszystkie serwery w internecie.
Jednak te podatności pozwalają bez logowania się wykonywać polecenia systemowe, a to oznacza możliwość kradzieży danych, przejęcia maszyny przez napastnika lub jej całkowite zniszczenie w sensie systemowym. Dlatego spora część hostingów i dużych firm informatycznych zmieniła już stosowane wersje PHP na takie, które mają nałożone odpowiednie patche. Jednak są takie serwery, najczęściej w niewielkich firmach, które z różnych powodów wciąż obsługiwane są przez systemy zwane EOL (End Of Life). Tam administratorzy muszą czekać na ewentualne łatki ze strony dystrybucji Linuksa lub sami upgrejdować PHP, co nie jest rutynowym zadaniem. Z tego względu warto wiedzieć, że tymczasowo – przed zmianą wersji PHP – można zabezpieczyć system. Nie likwidując być może zagrożenia, ale je zmniejszając.
Co można zrobić? Przedstawię po kolei kilka usprawnień w konfiguracji serwera httpd i php. Po pierwsze można zastosować mod_security (większość niewielkich serwerów korzysta z apache, a czasem z nginx, więc można to zainstalować, jeśli dotychczas tego nie było). Potrzebna jest lokalna reguła o następującej treści:
SecRule ARGS_POST_NAMES|FILES_NAMES "@rx (?i)PHP_SESSION_UPLOAD_PROGRESS" \
"id:990001,\
phase:2,\
drop,\
log,\
msg:'Blokowanie proby wykorzystania CVE-2026-109619 (PHP2Shell)',\
severity:'CRITICAL',\
tag:'vulnerability',\
tag:'CVE-2026-109619'"
Po dodaniu tej reguły np. do /etc/httpd/modsecurity.d/activated_rules/local_rules.conf trzeba zrestartować serwer (systemctl restart httpd) i wtedy ze swojego komputera możemy wysłać żądanie: curl -F „PHP_SESSION_UPLOAD_PROGRESS=1” https://twoja.domena.pl (lub http://twoja.domena.pl). Gdy reguła zadziała, znajdziemy nie tylko wpis w logu ale też komunikat w linii poleceń podobny do tego:
curl: (56) OpenSSL SSL_read: OpenSSL/3.5.5: error:0A000126:SSL routines::unexpected eof while reading, errno 0
lub
curl: (52) Empty reply from server
Gdyby ta reguła nie działała, odpowiedzią byłby cały kod html strony www na serwerze. To nie wszystko. Trzeba jeszcze zmienić ustawienia php. W pliku php.ini (lub innym konfiguracyjnym) trzeba zmienić lub odkomentować niektóre wpisy. Wiele serwerów korzysta z mechanizmu php-fpm, więc plik konfiguracyjny to nie będzie ten w /etc.
; 1. Wyłączenie mechanizmu postępu wysyłania plików (blokuje główny wektor CVE-2026-109619)
session.upload_progress.enabled = Off
; 2. Zwiększenie limitu pamięci (utrudnia wywołanie Out-Of-Memory dla CVE-2026-109618)
memory_limit = -1
; 3. Zmniejszenie limitów wejściowych, aby utrudnić zalanie bufora pamięci wielkimi żądaniami
post_max_size = 8M
max_input_vars = 1000
To nie wszystko, używając php-fpm trzeba jeszcze znaleźć swój plik www.conf dla danej wersji PHP. (jeśli jest ich kilka konfigurację php trzeba zmienić dla każdej). Plik www.conf jest najczęściej w /etc/php-fpm lub np. w /etc/opt/.. (zależy to od dystrybucji Linuksa).
Na końcu tego pliku należy dopisać:
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
Jeżeli używamy php-fpm, trzeba osobno zrestartować usługę (systemctl restart php-fpm).
Na serwerze możemy uruchomić plik testowy, który przed wdrożeniem zabezpieczeń da następujący efekt:
=== WERYFIKACJA BEZPIECZEŃSTWA PHP ===
session.upload_progress.enabled: WŁĄCZONE (ZAGROŻENIE!)
=== WERYFIKACJA LIMITU PAMIĘCI ===
memory_limit: 128M (Oczekiwane: -1)
A po ich wdrożeniu i restarcie php-fpm taki:
=== WERYFIKACJA BEZPIECZEŃSTWA PHP ===
session.upload_progress.enabled: WYŁĄCZONE (BEZPIECZNIE)
=== WERYFIKACJA LIMITU PAMIĘCI ===
memory_limit: -1 (Oczekiwane: -1)
Kod pliku test.php wygląda tak jak poniżej:
<?php
header('Content-Type: text/plain; charset=utf-8');
$status = ini_get('session.upload_progress.enabled');
echo "=== WERYFIKACJA BEZPIECZEŃSTWA PHP ===\n";
echo "session.upload_progress.enabled: " . ($status ? "WŁĄCZONE (ZAGROŻENIE!)" : "WYŁĄCZONE (BEZPIECZNIE)") . "\n\n";
echo "=== WERYFIKACJA LIMITU PAMIĘCI ===\n";
echo "memory_limit: " . ini_get('memory_limit') . " (Oczekiwane: -1)\n";
?>
Znalazłem jeszcze dodatkowe wskazówki i również dodałem je w swojej konfiguracji. W końcowej części httpd.conf (przed odwołaniami innych plików konfiguracji) dodałem:
LimitRequestBody 8388608
Natomiast do wspomnianego wcześniej pliku konfiguracyjnego mod_security (local_rules.conf) dołożyłem jeszcze jedną regułę:
# Blokowanie zadań zawierających więcej niż 1000 argumentów (zabezpieczenie CVE-2026-109618)
SecRule &ARGS_POST "@gt 1000" \
"id:990002,\
phase:2,\
drop,\
log,\
msg:'Wykryto nienaturalnie dużą liczbę argumentów POST (Ochrona CVE-2026-109618)',\
severity:'CRITICAL'"
Teraz pozostaje wzmożona obserwacja logów serwera do czasu zainstalowania spatchowanej wersji php.
