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

Что исправили обновления безопасности PHP от 21 октября

Команда безопасности PHP анонсировала критически важный выпуск 20 октября, а 21 октября опубликовала PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Две уязвимости затрагивают ядро интерпретатора и могут позволить удаленно выполнить код, а в наиболее уязвимой конфигурации атака начинается еще до запуска кода приложения. По заявлению PHP, полноценного обходного решения нет, поэтому установка исправления безопасности необходима.

В пояснениях PHP Foundation к выпуску описаны уязвимости и ответные действия проекта. Официальное уведомление PHP о выпуске содержит рекомендации по обновлению.

Две ошибки безопасности памяти при обработке запросов

• CVE-2026-109618: PHP обеспечивает соблюдение memory_limit через longjmp(), который резко прерывает выполнение. В этот момент данные запроса, например при загрузке в формате multipart, могут быть инициализированы лишь частично. Последующая очистка может обратиться к неинициализированной памяти, содержащей значения, которыми управляет злоумышленник.
• CVE-2026-109619: внутреннее состояние одного запроса может сохраниться после освобождения памяти, на которой оно основано. Следующий запрос, обработанный тем же рабочим процессом, может использовать это устаревшее состояние.

По данным PHP Foundation и php.net, подтвержденные сценарии атаки зависят от конфигурации. Для CVE-2026-109618 в Apache с mod_php запрос без аутентификации может вызвать сбой еще до запуска кода приложения, и полноценное удаленное выполнение кода продемонстрировано при настройках по умолчанию. В PHP-FPM выполнение кода подтверждено через пути на уровне приложения, поэтому риск там зависит от того, что делает само приложение. Для CVE-2026-109619 подтверждены use-after-free и падение рабочего процесса, а автор отчета продемонстрировал выполнение кода на реальном приложении под Apache с mod_php.

php.net относит к группе риска любую установку PHP, обслуживающую веб-запросы, включая PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed, и считает mod_php самой рискованной конфигурацией. Ни одна из приведенных здесь публикаций не описывает единый эксплойт, который одинаково работает против всех этих конфигураций. Обновлять нужно все, но опубликованные данные не показывают для каждой один и тот же путь атаки.

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

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

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

Сведения об эксплуатации уязвимостей быстро меняются

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

Позже CERT-EU сообщила о распространении технических подробностей и первых демонстрационных эксплойтов. Компания watchTowr, работающая в сфере безопасности, сообщила о попытках эксплуатации в своих системах-ловушках с 21 октября, а Brandefense в тот день сообщила об отсутствии подтвержденной эксплуатации. Эти сообщения отражают разные наблюдения и не доказывают массового взлома PHP-систем.

Почему превентивное отключение может быть обоснованным решением

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

Следующие официальные уведомления подтверждают превентивные меры 21 октября. Указано время публикации в Нидерландах, CEST, а не подтвержденное время начала каждого отключения.

Предупреждение NCSC Великобритании рекомендует выявить развернутые среды PHP, обновить их и рассмотреть отключение систем, если немедленно устранить уязвимость невозможно. CERT-EU и киберподразделение ФБР также рекомендовали изоляцию или отключение, когда исправления нельзя установить сразу.

Центральная IT-служба Вашингтонского университета описала на своей официальной странице статуса сервисов подход с сетевой изоляцией: null routing, при котором трафик к системам с уязвимой версией PHP отбрасывается. Системы продолжали работать, данные и настройки не менялись, но до подтвержденного обновления они были недоступны по сети. Для снятия изоляции владельцы должны были предоставить идентифицирующие сведения и номер установленной версии PHP с исправлениями.

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

Удаленное выполнение кода PHP: как компрометация может выйти за пределы процесса

Уязвимости напрямую позволяют выполнить код внутри уязвимого процесса PHP. Доступ за пределы этого процесса зависит от его фактических прав и сетевой доступности других ресурсов. Кража секретов, горизонтальное перемещение и атаки программ-вымогателей - возможные дальнейшие сценарии, а не подтвержденные последствия раскрытых уязвимостей.

