Руководства по безопасности

[Срочно] Две критические уязвимости PHP (CVE-2026-109618, CVE-2026-109619): японские IPA и JPCERT/CC выпустили предупреждения. Обновите до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 сейчас

PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 устраняют два критических недостатка RCE (CVE-2026-109618, CVE-2026-109619). IPA, JPCERT/CC и CISA выпустили предупреждения. Для третьей, пока не исправленной проблемы (CVE-2026-115560) есть способ снижения риска. Что обновлять и как обстоят дела у провайдеров общего хостинга.

Опубликовано 2026-10-21 Обновлено 2026-10-25 Последняя проверка 2026-10-25 36 мин чтения
На этой странице

Для кого это: для всех, кто запускает сайт на PHP (собственный сервер, VPS, облако, Docker или общий хостинг), и для тех, кто создаёт сайты на WordPress, Laravel, EC-CUBE и аналогичных платформах. Статья основана на официальных объявлениях команды безопасности PHP и заявлениях государственных органов и провайдеров. Здесь не описано, как что-либо атаковать.

В развитии: эта страница будет обновляться по мере публикации новых данных

По состоянию на 25 октября 2026 года (JST); хостинг-провайдеры и пакеты ОС — по состоянию на 02:15 UTC 23 октября

Пока неизвестно

  • Затронутые версии, оценка CVSS и исправленный релиз для третьей проблемы, CVE-2026-115560 (ожидаются с следующим регулярным релизом)
  • Эксплуатация в реальных условиях (официальная позиция) и были ли взломы
  • Оставшиеся потоки пакетов ОС (RHEL 9 php:8.4, Debian testing forky)
  • Хостинг-провайдеры, которые не объявили о завершении (KAGOYA, CPI для версий без исправленного релиза, Xserver для PHP 5.5 и старше, и другие)

Команда безопасности PHP выпустила исправления 21 октября, а IPA и JPCERT/CC Японии выпустили предупреждения 22 октября. Большинство крупных провайдеров общего хостинга сообщили, что исправление применено. Несколько компаний зафиксировали попытки эксплуатации, но подтверждённых взломов объявлено не было. 23 октября была раскрыта третья проблема (CVE-2026-115560), которую исправленные версии не устраняют. Команда PHP считает её маловероятной на практике, но рекомендует установить session.upload_progress.enabled=0 до следующего регулярного релиза. Эта страница будет обновляться по мере подтверждения состояния оставшихся пакетов ОС и провайдеров.

Исправленные версии и уязвимости (по данным php.net)

21 октября 2026 года команда безопасности PHP опубликовала рекомендацию по безопасности на php.net («Критические уязвимости удалённого выполнения кода, обновитесь сейчас») и объявила исправленный релиз для каждой ветки.

Объявление команды безопасности PHP (21 октября 2026 года)
Исправленные версии
PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
CVE-2026-109618
Обработка нехватки памяти может прервать PHP, когда внутренние данные запроса инициализированы лишь частично, и очистка после запроса может затем принять недействительные данные за корректные. Приводит к удалённому выполнению кода (RCE)
CVE-2026-109619
Внутреннее состояние, принадлежащее запросу, может сохраниться после освобождения памяти, на которую оно указывало, и последующий запрос, обрабатываемый тем же рабочим процессом, может использовать это устаревшее состояние до того, как оно будет сброшено инициализацией. Приводит к удалённому выполнению кода (RCE)
Серьёзность
Обе с оценкой CVSS v4.0 9.2
Кто под угрозой
Все установки PHP, обслуживающие веб-запросы (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). Наибольший риск у mod_php: продемонстрирован эксплойт, в котором запрос без аутентификации запускает атаку до выполнения какого-либо кода приложения
8.1 и более ранние
Обновлений от проекта PHP нет. Минимальные патчи исходного кода предоставлены для 7.4, 8.0 и 8.1
Дистрибутивы
Дистрибутивы Linux и поставщики LTS получили патчи заранее; проверьте обновлённые пакеты у своего поставщика
Меры защиты
Полной защиты нет; обновление — единственный безопасный выбор (временные меры, если вы пока не можете обновиться, — в блоке ниже)

Временные меры, если обновиться пока нельзя (по объявлению; они не делают систему безопасной)

Команда PHP перечисляет настройки, которые снижают риск по отдельным путям атаки до обновления, но говорит, что ни одна из них не делает установку безопасной. Основные из них: проверка memory_limit и ограничений размера запроса, таких как post_max_size, отключение session.upload_progress.enabled и перезапуск рабочих процессов, а в PHP 8.5 — отключение fatal_error_backtraces. Условия важны, поэтому прочитайте официальное объявление перед любыми изменениями и приоритетно выполните обновление.

Третья проблема, не устранённая выпусками (CVE-2026-115560, раскрыта 23 октября)

23 октября 2026 года команда безопасности PHP опубликовала на php.net «Информационное объявление: прогресс загрузки сессии», раскрыв проблему, которую выпуски от 21 октября не исправляют. Она отдельна от двух критических уязвимостей.

Объявление команды безопасности PHP (23 октября 2026 года)
CVE
CVE-2026-115560. Полное описание будет опубликовано с следующим релизом (по состоянию на 25 октября записи CVE и NVD ещё нет)
Условия
Затронуто только необычное сочетание конфигурации и кода приложения: в конфигурации задано session.serialize_handler со значением php_binary или php_serialize, приложение переключает его на php во время выполнения с помощью ini_set() перед вызовом session_start(), и при этом остаётся включённым прогресс загрузки сессии (session.upload_progress). Приложения, которые никогда не меняют обработчик сериализации во время выполнения, могут оставить эту функцию включённой
Последствия
Может привести к удалённому выполнению кода (RCE). Команда называет такую конфигурацию «маловероятной на практике»
Меры защиты
Установить session.upload_progress.enabled=0 до следующего регулярного релиза. Та же настройка уже была указана как мера защиты в объявлении от 21 октября для CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp); если вы применили её тогда, оставьте как есть, дополнительных действий не требуется
Исправление
Поскольку конфигурация маловероятна, исправление включено в регулярный цикл выпусков: исправление и полное описание выйдут с следующим релизом. Дата не указана
Пока не опубликовано
Затронутые версии и оценка CVSS
Эксплуатация
В объявлении команды PHP эксплуатация не упоминается

