Krytyczne luki w PHP: dlaczego fundacje charytatywne powinny sprawdzić swoje strony już teraz

21 października 2026 roku zespół PHP wydał nadzwyczajne aktualizacje, a europejski zespół reagowania na incydenty komputerowe CERT-EU opublikował pilne ostrzeżenie. Dwie luki z oceną zagrożenia 9,2 na 10 pozwalają atakującemu uruchomić własny kod na serwerze — bez loginu, bez hasła, bez żadnego działania ze strony pracowników czy wolontariuszy.

PHP to język, w którym napisana jest większość stron w internecie: WordPress, Joomla, OpenCart, Bitrix, Laravel. Strony fundacji charytatywnych, inicjatyw wolontariackich i zbiórek są niemal zawsze zbudowane właśnie na nim, a zatem ryzyko dotyczy ich tak samo jak dużych firm.

Co dokładnie znaleziono

Luk jest dwie, obie ocenione na 9,2 punktu i obie prowadzą do tego samego skutku — wykonania obcego kodu na serwerze bez autoryzacji.

CVE-2026-109618 — awaria przy braku pamięci

W PHP jest ustawienie memory_limit: żądanie, które zużyło zbyt wiele pamięci, jest przerywane siłowo. Problem polega na tym, jak dokładnie zostaje przerwane. PHP może urwać się w momencie, gdy wewnętrzne dane żądania są wypełnione tylko do połowy — na przykład w trakcie analizy pliku przesłanego przez formularz wysyłania. Porządkowanie po takim żądaniu bierze niedokończone dane za prawdziwe i próbuje zwolnić pamięć, której nigdy nie było. A w tej pamięci może leżeć to, co napastnik umieścił tam wcześniejszymi żądaniami.

CVE-2026-109619 — pozostałości poprzedniego żądania

Druga dziura dotyczy tego, że serwer nie do końca „zapomina” poprzedniego odwiedzającego. Stan wewnętrzny, który należał do jednego żądania, czasem przeżywa zwolnienie pamięci — powiedzmy po błędzie krytycznym. Następne żądanie, które trafiło do tego samego procesu roboczego, zdąży skorzystać z tych pozostałości, zanim zwykła inicjalizacja je wyzeruje.

Zagrożona jest każda instalacja PHP obsługująca żądania sieciowe: PHP-FPM, Apache z modułem mod_php, php-cgi, FrankenPHP, LiteSpeed. Za najbardziej ryzykowne zespół PHP uznaje właśnie połączenie Apache z mod_php — jest ono do dziś standardem na wielu tanich hostingach.

Demonstracyjny exploit działa jednym jedynym nieuwierzytelnionym żądaniem — jeszcze przed tym, jak zacznie wykonywać się kod samej strony. Czyli nie pomogą tu ani wtyczki bezpieczeństwa, ani skomplikowane hasła, ani uwierzytelnianie dwuskładnikowe: atak odbywa się o poziom niżej.

Które wersje są zagrożone

Wszystko, co jest niższe od tych wersji, jest podatne:

Gałąź PHP	Bezpieczna wersja
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 i starsze	brak wsparcia

Osobną kategorią ryzyka są produkty komercyjne i otwarte, wewnątrz których PHP jest wbudowany, choć z zewnątrz tego nie widać: panele zarządzania, urządzenia sieciowe, systemy monitoringu wideo, portale korporacyjne. Spis takiego oprogramowania prowadzi repozytorium niderlandzkiego NCSC.

Czym to grozi zbiórkom funduszy

Nikt nie szuka osobno strony konkretnej fundacji. Gdy przykłady włamania stają się publiczne — a są już publiczne — w ciągu kilku godzin uruchamiają się automatyczne skanery, które przeczesują cały internet po kolei. Jest im obojętne, czy to portal korporacyjny, czy strona zbiórki na samochód: liczy się tylko to, czy serwer odpowiada podatną wersją.

Dla fundacji najgroźniejszy nie jest ten scenariusz, w którym strona jest wyraźnie zepsuta. Przeciwnie: strona działa, wygląda jak zawsze — a numer karty albo dane zbiórki na stronie są po cichu zmienione. Darowizny płyną, ludzie przelewają środki, a wychodzi to na jaw wtedy, gdy ktoś sprawdza wpłaty. Obok tego idą zwykłe następstwa: web shell na serwerze, obce reklamy na stronach, domena na czarnych listach i poczta, która przestaje dochodzić do darczyńców i partnerów.