Рассмотрим возможный путь атаки через доступный извне клиентский портал. Злоумышленник получает возможность выполнять код от имени служебной учетной записи PHP, затем читает доступные ей файлы конфигурации. Доступный для чтения файл .env может содержать пароль базы данных. Он может открыть доступ к записям клиентов, если база данных принимает подключения с этого сервера.

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

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

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

Управление секретами сокращает число неконтролируемых копий учетных данных. Однако менеджер секретов не может скрыть каждый секрет от процесса, который имеет законное право его получить. Короткоживущие учетные данные и минимальные права ограничивают возможности злоумышленника при краже доступа. Сегментация сети и контроль исходящего трафика ограничивают круг ресурсов, к которым может подключиться скомпрометированный процесс.

Наша инженерная позиция проста: установка исправлений PHP закрывает выявленные уязвимости среды выполнения. Коду приложения, зависимостям и инфраструктуре по-прежнему нужны собственные меры защиты.

Затраты для бизнеса возникают еще до подтверждения взлома

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

Для интернет-магазина контролируемое отключение может прервать оформление и обработку заказов. В ERP или торговой системе решение о восстановлении работы также должно учитывать незавершенные транзакции и сверку данных. Возобновление HTTP-ответов не доказывает, что бизнес-данные остались согласованными.

Если уязвимость была использована, последствия могут выйти за рамки простоя:

• Кража кода и интеллектуальной собственности может раскрыть закрытую бизнес-логику.
• Утечки клиентских данных могут повлечь расследования, договорные споры и обязанности по уведомлению.
• Несанкционированные изменения записей могут исказить остатки на счетах, складские запасы или статусы заказов.
• Украденный доступ к развертыванию может распространить инцидент по цепочке поставки программного обеспечения.
• Кража данных или доступ, позволяющий их уничтожить, могут создать условия для вымогательства и атак программ-вымогателей.

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

Клиентам нужно знать, затронут ли их сервис, кто отвечает за реагирование и когда ждать следующего сообщения. Молчание лишает их возможности управлять собственными обязательствами. Поэтому при проверке поставщика следует оценивать не только технические меры защиты, но и коммуникацию, а также распределение ответственности за инциденты.

Безопасность PHP и GDPR: уведомление о нарушении защиты данных зависит от фактов, риска и роли

Уязвимая версия PHP или превентивное отключение сами по себе не доказывают нарушение защиты персональных данных. GDPR устанавливает постоянные обязанности по обеспечению безопасности. При этом необходимость уведомления зависит от фактического нарушения защиты персональных данных и применимого порога риска. Применимость NIS2 и DORA нужно оценивать отдельно.

Далее приведены практические рекомендации, а не юридическая консультация. Привлекайте юристов и специалиста по защите данных при оценке инцидента.

Требования GDPR к безопасности и основания для уведомления

GDPR устанавливает несколько важных постоянных обязанностей:

• Статья 5(1)(f): защищать целостность и конфиденциальность персональных данных.
• Статья 24: внедрять надлежащие меры со стороны контролера и подтверждать их выполнение.
• Статья 25: обеспечивать защиту данных на этапе проектирования и по умолчанию.
• Статья 32: поддерживать безопасность, соответствующую рискам обработки, включая устойчивость и возможность восстановления.

Своевременная установка исправлений с учетом рисков помогает выполнять эти обязанности. Обнаружение неисправленной среды выполнения требует действий и оценки, но не означает автоматической обязанности направлять уведомление о нарушении защиты данных по GDPR.