После выпуска (по состоянию на 02:15 UTC 23 октября 2026 года)

Что этот сайт подтвердил после выпуска
Время выпуска
Рекомендации безопасности GitHub опубликованы примерно в 13:34 UTC (22:34 JST), примерно на 30 минут раньше графика 14:00 UTC
Затронутые версии
Согласно официальным рекомендациям GitHub, версии до 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Записи CVE указывают 8.2–8.5 и ничего не говорят о 8.1 и более ранних (команда предоставила исправления исходного кода для 7.4, 8.0 и 8.1)
Подтверждённое воздействие (по рекомендациям)
CVE-2026-109618: удалённое выполнение кода без аутентификации подтверждено для mod_php; PHP-FPM может быть затронут по анализу исходного кода, но полный эксплойт не продемонстрирован. CVE-2026-109619: удалённое выполнение кода подтверждено для mod_php; также проверено на PHP-FPM через путь прогресса загрузки сессии, который зависит от подходящей операции приложения
Государственные органы Японии
22 октября IPA опубликовало «Меры против уязвимостей PHP (CVE-2026-109618, CVE-2026-109619: PHP2shell)» (на японском языке), в продолжение предварительного уведомления от 21 октября. Пользователям рекомендуется обновиться до исправленных версий (8.2.35, 8.3.36, 8.4.27, 8.5.12). Для версий 8.1 и более ранних, срок поддержки которых истёк, рекомендуется перейти на поддерживаемую версию PHP или на продукт либо сервис, который был исправлен. Если эффективные временные меры трудно применить, организациям предлагается оценить, нужно ли блокировать внешний доступ или временно остановить сервис. Также в нём приводится мнение участвовавшей в исследовании компании по информационной безопасности, согласно которому PHP 5.4 и более поздние версии затронуты как минимум одним из недостатков (это мнение компании, а не заявление команды PHP). JVN опубликовала JVNVU#99905564 в 10:30 JST (01:30 UTC) в тот же день, призвав пользователей установить патчи. JPCERT/CC выпустила предупреждение (JPCERT-AT-2026-0033) в тот же день с призывом к скорейшему обновлению и проверке на признаки компрометации. Оно также описывает, что именно искать при такой проверке
CISA
CISA выпустила предупреждение 21 октября с призывом к немедленной установке исправлений. В нём говорится, что на момент публикации она «не наблюдала эксплуатации этих уязвимостей». Организациям, которые не могут обновиться немедленно или всё ещё работают на PHP 8.1 или более ранней версии, рекомендуется отключить системы на PHP до установки патчей или обновления. Эти уязвимости не входят в каталог Known Exploited Vulnerabilities (издание от 21 октября)
Эксплуатация в реальных условиях
Заявлений от команды PHP нет, а CISA сообщила, что на момент публикации эксплуатации не наблюдала. Оценка эксплуатации, которую CISA добавляет в записи CVE, после их обновления 22 октября по-прежнему была «none» («нет»). Группа разведки угроз крупного облачного провайдера заявила 21 октября, что её honeypot-системы зафиксировали попытку эксплуатации 17 октября, за четыре дня до раскрытия (публикация). В ней говорится, что уязвимости «сейчас становятся объектом широких попыток эксплуатации в реальных условиях», но что «неясно, были ли какие-либо из этих попыток успешными в реальных системах». Рекомендуется проводить проверку начиная минимум с 17 октября. Провайдер CDN и несколько компаний по безопасности также сообщают о регистрации атакующего или сканирующего трафика (провайдер CDN, обзор новостей). Другая компания по безопасности в обновлении от 22 октября сообщила, что публичные эксплойты не работают против установки PHP по умолчанию и что массовая эксплуатация менее вероятна, чем изначально предполагалось. В Японии Lolipop и Heteml 22 октября заявили, что зафиксировали обращения, похожие на попытки использовать эти уязвимости, но никакого несанкционированного доступа или утечки данных в результате пока не подтверждено. По состоянию на 02:15 UTC 23 октября подтверждённых взломов объявлено не было
Пакеты ОС
Ubuntu выпустила исправления для перечисленных релизов 26.10, 26.04, 24.04 и 22.04. Исправления для 20.04 и 18.04 требуют Ubuntu Pro; для 16.04 и 14.04 нужен дополнительный пакет Legacy Support (USN-8948-1, USN-8948-2). Debian исправила версии 13 (DSA-6574-1) и 12 (DLA-4848-1); sid уже содержит исправленную 8.4.27-1, а testing (forky) всё ещё на неисправленной 8.4.26-1. Red Hat исправила многие потоки RHEL 8–10 (оценка Important, access.redhat.com) и 21 октября добавила RHEL 8 php:8.2 (RHSA-2026:87073). В RHEL 9 php:8.4 исправления по-прежнему нет («Затронуто» в обновлении от 22 октября). RHEL 6 отмечен как «вне области поддержки» без планов исправления, а RHEL 7 затронут CVE-2026-109619, исправления пока нет. Alpine исправила 8.5, 8.4 и 8.3. Если PHP установлен из пакетов ОС, примените обновление от своего поставщика сейчас
Официальные образы Docker
Теги latest, 8.5, 8.4, 8.3 и 8.2 (включая варианты -apache и -fpm) указывают на исправленные версии (8.5.12, 8.4.27, 8.3.36, 8.2.35) (hub.docker.com). Теги 8.1 и более ранних, срок поддержки которых истёк, не обновлялись. Исправление вступает в силу только после повторной загрузки образа и пересоздания контейнеров
NVD
Собственная оценка NVD для обеих уязвимостей — CVSS 3.1 9.8 (Critical); оценка команды PHP — CVSS v4.0 9.2 (nvd.nist.gov)
Утверждение, что исправление неполное
В сообщении в списке рассылки по уязвимостям говорилось, что исправление 8.5.12 «может быть неполным». Разработчик, опубликовавший объявление для команды безопасности PHP, ответил в том же списке 22 октября (09:11 UTC), что это «не связанная проблема с минимальным влиянием» (сбой одного компонента в маловероятном сценарии) и что она «не имеет отношения к RCE» (ответ). Объявление на php.net не изменилось
Windows
Сборки исправленных версий для Windows доступны
remirepo
Команда PHP сообщает, что rpms.remirepo.net, который поддерживают добровольцы, сегодня обновлений не выпустит, и рекомендует перейти на пакеты дистрибутива или собрать PHP из исходников

