PHP2Shell: критические уязвимости PHP и способы их устранения

20 октября 2026 года команда безопасности PHP сообщила о двух критических уязвимостях, каждая из которых получила оценку 9,2 из 10 по шкале CVSS v4.0. Выпущенные 21 октября экстренные обновления устраняют уязвимости CVE-2026-109618 и CVE-2026-109619, известные под общим названием PHP2Shell.

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

Действуйте немедленно

• Используете PHP 8.2–8.5? Незамедлительно обновитесь до исправленной версии своей ветки: 8.2.35, 8.3.36, 8.4.27 или 8.5.12.
• Используете PHP 5.x–8.1? Эти версии больше не поддерживаются официальным проектом PHP. Ограничьте доступ к уязвимым системам, проверьте наличие исправлений от поставщиков и запланируйте миграцию на PHP 8.4 или 8.3. PHP 8.2 можно рассматривать только как временное решение: поддержка безопасности этой ветки завершится 31 декабря 2026 года.
• Не удается установить обновления немедленно? Ограничьте доступ к уязвимым системам из интернета и настройте временные меры защиты, включая правила WAF (межсетевого экрана веб-приложений). Эти меры снижают риск атак, но не заменяют установку исправлений безопасности.

Текущая ситуация: зафиксированы попытки эксплуатации PHP2Shell. По данным Amazon Threat Intelligence, первая попытка атаки была обнаружена 17 октября 2026 года — за четыре дня до выпуска исправлений. Cloudflare также сообщила об атаках, включая попытки обхода механизмов защиты WAF.

Национальный центр кибербезопасности Великобритании (NCSC) рекомендует рассмотреть возможность временного отключения уязвимых систем, если оперативно установить исправления или реализовать компенсирующие меры защиты невозможно. В первую очередь следует проверить все доступные из интернета системы на базе PHP и проанализировать журналы на предмет подозрительной активности, начиная с 17 октября 2026 года.

Что такое PHP2Shell и чем она опасна?

PHP2Shell — общее название двух критических проблем безопасности в среде выполнения PHP: CVE-2026-109618 и CVE-2026-109619. Обе позволяют злоумышленникам выполнять произвольные команды на сервере без аутентификации и связаны с ошибками управления памятью при обработке веб-запросов.

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

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

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

Обновление безопасности PHP: какие версии затронуты и в каких версиях есть исправления?

Согласно данным Sansec, PHP2Shell затрагивает все версии PHP начиная с 5.4, включая ветки, для которых больше не выпускаются исправления. Согласно официальному уведомлению безопасности PHP, обновления безопасности для PHP 8.2, 8.3, 8.4 и 8.5 были выпущены 21 октября 2026 года.

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

Ветка PHP	Статус	Версия с исправлением	Поддержка безопасности до
8.5	Активная поддержка	8.5.12	31 декабря 2029 г.
8.4	Активная поддержка	8.4.27	31 декабря 2028 г.
8.3	Только исправления безопасности	8.3.36	31 декабря 2027 г.
8.2	Только исправления безопасности	8.2.35	31 декабря 2026 г.
8.1 / 8.0 / 7.4	Поддержка прекращена	Доступны обратные переносы исправлений в исходный код; официальные выпуски отсутствуют	—
7.3 и старше / 5.x	Поддержка прекращена	Официальные исправления от проекта PHP не объявлены	—

Исправленные версии PHP2Shell и официальные сроки окончания поддержки безопасности

Организациям, использующим Debian, Ubuntu, RHEL или услуги управляемого хостинга, следует уточнить у поставщиков, доступны ли исправления безопасности в виде обратных переносов исправлений (backport).

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

Поддержка безопасности PHP 8.2 завершается 31 декабря 2026 года — менее чем через три месяца после публикации информации о PHP2Shell. Для устранения выявленных проблем существующие установки PHP 8.2 необходимо обновить до версии 8.2.35. При этом организациям, планирующим переход с устаревших версий PHP, рекомендуется рассмотреть PHP 8.4, поддержка которого продлится до декабря 2028 года, или PHP 8.3 с поддержкой до декабря 2027 года.

