Публикувани са коригиращи издания на PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, както и пачове за вече ненадеждни версии PHP 7.4, PHP 8.0 и PHP 8.1 (уязвимите версии от 5.4 до 7.3 остават без пачове), в които са коригирани две критични уязвимости:
- CVE-2026-109618 — отдалечено изпълнение на код, причинено от факта, че при изчерпване на наличната за процеса свободна памет, обработчикът за недостиг на памет чрез извикване на функцията longjmp() може да прекрати интерпретатора на PHP в състояние, при което са инициализирани само част от вътрешните структури, свързани с обработката на заявката. В последствие функцията за завършване на обработката на заявката се обръща към тези структури като към вече инициализирани, въпреки че паметта за тях не е предвидена.
Основният вектор на атака е манипулацията с multipart заявки за създаване на условия за изчерпване на наличната памет на процеса. За да се заобиколи лимита post_max_size, заглавието Content-Length може да не бъде указано и да се изпратят огромен брой HTTP заглавия. Възможно е да се провеждат и целеви атаки върху конкретни операции в php приложения, които прекалено разходват памет. Наличието на експлоит е потвърдено за mod_php, тъй като той извиква функцията shutdown() дори при срив. PHP-FPM при срив ще завърши дочерния процес, което затруднява провеждането на атака, но теоретично не я изключва.
- CVE-2026-109619 — отдалечено изпълнение на код, причинено от достъп до паметта след нейното освобождаване поради некоректно почистване на глобалното състояние, свързано с конкретна заявка. В случай на прекратяване на заявката поради фатална грешка, таймаут или недостиг на памет, глобалното състояние може да не бъде нулирано и указателите могат да останат активни, въпреки освобождаването на паметта, на която се позовават. При обработката на следващата заявка в същия процес може да се твърде застарял указател, който да се обърне към старото глобално състояние.
За експлоатация могат да бъдат създадени условия за изчерпване на наличната памет при обработка на multipart заявки в кода за индикация на напредъка на качването (session.upload_progress). В този случай основният и потвърден вектор на атака е обработчикът fatal_error_backtraces в PHP 8.5, който не нулира състоянието на трасировката при приключване. В първия случай атаката може да бъде извършена на mod_php и PHP-FPM, а във втория само на mod_php. Също така се споменава неподтвердената възможност за извършване на атака в конфигурации, при които настройките имат директиви, водещи до извеждане на предупреждения на ранна фаза от обработката на заявката (например, предупреждения за използване на остарели параметри).
Заявено е, че пълното блокиране на уязвимостите е възможно само чрез инсталиране на актуализация. Следващите мерки позволяват да се намали вероятността от успешни атаки, но не правят системата напълно безопасна:
- Настройване в php.ini на параметъра "memory_limit=-1", което затруднява атакуващия да контролира изчерпването на лимитите на паметта.
- Настройване на параметъра "post_max_size = 8M", ако няма нужда от качване на големи файлове. Стойността на параметъра "upload_max_filesize" трябва да е по-малка от параметъра "post_max_size".
- Задаване на лимит за допустимо потребление на памет на системно ниво, чрез cgroup memory.max или параметри за потребление на паметта на контейнера, но не през системни лимити RLIMIT_AS и RLIMIT_DATA, които само провокират проблемния повик longjmp().
- Ако производителността не е важна, може да се ограничи броят на заявките, обработвани от един работен процес, чрез pm.max_requests=1 в PHP-FPM и MaxRequestsPerChild в Apache httpd.
- Настройване на нивото на php.ini или конфигурацията сървър (не чрез ini_set() или FPM .user.ini, тъй като параметърът трябва да действа преди началото на обработката на заявката) параметъра "session.upload_progress.enabled=0.
- При използване на версия PHP 8.5 трябва да се настрои параметърът "fatal_error_backtraces=0."
- Премахване на свързани с отделни заявки остарели или грешни настройки (като assert.* и некоректни пътища в open_basedir), водещи до извеждане на диагностични съобщения преди инициализация.
- Отстраняване в PHP кода на ситуации, водещи до достигане на тайм-аут и фатални грешки, например, свързани с провали в callback-обработчиците и обработката на качвания.
- За блокиране на първата уязвимост в кода на старите версии на PHP може да замените извикването на longjmp() в обработвача на изчерпване на свободната памет с _exit().
- Допълнително можете да намалите стойността на параметъра max_input_nesting_level в php.ini и да блокирате multipart заявки, както беше показано в предварителния анонс.
Статусът на отстраняване на уязвимостите в дистрибутивите може да бъде оценен на следните страници: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.
Допълнение 1: Уязвимостите бяха открити с помощта на AI модели GPT‑5.6 и Gemini 4 Argon. Компанията OpenAI публикува утилита php2shell-checker за проверка на уязвимостите на сайтовете и локалните изпълними файлове, но тази утилита само проверява номер на версията на PHP, връщан от HTTP сървъра или командата «php -v», без детайлен анализ.
Допълнение 2: Авторът на прототипа на експлоита, използващ уязвимостта, предизвикана от двойно освобождаване на паметта (double-free), съобщи, че проблемът остава неотстранен в версията PHP 8.5.12 и експлоитът продължава да работи. По-рано представители на PHP заявиха, че тази уязвимост не е свързана с предстоящите корекции и не е реален проблем. Авторът на експлоита твърдеше, че това е съвсем различна уязвимост.
Източник: opennet.ru