Предварительное уведомление (20 октября)

Днём раньше, 20 октября 2026 года, команда безопасности PHP опубликовала на php.net уведомление «Предстоящий критический релиз по безопасности PHP». В нём говорилось следующее.

Уведомление команды безопасности PHP (20 октября 2026 года)
Время выпуска
Среда, 21 октября 2026 года, 14:00 UTC (23:00 в Японии)
Охват
Две критические уязвимости
Серьёзность
Обе с оценкой 9.2 по CVSS v4.0
Просьба
Всех пользователей PHP призывают подготовиться заранее, чтобы обновиться сразу после выхода релиза
Более ранний выпуск
Команда может выпустить релиз раньше, если подробности любой из уязвимостей станут публичными или появятся признаки активной эксплуатации
Пока не опубликовано
Полные подробности, затронутые и исправленные версии, всё это ожидалось с релизом
Последние версии на тот момент
8.5.11, 8.4.26, 8.3.35 и 8.2.34 (релизы безопасности от 24 сентября 2026 года)

CVSS оценивает серьёзность уязвимости по шкале от 0 до 10; оценка 9.0 и выше относится к высшей категории «Critical» (см. Что такое CVSS). IPA Японии 21 октября также опубликовала уведомление «подготовьтесь заранее», призывая организации провести инвентаризацию программ, использующих PHP. IPA отмечает, что PHP может работать не только в веб-приложениях, но и внутри программных продуктов и сетевых устройств.

Кто обновляет PHP: это зависит от вашей конфигурации

Любой сайт, работающий на PHP, может быть затронут, но то, кто именно обновляет PHP, различается в зависимости от среды. Ошибка в этом приводит к пробелам вроде «я думал, это сделал провайдер» или «я обновил не тот PHP, который обслуживает сайт».

Собственный сервер, VPS, облако

Обновляете вы (обновите пакеты, затем перезапустите)

Docker (официальный образ)

Пересоберите образ, когда выйдут новые теги

Пакеты дистрибутива (Debian, Ubuntu, RHEL …)

Дистрибутив переносит исправление, вы его применяете. Номера версий отличаются от upstream

Общий хостинг

Обновляет провайдер. Вы проверяете, какую версию выбрали

Кто обновляет PHP, зависит от того, как вы запускаете сервер. Это отдельная задача от обновления WordPress или Laravel.
СредаКто обновляет PHPЧто делаете вы
Собственный сервер, VPS, облачный серверВыУстановите исправленную версию (или исправленный пакет дистрибутива) и перезапустите PHP-FPM или Apache
Официальный образ Docker (php:8.4-fpm и т. п.)Мейнтейнеры образов и выКогда выйдет исправленный тег, загрузите его, пересоберите свой образ и замените контейнеры. Не используйте закэшированный старый базовый образ
Пакеты дистрибутивов (семейство Debian, Ubuntu, RHEL)Дистрибутив и выПроверьте уведомления безопасности дистрибутива о исправленном пакете и установите его. Дистрибутивы переносят только исправление, поэтому их номера версий не совпадают с номерами upstream PHP
Общий хостингПровайдерПроверьте версию PHP каждого сайта в панели управления, спланируйте переход, если стоит 8.1 или старше, и читайте уведомления провайдера на его официальном сайте
PHP во встроенных продуктах или устройствахПроизводительПроверьте уведомления безопасности производителя (возможно, вы не увидите PHP внутри)

Кнопка обновления в WordPress или Laravel не обновляет сам PHP. Обновление приложения и обновление PHP — разные задачи.

Как безопасно проверить версию PHP

1

Если можете войти на сервер, используйте командную строку

Если у вас есть доступ по shell, эта команда покажет версию PHP.

php -v

Однако это версия PHP для командной строки (CLI). PHP, который обслуживает ваш сайт (PHP-FPM или модуль Apache), может быть другой версией. Нередко на одном сервере установлены и 8.2, и 8.4. Проверьте веб-часть одним из способов ниже или по имени службы PHP-FPM (например, php8.4-fpm).

2

В WordPress используйте «Состояние сайта»

В панели WordPress откройте «Инструменты», затем «Состояние сайта», вкладку «Информация» и разверните раздел «Сервер». Там показана версия PHP, реально работающая на сайте, так что её может проверить любой администратор без входа на сервер.

3

На общем хостинге используйте панель управления

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

4

Не оставляйте страницу phpinfo() в открытом доступе

Один из способов увидеть версию — поместить в публичный каталог файл, вызывающий phpinfo(), но эта страница показывает версию PHP, конфигурацию и внутренние данные сервера. Это даёт злоумышленнику полезные сведения для выбора цели, поэтому удалите её сразу после использования. Если достаточно трёх способов выше, не создавайте её вовсе. Как находить забытые файлы, описано в статье Секретные файлы, оставленные в публичных каталогах.

Перед обновлением

1

Составьте список сайтов и серверов

Для каждого сайта в одной таблице запишите, на каком сервере он находится, версию PHP (CLI и веб), кто обновляет PHP (вы, провайдер или подрядчик) и контакты владельца. Включите тестовые сайты и забытые сайты, которые всё ещё доступны публично. Именно забытые сайты чаще всего пропускают при обновлениях. Способ описан в чек-листе инвентаризации безопасности.

2

Сделайте резервные копии

Сохраните файлы и базы данных, чтобы можно было откатиться, если обновление сломает сайт. Храните копию вне сервера и убедитесь, что её можно восстановить (основы резервного копирования и восстановления).

3

Определите окно обслуживания и порядок действий