Согласно статье 33, контролер должен уведомить надзорный орган без неоправданной задержки и, по возможности, в течение 72 часов после того, как ему стало известно о нарушении защиты персональных данных. Исключение составляют случаи, когда нарушение вряд ли создаст риск для прав и свобод физических лиц. Статья 34, как правило, требует уведомить затронутых лиц, если нарушение с высокой вероятностью создает высокий риск, с учетом предусмотренных в ней исключений.

Нарушение может затрагивать конфиденциальность, целостность или доступность. Поэтому при расследовании нужно оценивать не только кражу, но и несанкционированные изменения, а также потерю доступа к персональным данным.

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

Отраслевые нормы и стандарты безопасности

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

DORA регулирует управление рисками информационно-коммуникационных технологий (ИКТ), отчетность об инцидентах и риски сторонних поставщиков ИКТ для финансовых организаций, на которые распространяется регламент. FinTech-компаниям и компаниям, занимающимся торговлей финансовыми инструментами, нужно оценивать свой регуляторный статус, а не считать, что применимость определяется используемой технологией. Их поставщики ИКТ также могут столкнуться с договорными требованиями, вытекающими из этих обязанностей.

ISO 27001 и SOC 2 задают подходы к подтверждению мер безопасности. Они не являются всеобщими законодательными требованиями и не заменяют доказательств установки исправления в конкретной среде выполнения. У Webdelo нет сертификации ISO 27001 или аудиторского заключения SOC 2.

Где закрепить ответственность за установку исправлений

• SLA и SOW: определяют ответственных за среду выполнения, границы поддержки, целевые сроки реагирования и обязанности при внесении изменений.
• DPA: определяет обязанности обработчика по уведомлению, сотрудничеству и содействию.
• Условия аудита: устанавливают, какие записи и подтверждающие материалы вправе запросить клиенты.
• План реагирования на инциденты: называет ответственных за решения об изоляции, восстановлении и информировании клиентов.

Распространенный пробел - приложение передано заказчику, но обслуживание среды выполнения не предусмотрено соглашением. Клиент может полагать, что этим занимается разработчик, а разработчик - что хостинг не входит в объем работ. Эту неопределенность нужно устранить до следующего выпуска исправлений безопасности.

Как такую границу можно описать, показывает опубликованное соглашение Webdelo об уровне обслуживания для поддержки и сопровождения. В нем код приложения и развертывание отнесены к нашей зоне ответственности, а инфраструктура, которой управляет клиент, - к зоне клиента. Там же закреплено, что клиентов предупреждают об уязвимостях высокого риска еще до подтверждения их эксплуатации. Обязательные условия для каждого проекта фиксируются в SOW.

Как отреагировала команда Webdelo

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

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

Ответственность за среду выполнения нужно обсуждать вместе с вопросами развертывания и хостинга. К этому обсуждению относится и направление DevOps и инфраструктура Webdelo. Постоянная поддержка уменьшает неопределенность, потому что команда уже знает стек и особенности развертывания.

После обновления среды выполнения в CRM-системе стоит заново проверить бизнес-процессы. На корпоративном сайте могут понадобиться проверки форм заявок и подключенных сервисов. Объем проверок должен соответствовать реальным бизнес-функциям продукта.

Техническое руководство нашей команды включает технического директора Webdelo Андрея Попова. Для клиентов важен практический вопрос управления: остается ли техническая ответственность четко определенной после сдачи проекта? Эту ответственность нужно явно закрепить при заказе разработки сайта и последующей поддержки.

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

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

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

