Критическая уязвимость в PHP

[dimassamid]

Бегет пока не торопится. Все сайты стоят. При этом фикс вышел где-то в 17 часов по МСК, как и обещали. На домашнем сервере я уже всё обновил, а у хостингов пока тормоза

Отправлено спустя 1 час 53 минуты 21 секунду:
Исправленные версии должны быть:

• 8.2.35
• 8.3.36
• 8.4.27
• 8.5.12

https://www.php.net/archive/2026.php

[Kuskow]

Evangelion, Исправления в PHP уже внесены.
Но не все провайдеры обновили у себя. Поэтому на всякий случай до обновления они отключили эту функцию, как бы чего не вышло. Тут на phpBBguru сделали так же - посмотрите красную плашку вверху страницы:

Уважаемые пользователи, по техническим причинам загрузка файлов временно недоступна. Приносим извинения за временные неудобства.

[Kuskow]

Было: Версия PHP: 8.2.31
Поменял на: Версия PHP: 8.3.31

В вашем списке доступных версий отображаются старые сборки (8.2.31, 8.3.31, 8.4.25). Все они уязвимы. Полностью безопасными являются только новые релизы, вышедшие буквально вчера:
• В ветке 8.2 — это 8.2.35
• В ветке 8.3 — это 8.3.36
• В ветке 8.4 — это 8.4.27
Пока Регру физически не соберет и не добавит эти новые безопасные версии в вашу панель, их глобальные правила фильтрации трафика будут блокировать отправку форм с файлами.

PHP 8.3.36 (cli)

[Kuskow]

Что изменилось в новостях за ночь:

1. Появились рабочие эксплоиты (PoC): Европейский киберцентр CERT-EU и другие агентства подтвердили, что в сети начали циркулировать первые рабочие прототипы инструментов для атаки (Proofs of Concept). Хакеры вовсю сканируют сеть. Это подтверждает, что вы обновились вовремя — те, кто отложил патч на пару дней, сейчас находятся под реальным ударом.

2. Уточнена зона максимального риска: Исследователи уточнили, что наибольшей опасности подвержены серверы, использующие старый модуль mod_php для веб-сервера Apache. На связке Nginx + PHP-FPM (которая по умолчанию используется в вашей HestiaCP) базовая конфигурация FPM частично блокирует один из векторов эксплуатации механизма нехватки памяти (OOM) на этапе старта. Но риск RCE через сессии все равно оставался, так что обновление для вас было обязательным.

3. Обнародована хроника задержки патча: Стало известно, почему уязвимость, существовавшая в коде годами, закрывалась в такой спешке. PHP Foundation признали, что первые теоретические признаки бага OOM были найдены еще во время внешнего аудита в 2024 году. Но тогда разработчики не смогли согласовать исправление, так как боялись нарушить совместимость со старыми расширениями, и работа заглохла. Только когда Wiz и OpenAI с помощью ИИ-инструментов построили полноценную цепочку взлома в октябре 2026 года, стало понятно, что медлить нельзя.

Более того, в некоторых регионах провайдеры вчера днем пошли на крайние меры — временно ограничивали зарубежный входящий трафик, чтобы снизить шквал автоматических хакерских сканирований, пока клиенты массово обновляют свои серверы.

[rxu]

Эпичнейший провал со стороны PHP Foundation.

[Vlad__]

А можно по-русски объяснить, что нужно сделать злоумышленнику, чтобы заюзаать эти уязвимости?

Загрузка файлов?

То есть гости и боты не навредят нашим форумам?

[Leo Angel]

Посмотрел у себя на форуме в Сведения о PHP.
Написано: PHP Version 8.3.6, Build Date - Jul 14 2025 18:30:55.

Что это значит? Я уязвим или нет?
Или нужно смотреть на сервере?

Отправлено спустя 4 минуты 13 секунд:
Да, и желательно разъяснить простыми словами, чем грозит форумам эта уязвимость?

[Kuskow]

Да, обновление от 14 июля - это старая версия. Для 8.3 должно быть 8.3.36 от 21 октября.