Решите, когда будете обновлять (в том числе в ночное время), кто будет это делать и как вы сообщите об этом пользователям. Для собственных серверов запишите команды обновления, службы для перезапуска и способ проверки результата. Если сервер ведёт подрядчик или агентство, сегодня же уточните, кто и когда обновляет его.

4

Для ветки с истекшим сроком поддержки спланируйте миграцию

По данным php.net, поддержка PHP 8.1 закончилась 31 декабря 2025 года, как и для 8.0 и более ранних версий. Согласно политике поддержки проекта PHP, ветки с истекшим сроком поддержки не получают релизов безопасности. В этот раз официального релиза тоже не было (только минимальные патчи исходного кода для 7.4, 8.0 и 8.1); спланируйте переход на поддерживаемую версию, 8.2–8.5. Поддержка безопасности для 8.2 также заканчивается 31 декабря 2026 года, поэтому если вы переходите сейчас, более безопасная цель — 8.3 или новее.

Не спешите с неофициальными «исправляющими» плагинами и обходными настройками

До выхода исправления начинают распространяться неофициальные плагины и изменения конфигурации, которые якобы блокируют проблему. Методы, которых нет в официальном объявлении, невозможно проверить. Единственное настоящее исправление — исправленный релиз PHP (или исправленный пакет вашего дистрибутива). Правила WAF (межсетевого экрана веб-приложений) могут выиграть время, но не защищают трафик, который попадает на сервер в обход WAF.

Обновление до исправленной версии

Исправленные версии: 8.5.12, 8.4.27, 8.3.36 и 8.2.35 (выпущены 21 октября 2026 года). Если вы установили PHP из пакетов ОС, используйте обновлённые пакеты, которые предоставляет ваш дистрибутив.

1

Обновитесь до исправленной версии своей ветки

Проверьте объявление о выпуске на php.net и ChangeLog, чтобы узнать исправленную версию вашей ветки (8.2, 8.3, 8.4 или 8.5), и обновитесь до неё или более новой. Если вы используете пакеты дистрибутива, проверьте уведомления безопасности дистрибутива (Debian, Ubuntu, Red Hat и других) о версии исправленного пакета. Для Docker загрузите и пересоберите образ, когда опубликуют исправленные теги.

2

Перезапустите PHP-FPM и Apache

Обновление пакета не меняет уже запущенные процессы PHP. Перезапустите PHP-FPM (например, php8.4-fpm) или Apache, если вы используете его модуль PHP, чтобы загрузился новый PHP.

3

Проверьте настройки сессий для третьей проблемы (CVE-2026-115560)

Эта проблема остаётся даже после перехода на релизы от 21 октября. Проверьте две вещи.

  • Задаёт ли конфигурация (php.ini и т. п.) session.serialize_handler со значением php_binary или php_serialize, и переключает ли код приложения его на php с помощью ini_set() (быстрый способ найти это — поиск session.serialize_handler в вашем коде)
  • Включён ли по-прежнему session.upload_progress.enabled (по умолчанию он включён; php -i в CLI может отличаться от веб-части, поэтому проверьте также пул PHP-FPM и конфигурацию PHP, обслуживающего сайт)

Если применимы оба условия или вы не можете определить это, установите session.upload_progress.enabled=0 до следующего регулярного релиза. Задайте значение там, где оно читается при запуске, например в php.ini, в пуле PHP-FPM или в конфигурации веб-сервера, и перезапустите все рабочие процессы (в объявлении от 21 октября рекомендуется задать session.upload_progress.enabled=0 административно и перезапустить все рабочие процессы). Эта функция показывает ход загрузки файлов; если ваш сайт её использует, после изменения проверьте, что она по-прежнему работает. Если вы уже отключили её как временную меру по объявлению от 21 октября, оставьте как есть. Среди японских хостингов Heteml и Lolipop уже отключили эту функцию.

4

Проверьте версию и в CLI, и в вебе

Помимо php -v, используйте «Состояние сайта» WordPress или статус службы PHP-FPM, чтобы убедиться, что PHP, обслуживающий сайт, теперь имеет исправленную версию. На серверах с несколькими установленными версиями PHP проверьте все.

5

Убедитесь, что сайт работает и ничего не выглядит подозрительно

Проверьте ключевые страницы, вход, контактные формы и платежи. Если вы опасаетесь, что сайт был атакован до исправления, ищите неизвестные файлы, лишние учётные записи администратора и искажение страниц. Крупный облачный провайдер зафиксировал попытку эксплуатации 17 октября, за четыре дня до раскрытия, и рекомендует проверять начиная минимум с этой даты. В предупреждении JPCERT/CC также перечислено, что искать. Как проверять, описано в статье Как проверить, был ли скомпрометирован ваш сайт или сервер.

Для пользователей общего хостинга

На общем хостинге провайдер устанавливает и управляет PHP на сервере. Пользователи не могут самостоятельно установить исправленную версию.

Что делает провайдер

  • Обновляет PHP на серверах до исправленной версии
  • При необходимости применяет временные защитные меры или экстренное обслуживание
  • Публикует статусы на официальном сайте и в социальных сетях

Что делаете вы

  • Проверяете версию PHP, выбранную для каждого домена, в панели управления
  • Если стоит 8.1 или старше, тестируете и затем переходите на более новую версию
  • Читаете уведомления провайдера на официальном сайте, а не по ссылкам из писем
  • Также поддерживаете в актуальном состоянии ядро WordPress, плагины и темы

Экстренное обслуживание на стороне провайдера может на время сделать панель управления недоступной. Выполните свои проверки заранее, чтобы не оказаться в ситуации, когда нужно менять версию PHP именно в это окно.

Ответы провайдеров (подтверждено этим сайтом по состоянию на 02:15 UTC 23 октября 2026 года)

Многие провайдеры сообщают, что завершили применение исправления. По состоянию на 02:15 UTC 23 октября (11:15 JST) KAGOYA не объявила о завершении. CPI просит клиентов на версиях без исправленного релиза применить меры защиты или перейти на исправленную версию. Уведомлений о PHP от Rakko Server или WADAX найдено не было. Время ниже указано по JST.

