Что случилось с PHP и при чём здесь «вулнпокалипсис»
PHP работает примерно на 70% сайтов, и две критические уязвимости в нём позволяли удалённо выполнить код на сервере без аутентификации. Организации латали системы в спешке, а часть сайтов временно отключали, пока патч не установлен. Разбор инцидента и его последствий прозвучал в выпуске подкаста Equity на TechCrunch с участием Томера Шварца, CTO направления Exposure Management & AppSec в Wiz.
Баг чинили коллективно. В работе участвовали Wiz (принадлежит Google), OpenAI, исследовательская группа Calif и команда PHP. Такое сочетание участников само по себе показывает масштаб: дыра в открытом проекте задела инфраструктуру, которую поддерживают и коммерческие вендоры, и сообщество.
Вывод, который Шварц доносит до слушателей, звучит резко: ручной патчинг не масштабируется, а волна уязвимостей в устаревшем коде - вопрос времени. Отсюда и термин «вулнпокалипсис»: накопленный годами риск, который AI-инструменты вскрывают быстрее, чем команды успевают реагировать.
Две уязвимости в PHP с CVSS 9.2: что именно нашли
Оценка CVSS 9.2 приводится в публикациях о находке: обе дыры давали возможность удалённо выполнять код без аутентификации на значительной части веба (краткая заметка о находке). Точные CVE-идентификаторы, векторы атаки и детали эксплойта в доступных источниках не раскрываются, поэтому пересказывать их по памяти бессмысленно: без официального бюллетеня это будет догадка.
Одна из двух уязвимостей оставалась на виду больше десяти лет. Эксплуатируемой её сделали изменения в окружении: версии зависимостей, конфигурации, новые сценарии использования кода. Пока условия не совпали, участок выглядел безобидным, и статические анализаторы того времени не видели в нём проблемы.
Второй фактор риска - массовость. Когда дыра затрагивает язык, на котором работает около 70% сайтов, патч становится задачей не одного мейнтейнера, а десятков тысяч администраторов, у каждого из которых свой график обновлений. Именно в этом окне и появляется основная экспозиция.
Почему это называют «Black October» и «вулнпокалипсисом»
«Black October» - обозначение, которое отраслевые обозреватели дали волне уязвимостей в PHP, найденных с помощью AI. Название описывает не один баг, а серию находок, пришедших почти одновременно и заставших команды врасплох.
«Вулнпокалипсис» - метафора накопленного риска в устаревшем коде. Смысл в том, что уязвимости не появляются из ниоткуда: они годами лежат в коде, который никто не перечитывает, и всплывают пачками, как только появляется инструмент, способный их массово проверять.
Скорость меняется измеримо. По данным Европейского агентства по кибербезопасности, приводимым в отраслевой заметке о волне, разрыв между обнаружением уязвимости и её эксплуатацией сократился с лет до месяцев, а в отдельных случаях - до минут. Цифра дана в пересказе, первичный отчёт стоит сверять отдельно, но направление тренда она передаёт точно.
Как AI ускоряет поиск уязвимостей: механика, а не магия
Шварц говорит об этом прямо: без AI Wiz не нашла бы эти баги. Собственный инструментарий компании за выходные проверил десятки гипотез, на которые при ручном переборе ушли бы месяцы (TechCrunch).
Механика выглядит прозаично. Модель читает код, историю коммитов и документацию, затем предлагает гипотезы: где может быть переполнение буфера, неверная проверка прав, гонка при обращении к разделяемой памяти, некорректная обработка входных данных. Дальше в работу вступают обычные инструменты: фаззинг, статический анализ, сборка минимального proof of concept. Агент запускает проверку, читает результат и уточняет гипотезу. Исследователь отбирает то, что стоит показывать вендору.
Anthropic показала, как это выглядит на практике. Внутренняя исследовательская модель искала уязвимости в браузерах и операционных системах, и по итогам команда описала пять цепочек атак, приводивших к удалённому выполнению кода (отчёт Anthropic). Одна из цепочек в Chrome соединяла ошибку в V8, обход песочницы памяти, состояние гонки в CacheStorage и use-after-free в FedCM, что давало выполнение кода вне песочницы. В Safari нашлась цепочка, где JavaScript с любого сайта обходил политику same-origin и получал доступ к истории, cookies и другим данным пользователя.
Итог по Chrome измеримый: 62 CVE назначены и исправлены к версии 156, все с рейтингом critical или high (Anthropic). Шесть десятков дыр в одном браузере за один цикл исследования - это уже другой масштаб работы, чем привычный аудит силами небольшой команды.
Гипотезы, проверка и человеческий надзор: как это работает на практике
Ключевое слово здесь - гипотезы. AI не выдаёт готовый список уязвимостей, он масштабирует черновую работу: чем больше проверенных гипотез, тем выше шанс поймать реальную дыру. Отбор, валидация и приоритизация остаются за человеком, иначе поток ложных срабатываний хоронит полезные находки.
Проблема шума известна по обычным сканерам: в разборе про DevSecOps в эпоху AI-разработки приводится цифра до 80% ложных срабатываний SAST и DAST, которые тормозят релизы. AI-триаж помогает ровно в этом месте: группирует однотипные алерты и объясняет, почему находка похожа на реальную.
В научной литературе для набора сопутствующих задач уже есть термины: AI-агенты безопасности, происхождение доказательств (evidence provenance), человеческий надзор, федеративная координация, permissioned audit и CVE (препринт о будущем раскрытия AI-обнаруженных уязвимостей). Evidence provenance - требование показать, откуда взялась находка: какой запрос, какой вход, какая версия кода, при каких настройках сработало. Без такой цепочки отчёт AI-сканера невозможно воспроизвести, а значит и нельзя нормально починить. Доступный фрагмент работы ограничен введением и списком терминов, развёрнутых выводов о процедурах раскрытия он не содержит.
Почему уязвимость может годами оставаться незамеченной
Код не менялся, менялось окружение. Версии зависимостей обновлялись, конфигурации правились, типичные сценарии использования становились другими. В какой-то момент сочетание условий сложилось, и участок, который десять лет выглядел безопасным, стал эксплуатируемым.
Раньше такую комбинацию находили случайно или не находили вовсе: перебрать все условия для большой кодовой базы вручную нереально. AI-инструмент перепроверяет старый код под новые допущения за часы. Именно это меняет экономику обнаружения: то, что требовало месяцев работы, сжимается до выходных, а стоимость одной проверенной гипотезы падает до уровня, при котором перебор вариантов перестаёт быть роскошью.
Почему ручной патчинг не масштабируется и что такое Exposure Management
Тезис Шварца простой: патчить вручную больше не получается. Причины накапливаются: кода много, находок становится больше, свободных специалистов меньше. Когда AI-сканер выдаёт десятки гипотез за выходные, а команда из двух человек разбирает их неделю, узкое место перемещается из обнаружения в реакцию.
Exposure Management меняет сам вопрос. Вместо «какие CVE у нас в списке» команда спрашивает «что у нас реально доступно из интернета, какой версии, что из этого уже эксплуатируют». Приоритет по экспозиции обычно снимает с повестки большую часть формальных записей в бюллетенях: у них нет ни публичного эксплойта, ни доступного снаружи вектора.
AppSec-инструменты с AI берут на себя триаж: группируют находки, отбрасывают дубликаты, подтягивают контекст о доступности сервиса. Смысл в том, чтобы человек смотрел на десять находок вместо трёхсот. Решение при этом остаётся за человеком: модель не знает вашу архитектуру и ваши договорённости с бизнесом о допустимом риске.
Приоритизация вместо погони за каждым CVE
Приоритизация держится на инвентаризации. Нужно знать, какие версии PHP, CMS, плагинов и библиотек работают на хостах, что смотрит наружу, где стоит прокси и WAF. Без этой картины любой рейтинг критичности превращается в гадание: непонятно, есть ли у дыры шанс дойти до вашего сервера.
Ограничение честное: инвентаризация стоит времени. Для пары сайтов её можно вести вручную в таблице с датами последних обновлений, для десятков хостов нужна автоматика, иначе данные устареют через месяц. Отдельная сложность - тень IT: тестовые копии, забытые поддомены, стенды, которые когда-то открывали наружу.
Координированное раскрытие уязвимостей и почему утечки почти неизбежны
Схема классическая: исследователь находит дыру, сообщает вендору, вендор готовит патч, затем информация публикуется. Anthropic, например, даёт разработчикам 90 дней на патч и ещё 45 дней до раскрытия деталей сверх того, что уже попало в публичный бюллетень (политика раскрытия Anthropic).
Утечки в такой схеме почти неизбежны, и Шварц говорит об этом как о рабочем допущении: Wiz заранее планировала, что делать, если информация уйдёт раньше срока. Причина простая - участников слишком много. Исследователи, вендоры, мейнтейнеры дистрибутивов, координаторы CVE, подрядчики. У каждого свои тикеты, чаты, черновики и графики релизов.
Для владельца сайта вывод один: момент публичного раскрытия плохо подходит на роль дедлайна. Патч стоит ставить тогда, когда он появился у вендора, а не когда о дыре написали в новостях.
Сроки, участники и точки утечки
Типичные точки утечки: слишком ранний анонс в блоге, черновик бюллетеня в общем канале, диффы в публичном репозитории, по которым легко восстановить, какой участок кода чинили. Последнее особенно неприятно: патч в открытом репозитории виден всем сразу, а по изменению обычно понятно, где искать проблему.
Срок в 90 дней - компромисс. Быстрее патч не всегда возможен, особенно в проекте с обратной совместимостью и огромной базой установок. Дольше держать информацию в секрете опасно: часть пользователей так и не узнает о риске и останется на уязвимой версии. Anthropic отдельно оговаривает, что детали сверх бюллетеня раскрывает через 45 дней после патча, а не сразу.
Что делать владельцам небольших сайтов на WordPress
Кто остаётся без патчей и надо ли беспокоиться владельцам небольших сайтов на WordPress - этот вопрос в выпуске TechCrunch обсуждается отдельно. Универсального ответа нет, зато риск неплохо считается по конкретным признакам.
Кто остаётся без патчей и в зоне риска
- Сайты на ветках PHP, которые больше не получают обновлений безопасности.
- Установки с заброшенными плагинами и темами: автор ушёл, обновлений нет, код остался.
- Хостинги с поздними обновлениями: версия PHP на shared-хостинге меняется по расписанию провайдера, а не по выходу патча.
- Сайты без обслуживания: работают годами, обновления не ставятся, резервных копий нет.
Отдельный слой риска - автоматизированные атаки и массовый скрейпинг. Старые сайты с большим числом страниц и файлов ловят ботов постоянно, и защита от эксплойта конкретной дыры эту нагрузку не снимает. Механику такого сценария мы разбирали в материале про атаки AI-ботов на веб-сайты.
Точных цифр по WordPress в доступных источниках нет, поэтому оценку стоит строить от собственной инвентаризации, а не от отраслевых средних.
Чек-лист: что сделать на своём сайте
- Проверить версию PHP и обновить до поддерживаемой. Неподдерживаемая ветка не получает патчей, и дыра останется с вами навсегда. Ограничение: на старом коде сайта обновление PHP может выявить ошибки совместимости, поэтому сначала тестовая копия, потом продакшен.
- Обновить ядро WordPress, плагины и темы. Большая часть проблем приходит именно через плагины. Ограничение: обновление без свежей резервной копии превращает сбой в потерю сайта.
- Удалить заброшенные плагины и темы. Отключённый плагин остаётся файлами на диске, а иногда и в базе. Удаляйте то, чем не пользуетесь.
- Включить автообновления безопасности для ядра и плагинов. Это сокращает окно между выходом патча и его установкой. Ограничение: автообновление иногда ломает вёрстку или совместимость с другим плагином, нужен план отката.
- Поставить WAF перед сайтом. Он отсекает часть попыток эксплуатации по сигнатурам и аномалиям. Ограничение: WAF не заменяет патч, а обходы под популярные фильтры появляются быстро.
- Вести инвентаризацию компонентов. Список версий PHP, плагинов, тем и внешних сервисов с датами последнего обновления. Без него непонятно, что проверять первым.
- Подписаться на бюллетени вендоров и отслеживать CVE по своим компонентам. Официальный канал вендора опережает новостные пересказы, а иногда и месяцы.
- Держать резервные копии и план отката. Проверьте восстановление заранее, а не в момент инцидента.
Порядок важен: обновление PHP и ядра даёт больше, чем тонкая настройка WAF. Защита от конкретной дыры без патча - временная мера, а не стратегия.
Насколько AI-инструменты безопасности реально помогают: цифры и ограничения
Отчёт Всемирного экономического форума, опубликованный в мае 2026 года, приводит такие данные: 94% руководителей в сфере кибербезопасности называют AI определяющей силой, а 77% организаций уже используют его в кибероперациях. Организации, которые применяют AI в безопасности активно, сокращают средние издержки от утечек до 1,9 млн долларов и уменьшают жизненный цикл утечки примерно на 80 дней. Цифры известны по пересказу в отраслевой заметке, первичный отчёт WEF стоит открывать отдельно и сверять формулировки.
Вендорские бенчмарки дают более дробные числа. Gemini 4 Carbon заявлена с результатом 88,2% в SEC-bench Pro по поиску уязвимостей, 54,8% в ExploitGym по эксплуатации и 71,0% в CWE-bench по патчингу. По генерации безопасного кода модель даёт больше чем двукратный рост успешности относительно Argon, а команда Chrome сообщила, что Carbon более чем в 10 раз лучше другой фронтирной модели готовила качественные патчи (анонс Gemini 4 Carbon). Wiz отмечает лидерство Carbon в бенчмарках веб-пентеста, что важно для её Scan for Good.
К этим числам стоит относиться как к замерам на подготовленных задачах. Перенос результата на произвольную кодовую базу никто не гарантирует, а ошибки в логике доступа и бизнес-контексте бенчмарки ловят плохо. Что такие результаты действительно показывают: класс задач, где модели уже полезны, и где их имеет смысл пробовать.
Где AI помогает, а где пока нет
Помогает: генерация гипотез, массовая проверка однотипных мест, триаж и группировка находок, приоритизация по контексту, подготовка черновиков патчей. Не помогает пока: замена эксперта, гарантия отсутствия ложных срабатываний, безопасное автоисправление без ревью. Автофикс способен закрыть дыру и заодно открыть новую ошибку в логике.
Ориентир для оценки таких инструментов даёт разбор бенчмарка CyberGym: видно, какие задачи модели решают уверенно, а где без человека результат рассыпается.
Как использовать AI для собственного аудита: практические ориентиры
Три класса инструментов, между которыми стоит выбирать осознанно.
- AI-ассистент для ревью кода. Подходит, чтобы пройтись по конкретному модулю и получить список подозрительных мест. Дешёво и быстро, но на выходе гипотезы без доказательств.
- Сканер с AI-триажем. SAST или DAST, поверх которого модель отсеивает шум и объясняет находки. Даёт проверяемые результаты, стоит денег и требует настройки под проект.
- Локальная LLM для анализа кода. Вариант для случаев, когда код нельзя отправлять наружу. Ограничение: локальные модели слабее на длинных цепочках рассуждений и хуже держат контекст большого репозитория, поэтому ручная валидация обязательна.
Рамка выбора простая: чувствительность кода (можно ли отдавать его внешнему API), бюджет и наличие человека, который проверит находки. Если валидировать некому, третий пункт важнее двух первых, иначе отчёт превратится в список страшилок.
Скорость агентов не отменяет узких мест. В разборе про AI-агентов в цикле разработки видно, что типовые задачи ускоряются в 2,5-4 раза, новая логика лишь в 1,3-1,8 раза, а безопасность остаётся ограничителем темпа.
Что будет дальше: прогноз и выводы для владельцев сайтов
Волна AI-обнаруженных уязвимостей будет расти. Инструменты дешевеют, старый код никуда не девается, а разрыв между обнаружением и эксплуатацией сжимается. Правило «обновимся в следующем квартале» перестаёт быть безопасным.
Стратегия для владельца сайта выглядит скучно и работает: держать PHP и CMS на поддерживаемых версиях, включить автообновления безопасности, знать свой инвентарь, отслеживать бюллетени вендора, иметь резервные копии и план отката. Для команд добавляются приоритизация по реальной экспозиции и автоматизация триажа, иначе поток находок побеждает любую команду.
Термин «вулнпокалипсис» звучит громко, но описывает смену темпа: AI находит дыры быстрее, чем люди успевают реагировать вручную, поэтому автоматизация поиска и обновления становится базовой гигиеной. Начните с одного действия: проверьте версию PHP на своём сайте и сравните её со списком поддерживаемых ветвей. Если версия не получает обновлений безопасности, это первоочередная задача на эту неделю.