Trzecie ryzyko to dane. Listy darczyńców, zgłoszenia jednostek i dokumenty o przekazaniu pomocy zwykle leżą na tym samym serwerze co strona.

Co robić — krok po kroku

1. Proszę sprawdzić swoją wersję. W panelu hostingu to sekcja „Wersja PHP” lub „PHP Selector”; na własnym serwerze — polecenie php -v. Ważne jest sprawdzenie wersji, na której pracuje sama strona, a nie tej, która stoi w wierszu poleceń: często się różnią.
2. Proszę zaktualizować w ramach swojej gałęzi. Przejście z 8.2.29 na 8.2.35 to poprawka wewnątrz jednej gałęzi: zgodność zostaje zachowana, strona od tego się nie psuje. Nie należy tego mylić z przejściem z 8.2 na 8.4 — ono już wymaga sprawdzenia.
3. Jeśli mają Państwo 8.1 lub starszą — te gałęzie nie mają wsparcia. Z powodu powagi sytuacji zespół bezpieczeństwa PHP wydał minimalne poprawki także dla 7.4, 8.0 i 8.1, a część hostingów utrzymuje własne kompilacje. Właściwym rozwiązaniem jest jednak przeniesienie się na wspieraną gałąź, a lepiej zaplanować je teraz niż następnym razem.
4. Proszę zrestartować moduły obsługi. Bez restartu php-fpm lub Apache procesy robocze dalej pracują na starym kodzie i aktualizacja faktycznie nie działa.
5. Proszę sprawdzić wynik. Najprościej — tymczasowa strona z phpinfo(), którą zaraz po sprawdzeniu trzeba usunąć, albo sekcja „Wersja PHP” w panelu po restarcie.

Użytkownicy hostingu najczęściej nie będą musieli robić niczego ręcznie: duzi dostawcy dostali poprawki z wyprzedzeniem i sami aktualizują swoje maszyny. Warto napisać do wsparcia jedną linijkę — „czy PHP zostało zaktualizowane do wersji z 21 października 2026” — i dostać odpowiedź na piśmie.

Jeśli aktualizacja od razu nie jest możliwa

Bywa, że strona jest stara, a aktualizacja wymaga przygotowania. Wtedy są środki tymczasowe, które zwężają okno do ataku:

• zablokować przepełnienie pamięci jako punkt wejścia: memory_limit=-1, ustawiony tak, by aplikacja nie mogła tego nadpisać, oraz sprawdzenie, że żadna pula ani katalog nie przywraca limitu;
• zmniejszyć post_max_size — 8M dla stron bez wysyłania plików, 32M jeśli wysyłanie jest potrzebne, a upload_max_filesize trzymać niżej;
• wyłączyć session.upload_progress.enabled i zrestartować wszystkie procesy robocze;
• na PHP 8.5 dodatkowo wyłączyć fatal_error_backtraces;
• ograniczyć rozmiar i złożoność żądań na poziomie serwera WWW lub proxy.

Żaden z tych środków nie czyni instalacji bezpieczną. Zamykają one tylko znane drogi — całkowicie problem zamyka wyłącznie aktualizacja.

Jeśli i to jest niemożliwe, CERT-EU doradza proste i niepopularne rozwiązanie: usunąć podatną usługę z publicznego internetu, dopóki poprawka nie zostanie zainstalowana i sprawdzona.

Skąd te dane

• CERT-EU, Security Advisory 2026-018 „Critical Vulnerabilities in PHP”
• Ogłoszenie o wydaniu aktualizacji na php.net
• Techniczny opis CVE-2026-109618 i CVE-2026-109619

---

Jeśli fundacja nie ma osoby odpowiedzialnej za stronę i hosting, sprawdzenie można zamówić na zewnątrz — w szczególności w SmartGT: sprawdzą zasoby i powiedzą wprost, czy jest zagrożenie.

Autor materiału — SmartGT. Źródło pierwotne: „Krytyczne luki w PHP: aktualizacji nie można odkładać”.