ПровайдерОфициальное уведомлениеЧто сказано
Xserver (Япония)Уведомление о временной приостановке официальных сайтов и панелей управления как превентивной меры безопасности (статус на 20:10 22 октября, на японском)Применены официальные исправления или собственные исправления для каждой предлагаемой версии PHP. Применение завершено для всех целевых серверов: PHP 8.2–8.5 — в 06:45 22 октября, 7.4–8.1 — в 12:00 и 5.6–7.3 — в 14:00. Для PHP 5.5 и более ранних патчи всё ещё «создаются и проверяются». С 20:10 сервисные сайты открываются поэтапно; официальные сайты, панели управления, веб-почта, API/MCP и контактная форма работают (некоторые функции, например старая веб-почта, всё ещё на обслуживании). В зависимости от использования некоторым клиентам могут потребоваться дополнительные действия. Сообщается, что действие не связано с несанкционированным доступом
Sakura Rental Server (Япония)Статус реагирования на уязвимости PHP (22 октября, на японском)Исправление применено ко всем версиям PHP, доступным в панели управления; срочных действий клиентов не требуется. Также предлагается перейти на последнюю поддерживаемую версию PHP. Веб-почта, используемая некоторыми сервисами, восстановлена в 13:45 22 октября, phpMyAdmin — в 15:15 (уведомление о обслуживании). Экстренное обслуживание от 21 октября (n-2697) завершилось в 22:30 21 октября
mixhost (Япония)[Завершено] Реагирование на критические уязвимости PHP (22 октября, на японском)Пакеты исправлений применены на всех серверах примерно в 10:18 22 октября, охватывая PHP 5.2–8.5. Номера версий не меняются (например, 8.4.26 остаётся 8.4.26). Действий клиентов не требуется. Обслуживание «Моей страницы» с 22:10 21 октября также завершено
ColorfulBox (Япония)Уведомление (22 октября, на японском)Превентивные меры защиты и обновление до исправленных версий завершены на всех серверах (общих, бизнес, Tada Server и выделенных) к утру 22 октября, включая 7.4, 8.0 и 8.1. Обновление выполнено на месте с сохранением используемой вами версии PHP; действий клиентов не требуется
XREA, VALUESERVER, CORESERVER, One Rental Server (Япония)XREA, VALUESERVER, CORESERVER V1 / V2, One (на японском)Все пять завершены. XREA, VALUESERVER и CORESERVER V1 завершили в 00:50 22 октября, а в обновлённых уведомлениях сказано, что исправлены все предлагаемые версии PHP (5.3–8.5). One Rental Server завершил в 10:20 (5.6–8.5), CORESERVER V2 — в 11:13 (5.2–8.5). Пользователям менять версии PHP не нужно
Heteml (Япония)Обслуживание, связанное с уязвимостями PHP, завершено, и как всё проходило, [Завершено] уведомление об обслуживании (18:05 22 октября, на японском)Сайты клиентов вернулись в 11:24 22 октября, все сервисы восстановлены в 18:05. PHP 8.2–8.5 получили официальные исправленные релизы, 7.4, 8.0 и 8.1 — исправления команды PHP для веток с истекшим сроком поддержки, 5.6–7.3 — собственные исправления провайдера на основе официальных. На всех версиях эта мера отключает одну функцию (session.upload_progress); клиентов просят проверить работу сайтов и перейти на 8.2 или новее. До применения исправлений на некоторых серверах сайты были остановлены примерно с 03:05 22 октября
Lolipop (Япония)Обслуживание, связанное с уязвимостями PHP, завершено, и как всё проходило, [Завершено] уведомление об обслуживании (обновлено 16:57 22 октября, на японском)Сайты клиентов вернулись примерно в 13:00 22 октября, всё обслуживание завершено в 16:57. PHP 8.2–8.5 получили официальные исправленные релизы, 7.4, 8.0 и 8.1 — исправления команды PHP для веток с истекшим сроком поддержки, 5.3–7.3 — собственные исправления провайдера на основе официальных. Одна функция (session.upload_progress) отключена на всех версиях; клиентов просят проверить сайты и перейти на 8.2 или новее. До применения исправлений на некоторых серверах сайты были остановлены примерно с 03:09 22 октября
KAGOYA (Япония)Влияние уязвимостей PHP на её сервисы (обновлено 18:15 22 октября, на японском)Для арендуемых серверов (PHP 7.4 и 8.1–8.5) сообщалось, что обновление до исправленных версий выполняется и должно завершиться в 24:00 22 октября. По состоянию на 11:15 23 октября уведомления о завершении не найдено. Для управляемых выделенных серверов, общего и WordPress-хостинга постоянное исправление всё ещё организуется, и клиентов просят рассмотреть временное отключение сайтов (переход на страницу обслуживания) или ограничение доступа как промежуточную меру. В её обновлении в 10:35 сказано, что ущерба, такого как атаки или утечки данных, не подтверждено. С 14:15 22 октября также проводится обслуживание безопасности веб-почты, сайта для участников и панелей управления, срок окончания не указан
ConoHa WING (Япония)Реагирование на уязвимости PHP завершено (итоговый отчёт) (22 октября, на японском)Патчи безопасности применены ко всем серверам по состоянию на 20:45 22 октября, когда также завершилось экстренное обслуживание. Патчи применены ко всем предлагаемым версиям PHP путём применения только исправления без повышения версии, поэтому WordPress «Состояние сайта» и подобные экраны могут всё ещё показывать старый номер (например, 8.5.11). Клиентам менять версии не нужно. Веб-почта и файловый менеджер вернулись примерно в 18:30, phpMyAdmin также работает
Onamae.com Rental Server (Япония)Реагирование на уязвимости PHP завершено (22 октября, на японском)Содержание то же, что у ConoHa WING: патчи применены по состоянию на 20:45 22 октября (тарифы Basic, RS Plan и AI Homepage Pack). Только исправление внесено во все предлагаемые версии PHP, поэтому отображаемый номер версии может остаться прежним. Клиентам менять версии не нужно. Веб-почта и файловый менеджер вернулись примерно в 18:30, phpMyAdmin также работает
CPI (Япония)Уведомление о приостановке сервисного сайта и панелей управления из-за уязвимостей PHP (обновлено 09:55 23 октября, на японском)Версии, для которых доступен последний патч, готовы (например, 8.2 и 8.3 на SV-Basic, 8.2–8.4 на Business Standard). Для остальных версий клиентов просят рассмотреть применение мер защиты и переход на исправленную версию PHP (на более старых тарифах — рассмотреть меры защиты). Сервисный сайт вновь открыт в 21:00 22 октября, панель управления — примерно в 17:00; защищённый файловый менеджер и некоторые другие инструменты ожидаются после 30 октября. Сообщается, что несанкционированный доступ или атаки, использующие уязвимости, не подтверждены
Rakko Server (Япония)Официальный сайт (на японском)Сервисный сайт был остановлен с 19:00 21 октября в качестве меры предосторожности (сообщалось, что несанкционированного доступа не обнаружено). Сайт работает, но уведомлений о PHP по состоянию на 11:15 23 октября не найдено
WADAX (Япония)Официальный сайт (на японском)При проверке 22 октября весь сайт был приостановлен в целях безопасности до подтверждения её обеспечения. По состоянию на 11:15 23 октября сайт работает, но уведомлений о PHP не найдено

