Уязвимость начинается с вопроса: где у нас PHP
21 октября 2026 года команда PHP выпустила экстренные обновления для двух критических уязвимостей — CVE-2026-109618 и CVE-2026-109619. По описанию разработчиков, обе проблемы потенциально позволяют удалённо выполнить код без предварительной аутентификации. Иными словами, атакующему в определённых сценариях не нужны учётная запись, пароль или уже полученный доступ к серверу.
Первая уязвимость связана с обработкой ошибок нехватки памяти, вторая — с сохранением устаревшего глобального состояния между запросами. Риск зависит от версии PHP, конфигурации и способа запуска. Поэтому неверно говорить, что уязвимы все сайты на PHP: наличие языка в инфраструктуре само по себе не означает компрометацию.
Исправления выпущены для веток PHP 8.5, 8.4, 8.3 и 8.2. В перечень затронутых вариантов установки входят PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Временные настройки могут снизить риск отдельных сценариев, но не заменяют полноценное обновление.
Для старых веток ситуация сложнее. PHP 8.1 и более ранние версии больше не поддерживаются самим проектом. При этом некоторые Linux-дистрибутивы и поставщики долгосрочной поддержки могут выпускать собственные backport-исправления — отдельные патчи безопасности для старой версии. Проверять наличие такого исправления нужно у конкретного поставщика, а не предполагать его автоматически.
Почему бизнес может не знать о проблеме
На практике компания редко устанавливает PHP как отдельный продукт и назначает сотрудника ответственным именно за него. Язык может находиться внутри CMS, интернет-магазина, панели управления хостингом, корпоративного портала или стороннего приложения.
Сайт может работать на managed hosting, где обновления формально выполняет провайдер. Интернет-магазин может поддерживаться подрядчиком, а его сервер — находиться в облачной инфраструктуре, о которой маркетинговая или финансовая команда ничего не знает. Наконец, PHP может быть частью контейнерного образа, который был собран несколько месяцев назад и продолжает использоваться в продакшене.
Отсюда главный практический вывод: инвентаризировать нужно не только собственные серверы. В список проверки должны попасть:
- сайты, лендинги и интернет-магазины;
- CMS, плагины и темы;
- PHP-FPM, Apache, LiteSpeed и другие варианты запуска;
- контейнерные образы и шаблоны виртуальных машин;
- панели управления хостингом;
- managed hosting и облачные сервисы;
- подрядчики, которые администрируют веб-приложения;
- резервные и тестовые среды, доступные из интернета.
Если организация не может быстро ответить, где используется PHP, какая там версия и кто отвечает за обновление, её периметр фактически не контролируется.
Как AI изменил первый этап защиты
Обе уязвимости стали примером того, как искусственный интеллект постепенно входит в исследование безопасности open-source-кода. OpenAI сообщала, что одна из проблем была найдена исследовательской компанией Calif с использованием модели GPT-5.6 Sol в рамках инициативы Patch the Planet. Компания Wiz независимо обнаружила и сообщила обе уязвимости.
Эти сведения важны именно в таком сочетании. Нельзя представлять дело так, будто одна модель самостоятельно нашла и устранила критическую дыру. AI мог ускорить анализ больших объёмов кода, поиск необычных состояний памяти и проверку сложных комбинаций поведения. Но подтверждение дефекта, оценка его влияния, подготовка исправления, тестирование совместимости и координация раскрытия потребовали участия исследователей и разработчиков PHP.
Это новая модель работы, а не автоматическая кнопка «починить интернет». Машина помогает быстрее добраться до подозрительного участка кода. Дальше начинаются задачи, в которых особенно важны ответственность и контекст: не сломает ли патч существующие приложения, какие версии нужно поддержать, как предупредить дистрибьюторов и что делать владельцам систем, которые давно никто не обслуживает.
Скорость поиска повышает цену координации
Традиционная цепочка выглядела относительно линейно: исследователь находил ошибку, закрыто сообщал о ней разработчику, команда готовила патч, после чего пользователи устанавливали обновление. AI сокращает время первого этапа. Но чем быстрее обнаружен дефект, тем меньше запаса у всей экосистемы на проверку и массовое обновление.
В случае PHP в цепочке участвуют не только разработчики языка. Это ещё Linux-дистрибутивы, хостинги, CMS, облачные платформы, корпоративные IT-команды и подрядчики. Один и тот же патч должен пройти через множество уровней поставки. Ошибка на любом из них оставляет часть систем на старой версии.
Поэтому современная киберзащита — это не только способность найти уязвимость. Не менее важны закрытые каналы уведомлений, обмен индикаторами компрометации, проверка исправлений, временные правила WAF, контакт с CERT и понятный процесс обновления у клиентов.
Что сделать компании
1. Найти фактические версии
Проверить нужно не только основной сайт, но и все публичные IP-адреса, контейнеры, резервные среды и панели администрирования. Версию следует сопоставить с исправленными ветками и рекомендациями поставщика.
2. Зафиксировать владельца системы
У каждого приложения должен быть конкретный ответственный: внутренний IT-отдел, хостинг-провайдер или подрядчик. Формулировка «это где-то у провайдера» не является планом реагирования.
3. Обновить или ограничить доступ
Приоритет — интернет-доступные системы. Если быстро установить исправление невозможно, временные меры должны быть согласованы с ответственным специалистом: ограничение доступа, усиленный мониторинг или временное отключение сервиса. Такие меры снижают риск, но не заменяют патч.
4. Проверить старые продукты
CMS, плагины и контейнеры могут поставляться со своей версией PHP. Обновление только операционной системы не гарантирует, что приложение перестало использовать уязвимый компонент.
5. Сохранить процедуру на будущее
Следующая критическая проблема в популярном open-source-компоненте появится не обязательно в PHP. Компании, которые сейчас создадут карту зависимостей и понятный процесс обновления, выиграют не только в этой ситуации.
Вывод
История с CVE-2026-109618 и CVE-2026-109619 показывает двойной эффект AI в кибербезопасности. Искусственный интеллект ускоряет поиск ошибок в фундаментальном программном обеспечении, но одновременно сокращает время на реакцию всей индустрии.
Патч всё ещё должен проверить человек. Хостинг всё ещё должен его развернуть. Компания всё ещё должна знать, где находится её PHP. И именно последний пункт для многих организаций окажется самым трудным — не потому, что технология редкая, а потому, что за годы она незаметно встроилась почти во все слои веб-инфраструктуры.