1. CTO или руководитель инфраструктуры: определите, какие системы подвержены риску. Сначала составьте список приложений, доступных из интернета, затем внутренних сервисов и продуктов поставщиков со встроенным PHP. Включите контейнеры и приложения на PHP, такие как WordPress, Drupal, Nextcloud и phpMyAdmin.
2. Руководитель эксплуатации: проверьте среду выполнения, которая обслуживает запросы. Проверьте установленные пакеты и активную среду PHP, обрабатывающую веб-запросы. Изучите журнал изменений дистрибутива или поставщика на предмет исправлений, перенесенных из новых версий. Скрытый или устаревший HTTP-баннер не позволяет установить, применено ли исправление.
3. Руководитель разработки: установите исправление. Используйте PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 или более позднюю версию с исправлениями либо проверенную исправленную сборку поставщика. Переведите системы с завершенной поддержкой на поддерживаемую ветку. Проверьте зависимости и установите необходимые обновления безопасности или совместимости.
4. Владелец бизнес-системы и руководитель безопасности: изолируйте все, что остается под угрозой. Уберите неисправленные сервисы из публичных сетей или при необходимости отключите их. Зафиксируйте ответственного за решение и срок устранения уязвимости. Изменение session.upload_progress.enabled не заменяет установку исправлений.
5. Ответственный за выпуск: проверьте изменение и план отката. Перезапустите или замените затронутые рабочие процессы и контейнеры, чтобы исправленная среда действительно использовалась. Проверьте критически важные рабочие сценарии и интеграции. Откат не должен незаметно возвращать публичный доступ к уязвимой среде выполнения.
6. Руководитель безопасности: сохраните доказательства и исследуйте индикаторы. Сохраните журналы веб-сервера и PHP, записи о развертывании и доступную телеметрию процессов. Изучите неожиданные запуски командной оболочки или загрузки файлов, инициированные процессами PHP. Не считайте ни отсутствие находок в журналах, ни подозрительный запрос сами по себе окончательным доказательством.
7. Руководитель реагирования на инцидент: реагируйте на признаки компрометации. Изолируйте затронутые системы и исследуйте доступные из них учетные данные и ресурсы. Замените секреты, если их раскрытие установлено или обоснованно подозревается, и отзовите затронутые сеансы или токены. Ужесточите ограничения прав учетных данных, сегментацию и контроль исходящих подключений.
8. Юристы и ответственные за работу с клиентами: выполняйте требования по отчетности и информируйте. Оцените регуляторные и договорные обязанности с учетом доказательств и применимости норм. Расскажите клиентам, что подтверждено, какие действия выполнены и что еще расследуется.

Следующая команда проверяет исполняемый файл PHP в текущем окружении командной оболочки:

php -v

Результат может отличаться от версии, которую использует PHP-FPM, Apache или контейнер приложения. Зафиксируйте как сведения о соответствующих пакетах, так и среду выполнения, которая фактически обслуживает рабочий трафик. Не публикуйте диагностические данные через общедоступную страницу phpinfo().

Управление уязвимостями в компании должно оставлять проверяемые записи

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

• Подтверждение среды выполнения: активная версия PHP или исправленная сборка пакета для каждой соответствующей среды.
• Подтверждение изменений: дата установки исправления, запись о развертывании и результаты проверок.
• Перечень систем под риском: выявленные приложения и встроенные в продукты поставщиков среды выполнения с четкой отметкой нерешенных вопросов.
• Охват расследования: доступные журналы, сроки их хранения и ограничения мониторинга.
• Решение по учетным данным: заменялись ли секреты и почему было принято такое решение.
• Фиксация ответственности: назначенный ответственный за среду выполнения и коммуникация, соответствующая DPA, SLA и плану реагирования на инциденты.

Тревожные признаки - заявления о версии, основанные только на публичных баннерах, отсутствие назначенного ответственного за обслуживание и утверждения, что обновление PHP делает безопасным все приложение. Еще один признак - партнер не различает оценку подверженности уязвимости и расследование предполагаемого взлома.

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

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

Спокойная реакция начинается с четкой ответственности

CVE-2026-109618 и CVE-2026-109619 требуют срочного устранения уязвимостей среды выполнения, но их раскрытие не доказывает, что каждый PHP-сервис был взломан. Отключения в Нидерландах были превентивными. Приоритет бизнеса - проверить подверженность риску, установить исправление и оценить последствия на основе доказательств.

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