Провайдеры формулируют уведомления о завершении по-разному. Из уведомления вашего провайдера выясните, какие версии PHP охвачены и нужно ли вам что-то делать. Некоторые провайдеры, такие как ConoHa WING, Onamae.com и mixhost, применили только исправление, поэтому номер версии PHP не меняется. Не считайте сайт неисправленным только по номеру; смотрите уведомление провайдера. Уведомления других провайдеров будут добавлены после подтверждения.

Остерегайтесь поддельных писем от имени вашего хостинга

Когда в новостях появляется уязвимость или экстренное обслуживание, становятся чаще поддельные письма от имени хостинг- или доменных провайдеров («войдите снова для срочного обслуживания», «ваша учётная запись будет приостановлена»). Не входите по ссылкам из писем. Проверяйте через официальный сайт, который вы сохранили в закладках, или официальный аккаунт провайдера в социальных сетях. Как распознавать такие письма, описано в статье Что такое фишинг. Как готовиться к взлому самого провайдера, описано в статье Когда ваш хостинг-провайдер подвергся взлому.

Сообщения до выпуска

Официальное объявление от 21 октября подтвердило идентификаторы CVE (CVE-2026-109618, CVE-2026-109619) и то, что обе уязвимости — это уязвимости удалённого выполнения кода (RCE). В таблице ниже показано, что сообщалось до выпуска; эксплуатация в реальных условиях пока официально не подтверждена.

До выпуска СМИ и компании по безопасности передавали несколько утверждений. Ни одно из них не было официальным заявлением команды безопасности PHP. Этот сайт не менял рекомендуемые шаги на их основании.

УтверждениеИсточникСтатус
Подробности уязвимостей утекли до запланированного выпускаКомпания по безопасности (в разговоре с новостным изданием)Не подтверждено
Обе — уязвимости удалённого выполнения кода (RCE)Компании по безопасности и CERT-EU (CSIRT для институтов ЕС)Подтверждено объявлением от 21 октября
Идентификаторы CVE (CVE-2026-109618, CVE-2026-109619)Компании по безопасности, СМИ, CERT-EUПодтверждено объявлением от 21 октября
Затронут широкий диапазон начиная с PHP 5Компании по безопасности, CERT-EUНе подтверждено (рекомендации GitHub охватывают версии до каждого исправленного релиза без указания нижней границы; патчи предоставлены для 7.4/8.0/8.1). В предупреждении IPA от 22 октября приводится мнение участвовавшей в исследовании компании по безопасности о том, что затронуты PHP 5.4 и более новые версии
Эксплуатация не наблюдаласьКомпания по безопасности (в разговоре с новостным изданием)Мнение самого источника
Зафиксированы признаки атакРуководитель провайдера CDN, другая компания по безопасности (со ссылкой на отчёты партнёров-хостингов) и крупный облачный провайдерПровайдер CDN в публикации в 13:56 UTC сообщил, что зафиксировал атакующий трафик, а крупный облачный провайдер сказал, что видел попытки эксплуатации начиная с 17 октября (см. «После выпуска»). Ни один государственный орган это не подтвердил

Оценки эксплуатации различаются в зависимости от источника. В предварительном уведомлении от 21 октября IPA сообщила, что на тот момент не подтвердила атак с использованием этих уязвимостей. CISA также сообщила в предупреждении от 21 октября, что на момент публикации эксплуатации не наблюдала. Крупный облачный провайдер, напротив, заявляет, что до раскрытия, 17 октября, зафиксировал попытку эксплуатации. Начата эксплуатация или нет, действие одно и то же: обновитесь до исправленной версии сейчас.

Позиция этого сайта: сегодня вы решаете, кто обновляет и когда

Исправленные версии уже вышли. Остаётся решить, кто и когда обновит систему, и сделать это. Обычный пробел — не технический, а связанный с ответственностью. Сайт, созданный агентством, VPS, настроенный человеком, который уже ушёл, тестовый сервер, о котором никто не помнит: PHP без назначенного владельца дольше всего остаётся устаревшим. Как оценивать серьёзность, описано в статье Как расставлять приоритеты уязвимостей (CVSS, EPSS, KEV), а действия после раскрытия — в статье Что делать, когда опубликована уязвимость.

