Opublikowano poprawki do PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, a także łatki dla już nie wspieranych gałęzi PHP 7.4, PHP 8.0 i PHP 8.1 (wrażliwe wersje od 5.4 do 7.3 pozostają bez poprawek), w których naprawiono dwie krytyczne luki bezpieczeństwa:
- CVE-2026-109618 — zdalne wykonanie kodu spowodowane tym, że w przypadku wyczerpania dostępnej pamięci procesu obsługa braku pamięci poprzez wykonanie funkcji longjmp() może przerwać interpreter PHP w sytuacji, gdy zainicjalizowana jest tylko część struktur wewnętrznych związanych z obsługą żądania. Następnie funkcja kończenia przetwarzania żądania odnosi się do tych struktur jako już zainicjalizowanych, chociaż pamięć dla nich nie została przydzielona.
Głównym wektorem ataku jest manipulacja żądaniami multipart w celu stworzenia warunków do wyczerpania dostępnej pamięci procesu. Aby obejść limit post_max_size, nagłówek Content-Length może nie być uwzględniony, a do przesyłania może być wykorzystana ogromna liczba nagłówków HTTP. Możliwe jest prowadzenie też punktowych ataków na konkretne operacje w aplikacjach PHP, które nadmiernie zużywają pamięć. Obecność exploita potwierdzono dla mod_php, ponieważ wywołuje on funkcję shutdown() nawet w przypadku awarii. PHP-FPM w przypadku awarii zakończy proces potomny, co utrudnia przeprowadzenie ataku, ale teoretycznie go nie wyklucza.
- CVE-2026-109619 — zdalne wykonanie kodu spowodowane odwołaniem do pamięci po jej zwolnieniu z powodu nieprawidłowego oczyszczenia globalnego stanu przypisanego do konkretnego żądania. W przypadku przerwania żądania z powodu błędu krytycznego, limitu czasu lub wyczerpania pamięci globalny stan może nie zostać zresetowany, a wskaźniki pozostaną aktywne, mimo że pamięć, do której się odwołują, została zwolniona. Podczas przetwarzania następnego żądania w tym samym procesie może dojść do odwołania się przez pozostający wskaźnik do starego globalnego stanu.
Do eksploatacji można wykorzystać tworzenie warunków wyczerpania dostępnej pamięci podczas przetwarzania żądań multipart w kodzie do wskazywania postępu ładowania (session.upload_progress). Przy tym jako główny i potwierdzony wektor ataku wymienia się obsługę fatal_error_backtraces w PHP 8.5, która nie resetuje stanu śledzenia przy zakończeniu. W pierwszym przypadku atak jest możliwy na mod_php i PHP-FPM, a w drugim tylko na mod_php. Mówi się również o niepotwierdzonej możliwości przeprowadzenia ataku w konfiguracjach, w ustawieniach których znajdują się dyrektywy prowadzące do wyświetlania ostrzeżeń na wczesnym etapie przetwarzania żądania (na przykład ostrzeżenia o używaniu przestarzałych parametrów).
Zgłoszono, że całkowite zablokowanie luk jest możliwe tylko poprzez zainstalowanie aktualizacji. Następujące środki zmniejszają prawdopodobieństwo udanego przeprowadzenia ataków, ale nie czynią systemu całkowicie bezpiecznym:
- Ustawienie w php.ini parametru „memory_limit=-1”, co utrudnia atakującemu kontrolowanie wyczerpania limitów pamięci.
- Ustawienie parametru „post_max_size = 8M”, jeśli nie ma potrzeby przesyłania dużych plików. Wartość parametru „upload_max_filesize” powinna być mniejsza od parametru „post_max_size”.
- Ustalenie limitu na dozwolone zużycie pamięci na poziomie systemowym, poprzez cgroup memory.max lub parametry zużycia pamięci kontenera, ale nie poprzez systemowe limity RLIMIT_AS i RLIMIT_DATA, które jedynie prowokują problemowe wywołanie longjmp().
- Jeśli wydajność nie jest istotna, można ograniczyć liczbę żądań przetwarzanych przez jeden proces roboczy poprzez pm.max_requests=1 w PHP-FPM i MaxRequestsPerChild w Apache httpd.
- Ustawienie na poziomie php.ini lub konfiguracji serwery (nie przez ini_set() lub FPM .user.ini, ponieważ parametr powinien działać przed rozpoczęciem przetwarzania żądania) parametru „session.upload_progress.enabled=0.
- Przy korzystaniu z wydania PHP 8.5 należy ustawić parametr „fatal_error_backtraces=0”.
- Usunięcie powiązanych z pojedynczymi żądaniami przestarzałych lub błędnych ustawień (typu assert.* i niewłaściwych ścieżek w open_basedir), prowadzących do wyświetlania komunikatów diagnostycznych przed inicjalizacją.
- Usunięcie w kodzie PHP sytuacji prowadzących do osiągania limitów czasu i błędów krytycznych, na przykład związanych z awariami w callbackach i przetwarzaniu przesyłek.
- Aby zablokować pierwszą lukę w kodzie starszych wersji PHP, można zastąpić wywołanie longjmp() w obsłudze wyczerpania pamięci swobodnej na _exit().
- Dodatkowo można zmniejszyć wartość parametru max_input_nesting_level w php.ini oraz zablokować zapytania multipart, jak pokazano w wcześniejszym ogłoszeniu.
Status usuwania luk w dystrybucjach można ocenić na tych stronach: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.
Dodatek 1: Luki zostały wykryte przy pomocy modeli AI GPT‑5.6 oraz Gemini 4 Argon. Firma OpenAI opublikowała narzędzie php2shell-checker do sprawdzania podatności na luki w stronach internetowych i lokalnych plikach wykonywalnych, ale to narzędzie sprawdza jedynie numer wersji PHP zwracany przez serwer HTTP lub polecenie „php -v”, bez szczegółowej analizy.
Dodatek 2: Autor prototypu exploita, wykorzystującego lukę spowodowaną podwójnym zwolnieniem pamięci (double-free), poinformował, że problem pozostaje niepoprawiony w wydaniu PHP 8.5.12, a exploit nadal działa. Wcześniej przedstawiciele PHP twierdzili, że ta luka nie jest związana z planowanymi poprawkami i nie stanowi rzeczywistego problemu. Autor exploita przekonywał jednak, że to zupełnie inna luka.
Źródło: opennet.ru