Как реагировать на PHP2Shell в первые 24 часа

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

1. Проведите инвентаризацию установок PHP

Проверьте все производственные серверы и тестовые среды, внутренние приложения, контейнеры Docker, CMS и стороннее программное обеспечение. Чтобы определить версию PHP в командной строке, выполните php -v. При этом учитывайте, что версия PHP, используемая веб-сайтом, может отличаться от версии, установленной в CLI.

2. В первую очередь проверьте системы, доступные извне

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

3. Установите исправления безопасности PHP

Обновите PHP до исправленной версии либо установите проверенное исправление, предоставленное поставщиком. Обязательно проверьте PHP-FPM, модули веб-сервера и образы Docker. Обновление операционной системы или основного сервера не гарантирует обновления PHP внутри контейнеров — их необходимо проверять и обновлять отдельно.

4. Ограничьте доступ, если обновление задерживается

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

5. Не полагайтесь только на изменение конфигурации PHP

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

• session.upload_progress.enabled=0
• memory_limit=-1
• fatal_error_backtraces=0 — для PHP 8.5.

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

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

6. Проверьте систему на признаки взлома

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

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

7. Избегайте запуска непроверенных эксплойтов

Не запускайте общедоступные инструменты для демонстрации эксплуатации уязвимостей (proof of concept, PoC), если их безопасность и надежность не подтверждены. В особенности не следует использовать такие инструменты на производственных серверах. Для проверки статуса исправлений ориентируйтесь на официальные уведомления безопасности и документацию проверенных поставщиков.

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

Используете неподдерживаемые версии PHP (5.x–8.1)? Почему защитить их сложнее?

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

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

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

• Неподдерживаемые версии PHP. Для PHP 5.x–8.1 больше не выпускаются официальные обновления безопасности в рамках стандартной поддержки. Команда безопасности PHP опубликовала минимальные исправления в исходном коде для веток 7.4, 8.0 и 8.1. Исправленные пакеты также могут предоставляться отдельными дистрибутивами Linux и поставщиками коммерческой поддержки. Однако эти меры не заменяют переход на поддерживаемую версию PHP. Организациям следует ограничить доступ к уязвимым системам и запланировать миграцию.
• Устаревшие фреймворки и библиотеки. Старые версии фреймворков, CMS и сторонних пакетов Composer могут быть несовместимы с современными выпусками PHP. Поэтому обновление среды выполнения часто требует одновременного обновления зависимостей приложения.
• Критически важные бизнес-интеграции. Устаревшие приложения могут быть связаны с платежными шлюзами, CRM- и ERP-системами, базами данных и внешними API. Изменения в версии PHP способны нарушить работу этих интеграций и повлиять на повседневные бизнес-процессы.
• Недостаточное покрытие автоматизированными тестами. В устаревших системах часто отсутствуют полноценные наборы автоматизированных тестов. Из-за этого сложнее выявить проблемы совместимости до развертывания обновлений в производственной среде.

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

Как обновить PHP, не нарушив работу приложения

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

Проведите аудит кода и зависимостей

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

Выполните команду composer outdated, чтобы определить, какие зависимости требуют обновления. Убедитесь, что используемые версии Laravel, Symfony, WordPress или Magento поддерживают выбранную версию PHP. Составьте список компонентов, для которых потребуются дополнительные изменения или ручная проверка.

Адаптируйте код к новой версии PHP

Инструмент Rector позволяет автоматизировать часть изменений, необходимых для обеспечения совместимости. Например, он может заменить устаревшие конструкции и функции, использование которых больше не рекомендуется. Это особенно полезно при работе с большими кодовыми базами.

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

Спланируйте поэтапную миграцию

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

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

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

Протестируйте приложение перед обновлением

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

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

Разверните обновление с минимальным простоем