Хронология

  1. 24 сентября 2026

    Выпущены релизы безопасности PHP 8.5.11, 8.4.26, 8.3.35 и 8.2.34 (последние версии на момент уведомления).
  2. 17 октября (объявлено 21 октября)

    Honeypot-системы крупного облачного провайдера фиксируют попытку эксплуатации за четыре дня до раскрытия.
  3. 20 октября

    Команда безопасности PHP объявляет на php.net о релизе безопасности на 14:00 UTC 21 октября. Обе уязвимости оцениваются в 9.2 по CVSS v4.0. В тот же день сообщается, что компания по безопасности сказала новостному изданию, что подробности утекли.
  4. 21 октября

    IPA публикует уведомление «подготовьтесь заранее». Xserver приостанавливает доступ к своим официальным сайтам и панелям управления с 16:00 JST.
  5. 21 октября

    Команда безопасности PHP выпускает 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а также рекомендацию по безопасности. В ней говорится, что CVE-2026-109618 и CVE-2026-109619 могут обе позволить выполнить удалённый код без аутентификации, и всех призывают немедленно обновиться.
  6. 21 октября

    CISA выпускает предупреждение с призывом к немедленной установке исправлений и сообщает, что на момент публикации эксплуатации не наблюдала.
  7. 22 октября

    Xserver (8.2–8.5), Sakura, mixhost, ColorfulBox, сервисы группы Value Domain, Heteml, Lolipop и другие объявляют, что исправление применено. JVN публикует JVNVU#99905564, IPA выпускает предупреждение о мерах против уязвимостей PHP, а JPCERT/CC — своё предупреждение (JPCERT-AT-2026-0033).
  8. 22 октября (вечер, JST)

    ConoHa WING и Onamae.com сообщают, что патчи применены по состоянию на 20:45 JST. Xserver завершил работу с PHP 5.6–8.5 к 14:00 JST и открывает официальные сайты с 20:10 JST. KAGOYA сообщает, что ожидает завершения работ на арендуемых серверах в 24:00 JST.
  9. 23 октября

    Команда безопасности PHP раскрывает третью проблему (CVE-2026-115560), которую выпуски от 21 октября не исправляют. Она называет проблему маловероятной на практике и рекомендует установить session.upload_progress.enabled=0 до следующего регулярного релиза.

Источники (открытые данные)

Факты в этой статье основаны на следующей открытой информации. Сведения, которые PHP официально не публиковал (например, эксплуатация в реальных условиях), приписаны СМИ или компаниям по безопасности и отмечены как не подтверждённые.

  • Команда безопасности PHP, «Рекомендация по безопасности: критические уязвимости удалённого выполнения кода, обновитесь сейчас» (21 октября 2026) — php.net
  • Команда безопасности PHP, «Информационная рекомендация: прогресс загрузки сессии» (CVE-2026-115560, 23 октября 2026) — php.net
  • Рекомендация безопасности GitHub для CVE-2026-109618 — github.com
  • Рекомендация безопасности GitHub для CVE-2026-109619 — github.com
  • ChangeLog (8.5.12, 8.4.27, 8.3.36, 8.2.35) — php.net
  • PHP, «Предстоящий критический релиз по безопасности PHP» (20 октября 2026) — php.net
  • Главная страница PHP (последние версии на тот момент: 8.5.11, 8.4.26, 8.3.35, 8.2.34) — php.net
  • PHP, «Поддерживаемые версии» — php.net
  • PHP, «Неподдерживаемые ветки» (окончание срока поддержки 8.1: 31 декабря 2025) — php.net
  • Рекомендации безопасности php-src (GitHub) — github.com
  • IPA, уведомление о необходимости подготовиться заранее к релизу безопасности PHP (21 октября 2026, на японском) — ipa.go.jp
  • IPA, «Меры против уязвимостей PHP (CVE-2026-109618, CVE-2026-109619: PHP2shell)» (22 октября 2026, на японском) — ipa.go.jp
  • JVN, JVNVU#99905564 о нескольких уязвимостях PHP, позволяющих выполнить произвольный код (22 октября 2026, на японском) — jvn.jp
  • JPCERT/CC, предупреждение о нескольких уязвимостях PHP (CVE-2026-109618, CVE-2026-109619) (JPCERT-AT-2026-0033, 22 октября 2026, на японском) — jpcert.or.jp
  • CISA, «Критические уязвимости PHP требуют немедленной установки исправлений» (21 октября 2026) — cisa.gov
  • Xserver Inc., уведомление о временной приостановке как превентивной мере безопасности (22 октября 2026; статус на 20:10 JST, на японском) — xserver.ne.jp
  • Группа разведки угроз крупного облачного провайдера: попытки эксплуатации начиная с 17 октября, до раскрытия (21 октября 2026) — aws.amazon.com
  • Ответ разработчика команды безопасности PHP на утверждение, что исправление неполное (22 октября 2026) — openwall.com
  • Уведомления хостинг-провайдеров о завершении работ: ConoHa WING / Onamae.com / Lolipop / Heteml (все от 22 октября 2026, на японском)
  • CERT-EU, «Рекомендация по безопасности 2026-018: критические уязвимости PHP» (источник неподтверждённых утверждений) — cert.europa.eu
  • Сообщение СМИ: рассказ компании по безопасности об утечке и её мнение, что эксплуатация не наблюдалась (BleepingComputer, 20 октября 2026) — bleepingcomputer.com
  • Сообщение СМИ: мера защиты для третьей проблемы (CVE-2026-115560) (BleepingComputer, 23 октября 2026) — bleepingcomputer.com
  • Предупреждение компании по безопасности: сообщения об атаках от хостинг-партнёров (21 октября 2026) — patchstack.com
  • Публикация руководителя провайдера CDN: ранние атаки и правила WAF (21 октября 2026; приведено в предупреждении выше) — x.com
  • Быстрый отклик компании по безопасности: эксплуатация в реальных условиях на системах партнёров не наблюдалась (по состоянию на 21 октября 2026) — huntress.com
  • Материалы компаний по безопасности (сообщённые идентификаторы CVE, тип и охват) — sansec.io / tenable.com
  • Уведомления безопасности дистрибутивов: Debian security-tracker.debian.org / Ubuntu ubuntu.com / Red Hat access.redhat.com (RHEL 8 php:8.2: RHSA-2026:87073)
  • Официальный образ Docker (php) — hub.docker.com

История обновлений