Для форумов phpBB уязвимость PHP2Shell несет критическую угрозу, так как бьет по самому популярному функционалу — формам публикации. Нападающему даже не нужно знать, что на сервере стоит phpBB. Атака идет по стандартному протоколу передачи данных, который используется везде.

Главные риски для форума:

• Полный захват сервера (RCE): Хакер может удаленно выполнить любой вредоносный код с правами веб-сервера. Это позволяет залить на сервер шелл (вредоносный скрипт), получить доступ к конфигурационным файлам форума (включая пароли от базы данных в config.php) и полностью скомпрометировать операционную систему.
• Кража конфиденциальной памяти: Из-за утечки данных между запросами (баг Use-After-Free) злоумышленник может прочитать конфиденциальную информацию из памяти соседних процессов PHP-FPM. В этой памяти могут находиться пароли пользователей, сессии администраторов, cookies и персональные данные других участников форума, которые в этот момент находились на сайте.
• Массовый спам и подмена контента: Получив контроль над кодом, хакеры могут автоматически внедрить скрытые ссылки, рекламные баннеры или вредоносные редиректы на сторонние ресурсы прямо в код страниц форума, что быстро приведет к бану сайта в поисковых системах.

Почему под ударом именно вложения?

Критическая уязвимость срабатывает в момент, когда PHP обрабатывает POST-запросы типа multipart/form-data. На форумах этот тип запроса используется каждый раз, когда пользователь создает тему, редактирует сообщение или пытается прикрепить к нему любой файл (картинку, архив, документ).
Поэтому простого обновления самого phpBB до последней версии в данной ситуации недостаточно — уязвимость находится на уровень ниже, в самом ядре PHP. Закрыть её можно только обновлением интерпретатора на сервере до безопасных версий (8.2.35, 8.3.36, 8.4.27).

Для владельцев сайтов и форумов, которые до сих пор работают на архивных версиях вроде PHP 5.x или PHP 7.x, ситуация самая сложная. Официальная поддержка этих веток давно прекращена, и разработчики PHP Foundation не выпустили и не выпустят для них официальные исправления безопасности. Оставлять всё как есть нельзя — серверы со старыми PHP сейчас находятся под максимальной угрозой автоматических взломов.

[rxu]

на архивных версиях вроде PHP 5.x или PHP 7.x, ситуация самая сложная

Для версий PHP 7.4, 8.0 и 8.1 выпущены бэк-порты в виде исходников, из которых можно собрать бинарники самостоятельно, если этого не делают хостинг-провайдеры.

[Kuskow]

У меня в Nginx режутся все POST-запросы без cookies - это значит, воспользоваться этой уязвимостью на моём сервере не получилось бы?

Код: Выделить всё

if ($request_method$http_cookie ~ "^(HEAD|POST)$") { return 444; }

Да, абсолютно верно. Если на уровне Nginx у вас настроена жесткая фильтрация и все POST-запросы без заголовка Cookie гарантированно сбрасываются (например, с кодом 444), то эта уязвимость до вашего PHP физически не могла добраться. Это идеальная инженерная защита.
Даже на старых архивных версиях PHP (таких как 5.4, 5.6 или 7.4) этот фильтр в Nginx полностью защитил бы ваш сервер от внешних автоматических атак. Физика процесса здесь не зависит от версии PHP, потому что Nginx выполняет эту проверку до того, как передаст запрос интерпретатору.

[Bydlocoder]

Пришлось все забекапить, снести старую vestacp на ubuntu 18.04. Залить новый образ 22;04, обновить php, поставить HestiaCP, поднять форум из бекапа

[angst66]

Залить новый образ 22;04

Нужно было ставить Ubuntu 24.04, имхо

[Siava]

Залить новый образ 22;04

Так он уже не новый.. более менее новый 24.04, а лучше 26.04.

[Bydlocoder]

Нужно было ставить Ubuntu 24.04, имхо

Да, не то написал, его и поставил

24.04, а лучше 26.04.

Не, пока не буду 26,

[angst66]

а лучше 26.04.

О, уже поддерживает, отстал.