Если архитектура приложения позволяет, используйте стратегии Blue-Green Deployment или Canary Deployment. Они помогают постепенно переводить трафик на обновленную среду и снизить риск масштабных сбоев.

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

Как компаниям предотвратить следующий кризис безопасности PHP?

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

Для этого рекомендуется придерживаться пяти основных принципов.

• Ведите реестр используемых версий PHP. Фиксируйте версии PHP на серверах, в приложениях и контейнерах Docker. Регулярно обновляйте сведения при изменении программного обеспечения или инфраструктуры, чтобы своевременно выявлять устаревшие компоненты.
• Планируйте обновления до окончания поддержки. Регулярно проверяйте официальный график поддержки PHP. Заранее обновляйте фреймворки, библиотеки и другие зависимости, чтобы переход на поддерживаемые версии не пришлось выполнять в экстренном порядке после прекращения выпуска исправлений безопасности.
• Автоматизируйте проверки безопасности. Включите сканирование зависимостей и проверку образов контейнеров в конвейеры CI/CD. Отслеживайте официальные уведомления безопасности, чтобы оперативно выявлять проблемы, затрагивающие используемые версии PHP и связанные компоненты.
• Регулярно обслуживайте приложения и инфраструктуру. Выделяйте ресурсы на установку обновлений безопасности, проверку совместимости и замену устаревших компонентов. Систематическое техническое обслуживание помогает сократить технический долг и упрощает переход на новые версии программного обеспечения.
• Подготовьте план реагирования на инциденты безопасности. Заранее распределите обязанности, задокументируйте порядок установки исправлений и определите процедуры проверки возможных атак. Предусмотрите тестирование обновлений, мониторинг после их установки и восстановление сервисов в случае сбоев.

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

Как СКЭНД помогает обеспечить безопасность и модернизировать PHP-приложения

Компания СКЭНД обладает более чем 25-летним опытом разработки программного обеспечения, объединяет свыше 250 инженеров и реализовала более 900 проектов. Процессы компании сертифицированы по стандартам ISO 9001 и ISO 27001.

СКЭНД предоставляет услуги разработки на PHP, используя Laravel и другие современные веб-технологии. В портфолио компании — система автоматизированного формирования юридических договоров и платформа управления медицинскими курьерскими перевозками. Эти проекты подтверждают опыт СКЭНД в создании бизнес-приложений со сложной архитектурой, множеством зависимостей и внешних интеграций.

Если ваша компания столкнулась с PHP2Shell или использует устаревшие PHP-приложения, СКЭНД предлагает помощь по трем направлениям.

• Оперативное устранение уязвимостей и оценка рисков. Специалисты проведут инвентаризацию установок PHP, включая контейнеры и стороннее программное обеспечение, помогут установить доступные исправления, настроить временные правила защиты WAF и проверить признаки взлома совместно с инженерами DevOps.
• Миграция на современные версии PHP. Команда оценит совместимость приложения, обновит зависимости и подготовит переход на PHP 8.3 или 8.4 в рамках модернизации устаревших приложений. Перед запуском специалисты проведут необходимое тестирование программного обеспечения.
• Постоянная техническая поддержка. Специалисты будут отслеживать уведомления безопасности PHP и используемых фреймворков, устанавливать обновления и заблаговременно планировать миграцию до окончания поддержки текущих версий.

Часто задаваемые вопросы

Что такое PHP2Shell?

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

Какие версии PHP устраняют CVE-2026-109618 и CVE-2026-109619?

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

Затронуты ли PHP 7.4 и 8.1 и будут ли для них выпущены исправления?

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

Может ли WAF или изменение настроек php.ini защитить сайт?

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

Стоит ли переходить на PHP 8.2, 8.3 или 8.4?

Для миграции предпочтителен PHP 8.4 с поддержкой до декабря 2028 года. PHP 8.3 — альтернатива при проблемах совместимости. Поддержка PHP 8.2 заканчивается в декабре 2026 года.