Критические уязвимости PHP в октябре 2026: что сделать владельцу сайта

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

Что случилось за два дня

17 октября независимый исследователь сообщил, что приватные ключи восьми промежуточных сертификатов eMudhra оказались слабыми. 21 октября команда PHP выпустила внеплановые релизы, закрывающие две критические уязвимости в ядре. В тот же день Битрикс24 сообщил о временных ограничениях в облаке — как раз из-за этих уязвимостей PHP.

Три события связаны между собой только временем, но реагировать нужно на каждое.

Уязвимости PHP: что именно закрыли

21 октября вышли релизы 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Они закрывают две уязвимости с оценкой 9.2 по CVSS — в обеих подтверждено удалённое выполнение кода без авторизации.

CVE-2026-109618 — нехватка памяти ломает состояние запроса. PHP использует longjmp() для выхода при исчерпании памяти. В некоторых местах память запроса уже доступна, но ещё не инициализирована; если выделение памяти падает в этот момент, завершение запроса работает с невалидными данными. Довести запрос до такого состояния можно через multipart/form-data: запрос без корректной длины тела, неограниченное число заголовков в части, пустые поля загрузки файлов. Атака срабатывает до кода приложения — работает даже на пустом index.php. Полная RCE подтверждена против Apache с mod_php.

CVE-2026-109619 — «протухшее» состояние воркера. Воркер хранит глобальное состояние (ошибки, сессии, объекты, состояние расширений), которое может указывать на память конкретного запроса. Если запрос прервался фатальной ошибкой, сброс может не произойти, память освобождается, а указатель остаётся. Следующий запрос в том же воркере обращается к нему до нормальной инициализации — use-after-free. Для атаки нужны два запроса: один оставляет мусор, второй его использует. Подтверждено на mod_php и через жизненный цикл сессий на PHP-FPM.

Ветки 8.1 и старше официально не поддерживаются — исправлений для них не будет, только переход на 8.3 или 8.4.

Что это значит для PHP 8.1 и старше

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

Практический вывод: сайт на PHP ниже 8.2 остаётся уязвимым не «до следующего патча», а бессрочно. Вариантов два.

Первый — переезд на 8.3 или 8.4. Это не одна команда: сначала проверяется совместимость CMS, шаблона и расширений на тестовой копии, затем переносится прод. Для интернет-магазина на Bitrix это чаще всего один-два рабочих дня с проверкой оформления заказа, оплат и админки.

Второй — если переезд сейчас невозможен, временно сузить поверхность атаки: отключить session.upload_progress, задать memory_limit=-1 с ограничением памяти снаружи, ограничить размер и количество частей multipart на веб-сервере, поставить WAF. Эти меры не устраняют уязвимость, а лишь снижают вероятность эксплуатации — и всё равно оставляют переезд в планах.

Кому действовать в первую очередь

Если у вас сайт на 1С-Битрикс или на WordPress, PHP работает на вашем сервере. Обновлять его нужно вам или вашему подрядчику — за вас этого никто не сделает.

Если вы работаете в облаке Битрикс24, за PHP в облаке отвечает Битрикс. Они уже ограничили часть функций: по их сообщению, ограничения могут затрагивать работу с формами и файлами, возможны и другие сложности. Это не авария, а сознательная мера на время устранения угрозы.

Если у вас коробочная версия Битрикс24, она снова живёт на вашем сервере — и PHP обновляете вы.

Отдельно стоит запомнить формулировку из сообщения Битрикса: 17:00 МСК — это время ожидаемого выпуска исправлений разработчиками PHP, а не срок восстановления всех функций. После релиза нужно время на установку и проверку.

Что сделать по шагам

1. Проверить версию PHP. В консоли: php -v. В панели ISPmanager, Plesk или cPanel версия видна в настройках сайта или в разделе PHP.
2. Обновить пакеты до 8.2.35, 8.3.36, 8.4.27 или 8.5.12. В Debian и Ubuntu из репозитория ondrej: apt update && apt install --only-upgrade 'php8.4*'.
3. Перезапустить воркеры. systemctl restart php8.4-fpm или systemctl restart apache2, если используется mod_php. Без перезапуска старый код остаётся в памяти, и обновление ничего не меняет.
4. Проверить, что версия сменилась: php -v и открыть сайт, включая формы и загрузку файлов.
5. Повторить для каждого сайта на сервере, у которого своя версия PHP.