2026-10-25: Добавлена третья проблема, раскрытая командой безопасности PHP 23 октября (CVE-2026-115560, не исправлена выпусками от 21 октября): её условия, мера защиты (session.upload_progress.enabled=0) и запланированное исправление, а также шаг для администраторов по проверке настроек. Обновлены краткое описание, блок статуса, FAQ, хронология и источники.
2026-10-23 (02:15 UTC): Добавлено сообщение крупного облачного провайдера о попытках эксплуатации начиная с 17 октября (неясно, были ли успешные), сообщения японских провайдеров о обращениях, похожих на попытки использовать уязвимости (ущерб не подтверждён), и то, что подтверждённых взломов не объявлено; добавлен совет проверять логи начиная с 17 октября. Добавлен ответ разработчика команды безопасности PHP о том, что сообщение о «неполном исправлении» касается несвязанной проблемы. Обновлены пакеты ОС (Debian sid исправлена, RHEL 9 php:8.4 всё ещё без исправления, для RHEL 6 исправление не планируется) и статус хостингов (ConoHa WING, Onamae.com, Lolipop и Heteml завершили; Xserver завершил PHP 5.6–7.3; версии, охваченные сервисами группы Value Domain; статус KAGOYA и CPI).
2026-10-22 (04:45 UTC): Заголовок изменён на формат срочной новости; добавлены предупреждение IPA, предупреждение JPCERT/CC (JPCERT-AT-2026-0033), JVNVU#99905564 и предупреждение CISA. Обновлены сообщения об эксплуатации (по-прежнему без подтверждённых взломов), пакеты ОС (добавлен RHEL 8 php:8.2; RHEL 9 php:8.4 и development-ветки Debian в ожидании), официальные образы Docker и статус завершения работ на общем хостинге (Xserver, Sakura, mixhost, ColorfulBox, сервисы группы Value Domain, Heteml и другие).
2026-10-21 (21:30 UTC): Обновлены сообщения об эксплуатации (зафиксированы попытки, подтверждённых взломов нет), исправленные пакеты поставщиков ОС, официальные образы Docker уже исправлены, оценка NVD, неподтверждённое утверждение о неполном исправлении и обновления хостингов (Xserver начал применять исправления, добавлен WADAX).
2026-10-21 (14:30 UTC): Добавлено сообщение провайдера CDN о зафиксированном атакующем трафике, исправленные пакеты Ubuntu (USN-8948-1), записи NVD и статус официальных образов Docker.
2026-10-21 (14:10 UTC): Добавлен статус после выпуска (время выпуска, затронутые версии, воздействие, подтверждённое в рекомендациях, отсутствие официальных данных об эксплуатации, пакеты ОС, официальные образы Docker, remirepo) и обновления хостингов после 21:00 JST (добавлены CPI и mixhost, FAQ Xserver, завершение работ Sakura).
2026-10-21 (после выпуска): Учтено объявление команды безопасности PHP от 21 октября (исправленные версии, идентификаторы CVE, описание уязвимостей, кто под угрозой, как обрабатываются 8.1 и более ранние, временные меры); переписаны заголовок и ключевой вывод.
2026-10-21: Первая версия, основанная на уведомлении команды безопасности PHP от 20 октября, предварительном уведомлении IPA и уведомлении Xserver. Идентификаторы CVE, затронутые версии и номера исправленных версий будут добавлены после выпуска.

Что читать дальше

Последние срочные сообщения

FAQ

QЧто произошло?
A

21 октября 2026 года команда безопасности PHP выпустила PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, которые устраняют две критические уязвимости, позволяющие выполнять удалённый код без аутентификации (CVE-2026-109618 и CVE-2026-109619, обе с оценкой CVSS v4.0 9.2), и призвала всех пользователей немедленно обновиться. О выпуске она объявила днём раньше, 20 октября.

QЗатронут ли мой сайт?
A

Команда PHP говорит, что под угрозой находятся все установки PHP, обслуживающие веб-запросы: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed, при этом наибольший риск у mod_php. Для сайтов, работающих на PHP (WordPress, Laravel, EC-CUBE и других), проверьте версию PHP и обновите её, если она старше исправленных версий (8.5.12, 8.4.27, 8.3.36, 8.2.35).

QЯ пользуюсь общим хостингом. Нужно ли что-то делать?
A

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

QУ меня PHP 8.1 или более ранней версии, срок поддержки которой истёк. Будет ли исправление?
A

Команда PHP не выпускала официальных обновлений для 8.1 и более ранних версий. Учитывая серьёзность проблемы, она предоставила минимальные патчи исходного кода для 7.4, 8.0 и 8.1, предназначенные для тех, кто собирает PHP из исходников. Дистрибутивы и поставщики долгосрочной поддержки могут выпустить собственные исправления, поэтому уточните у своего поставщика или перейдите на поддерживаемую версию (8.2–8.5). Поддержка 8.2 также заканчивается 31 декабря 2026 года.

QАтаки уже происходят?
A

Команда PHP ссылается на продемонстрированный эксплойт против mod_php, в котором запрос без аутентификации запускает атаку до выполнения кода приложения, однако в её объявлении не сказано, фиксировалась ли эксплуатация в реальных условиях. CISA сообщила, что на момент публикации эксплуатации не наблюдалось. Крупный облачный провайдер заявил, что его honeypot-системы зафиксировали попытки эксплуатации начиная с 17 октября, за четыре дня до раскрытия, но неясно, были ли какие-либо из них успешными. Некоторые японские хостинг-провайдеры сообщают, что видели обращения, похожие на попытки использовать эти уязвимости, но никакого несанкционированного доступа или утечки данных не подтверждено. Поскольку подтверждённых взломов объявлено не было, этот сайт считает эксплуатацию неподтверждённой. Если вы проверяете логи, охватите период с 17 октября.

QЧто делать с третьей проблемой, раскрытой 23 октября (CVE-2026-115560)?
A

Она не исправлена выпусками от 21 октября (8.5.12, 8.4.27, 8.3.36, 8.2.35). По словам команды PHP, она может привести к выполнению кода только если в конфигурации задано session.serialize_handler со значением php_binary или php_serialize, приложение переключает его на php во время выполнения с помощью ini_set перед вызовом session_start, и при этом остаётся включённым отслеживание прогресса загрузки сессии (session.upload_progress). Команда считает это маловероятным на практике, но рекомендует установить session.upload_progress.enabled=0 до следующего регулярного релиза. Если вы уже установили эту настройку как временную меру по объявлению от 21 октября, оставьте её, дополнительных действий не требуется. Затронутые версии и оценка CVSS не опубликованы, сообщений об эксплуатации нет.