Если обновиться прямо сейчас нельзя

Полноценной защиты без обновления нет — это прямо написано в бюллетенях. Временные меры только сужают поверхность атаки:

• memory_limit=-1 на уровне администратора (в пуле FPM или конфиге Apache) с перезапуском воркеров — убирает предсказуемый лимит, на котором построен эксплойт первой уязвимости. Память при этом нужно ограничивать снаружи, через cgroup или контейнер.
• Для PHP 8.5 — fatal_error_backtraces=0, это убирает подтверждённый путь к RCE.
• session.upload_progress.enabled=0 — закрывает подтверждённый сценарий с сессиями.
• pm.max_requests=1 в пуле FPM: каждый воркер обрабатывает один запрос, «мусору» не к кому переходить. Подходит только если производительность не критична.
• Ограничить размер тела и количество частей multipart на фронтенде: в nginx или WAF.

Вторая история: сертификаты eMudhra

17 октября нашли, что приватные ключи восьми промежуточных сертификатов eMudhra сгенерированы с недостаточной случайностью: значения были меньше 256, то есть подбирались перебором за 256 попыток. Один из ключей опубликовали публично — его значение оказалось равно 4.

Что это значит на практике: любой, кто знает такой ключ, может выпустить поддельный сертификат на чужой домен и попытаться выдать себя за сайт, читая или подменяя трафик. Сертификат — это «паспорт» сайта, и подделанный паспорт глазами не отличить.

Реакция была быстрой: Mozilla заблокировала сертификаты через OneCRL за три часа — без обновления браузера, Chrome выпустил CRLSet в тот же день, Apple подключилась 19 октября, Go выпустил 1.27.3 и 1.26.10. Уязвимыми остаются устройства без обновлений и софт, который использует собственное хранилище сертификатов.

Отдельное следствие: Chrome удаляет из своего хранилища корневой сертификат emSign ECC Root CA - G3. Освобождение выходит на всех устройствах 27 октября — сайты и сервисы, чьи сертификаты выпущены через эту ветку, перестанут открываться в Chrome. Если вы не уверены, к какой ветке относится ваш сертификат, проверьте цепочку.

Как проверить себя за минуту

Сертификат:

openssl s_client -connect ваш-домен:443 -showcerts

В выводе смотрите строки i: (issuer) и s: (subject). Если увидите emSign или AAA Certificate Services — сертификат выпущен через затронутую ветку, его нужно менять.

PHP:

php -v

Если версия ниже 8.2.35, 8.3.36, 8.4.27 или 8.5.12 — на сервере работают уязвимые релизы.

Что полезно сделать на этой неделе

Это не срочная авария, а гигиена, которая занимает час и снимает большую часть риска.

1. Проверить версию PHP на каждом сайте. php -v в консоли или настройки сайта в панели управления — пять минут на сервер.
2. Обновить и перезапустить. Обновление пакетов плюс systemctl reload php-fpm — пятнадцать минут на сервер, включая проверку форм и загрузки файлов.
3. Проверить сертификат. openssl s_client -connect ваш-домен:443 -showcerts: если в цепочке есть emSign или AAA Certificate Services, сертификат выпущен через затронутую ветку и его нужно менять.
4. Настроить еженедельную проверку обновлений. Не «когда вспомним», а в календаре: раз в неделю смотреть, не вышли ли обновления PHP и CMS. Большинство громких взломов случаются не в день выхода патча, а через месяцы, когда про него забыли.
5. Назвать ответственного. Кто именно обновляет PHP, в какой срок после выхода патча и по какому каналу приходит уведомление. Если ответа нет — это и есть главный риск, а не сама уязвимость.
6. Проверить резервные копии. Обновление может что-то сломать; важно, чтобы сайт можно было вернуть за сутки, а не за неделю переписки с хостингом.

**Итог

Все три события требуют одного и того же: обновиться и перезапустить сервисы. Уязвимость в PHP не спрашивает пароль, а поддельный сертификат не видно глазами — поэтому «подождём, пока само рассосётся» здесь не работает. Если на сервере несколько сайтов и разные версии PHP, проверьте каждый: самая старая ветка и есть самая опасная.