21 октября разработчики PHP выпустили срочные обновления, которые закрывают две критические уязвимости. Через них злоумышленник может без пароля запустить собственный код на сервере с сайтом. PHP работает примерно на 70% сайтов в мире, поэтому правительства нескольких стран на время отключали свои порталы. Первые признаки ошибки заметили ещё в 2024 году, а сам выпуск исправления сопровождался утечками и публичным скандалом.
Коротко
- Уязвимы все установки PHP, которые обрабатывают веб-запросы. Защищают только новые версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35.
- Если обновиться сразу нельзя, агентства кибербезопасности США и Великобритании советуют временно отключить сайт.
- Исправление застряло почти на два года. Масштаб угрозы стал ясен летом 2026-го, когда уязвимости независимо нашли несколько команд, в том числе с помощью ИИ.
- Скоординированный выпуск патча сорвался: номера уязвимостей утекли за день до релиза, а одна компания выложила исправление раньше договорённого срока.
Что случилось
PHP — один из самых распространённых языков для сайтов. На нём работают WordPress и Drupal, интернет-магазины, медиа и многие государственные сервисы. По данным W3Techs, которые приводит Cybersecurity Dive, PHP используют около 70% сайтов.
21 октября команда PHP выпустила версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. В официальном бюллетене сказано, что они закрывают две критические уязвимости, которые позволяют удалённо выполнить код без авторизации.
Проще говоря, злоумышленник может заставить чужой сервер выполнять свои команды, не зная никаких паролей. Это самый опасный класс уязвимостей: через него можно получить контроль над сайтом и данными на нём.
Уязвимостям присвоены номера CVE-2026-109618 и CVE-2026-109619. CVE — это общий каталог известных уязвимостей, у каждой в нём свой номер. Опасность обеих оценили в 9,2 балла из 10 по стандартной шкале CVSS.
Под угрозой все установки PHP, которые обслуживают веб-запросы, независимо от того, как PHP подключён к веб-серверу. Самым рискованным вариантом команда PHP считает связку веб-сервера Apache с модулем mod_php.
Обе уязвимости находятся в управлении памятью и обработке ошибок — в тех частях PHP, через которые проходит почти каждый запрос. Как объясняет PHP Foundation, именно поэтому уязвимости оказались такими опасными и такими сложными в исправлении.
Что делать владельцам сайтов
Сначала узнайте, какая версия PHP стоит на вашем сайте. Её обычно показывает панель управления хостингом. Если сайт обслуживает провайдер или подрядчик, спросите их напрямую.
- Версии 8.2–8.5. Обновитесь до 8.2.35, 8.3.36, 8.4.27 или 8.5.12. Дистрибутивы Linux получили исправления заранее, поэтому обновлённые пакеты обычно уже доступны через штатный менеджер пакетов.
- Версия 8.1 и более старые. Проект PHP их больше не поддерживает. Часть дистрибутивов и компаний с долгосрочной поддержкой выпускает исправления сама, поэтому уточните это у своего поставщика. Для тех, кто собирает PHP из исходного кода, команда PHP в виде исключения подготовила минимальные исправления для версий 7.4, 8.0 и 8.1. Надёжное решение всё равно одно — переход на поддерживаемую версию.
- Если обновиться прямо сейчас нельзя. В бюллетене php.net перечислены временные настройки, которые снижают риск. Но команда PHP прямо предупреждает, что безопасной установку они не делают. Американские CISA и NSA и британский NCSC в таком случае советуют отключить сайт до обновления.
- Если сайт работает через Cloudflare. Компания заявила, что заранее включила защитные правила в своём веб-фаерволе (WAF) — фильтре, который отсекает подозрительные запросы до того, как они дойдут до сервера. На наш взгляд, это полезный дополнительный слой, но не замена обновлению.
Почему правительства выключали сайты
Выпуск патча не только защищает, но и подсказывает. Сравнив старый и исправленный код, атакующие могут понять, где именно находится ошибка. Эксперты, с которыми говорил Cybersecurity Dive, отмечают, что инструменты ИИ заметно ускоряют путь от опубликованного патча до готовой атаки. Поэтому на обновление теперь остаются часы, а не недели.
Многие государственные организации решили не рисковать. По данным Reuters, которые пересказывает Engadget, часть сайтов временно отключили правительства Нидерландов, Дании, Франции и Финляндии.
В Канаде о временном отключении государственных сайтов объявил министр по ИИ и цифровым инновациям Эван Соломон. The National добавляет к списку Австралию, а премьер-министр Японии Санаэ Такаити призвала проверить, не работают ли публичные сайты на PHP.
Белый дом, по данным Engadget, узнал о проблеме ещё в прошлую пятницу. CISA, NSA и NCSC выпустили рекомендации для организаций: обновиться как можно быстрее, а если это невозможно — отключить системы.
Сколько сайтов под угрозой
Точного числа нет, потому что компании считают по-разному. VirusTotal насчитал 5,1 млн доступных из интернета IP-адресов с PHP, из них 758 тыс. работают на версиях, которые больше не поддерживаются (The Record). Palo Alto Networks говорит о 22,6 млн доступных извне установок, а один из исследователей — о более чем 1,3 млн уязвимых сайтов.
Самая тревожная оценка у Cisco: примерно половина доступных из интернета установок работает на версиях, слишком старых для официальных исправлений.
Атакуют ли уже
Здесь данные расходятся. PHP Foundation пишет, что к моменту выпуска патча не нашла ни одного работающего публичного эксплойта, то есть готовой программы для атаки. При этом Cloudflare сообщила о попытках атак, а компании watchTowr и Sophos — об обсуждении уязвимости и попытках её использовать в киберпреступных сообществах. В watchTowr уточнили, что успешных атак пока не видели, но ожидают их.
Ведущий исследователь Ox Security Моше Симан Тов Бустан в комментарии The National дал простой совет: если у вас есть публичный сервер с PHP без патча, исходите из того, что он уже под угрозой.
Как ошибка прожила почти два года
Главный вопрос этой истории — почему уязвимость не закрыли раньше. PHP Foundation ответила на него необычно откровенно.
В 2024 году PHP прошёл первый за много лет внешний аудит безопасности. Его оплатило немецкое государственное агентство Sovereign Tech Agency, а провела компания Quarkslab. Исправляя одну из найденных проблем, разработчик ядра PHP заметил первые признаки ошибки, которая теперь известна как CVE-2026-109618. Реального способа атаки тогда не нашли, а другие проблемы казались срочнее.
Команда безопасности подготовила несколько вариантов исправления, но у каждого был серьёзный минус. Один ломал совместимость со старым кодом. Другой создавал новый риск DoS-атак, при которых сервер перегружают, и он перестаёт отвечать. Третий требовал переписать множество сторонних расширений, а договориться со всеми их авторами было практически невозможно.
Команда принимала решения консенсусом, и договориться о варианте не получалось. Работа над исправлением месяцами останавливалась и начиналась заново. Фонд прямо называет это «структурным провалом», вызванным и самим порядком принятия решений, и нехваткой людей. Сейчас этот порядок меняют: решения будут принимать большинством голосов, а сложные случаи будут быстрее доходить до руководства фонда.
Какую роль сыграл ИИ
В 2026 году к поиску ошибок в PHP подключили новые инструменты. По данным фонда, в начале года PHP просканировали моделью Claude Mythos от Anthropic в рамках программы Alpha-Omega. Позже добавили инструмент OpenAI Daybreak Red, который помогает проверять присланные отчёты.
30 июля PHP включили в программу Patch the Planet, и компания Calif начала аудит. 11 августа её исследователь сообщил об уязвимости с той же первопричиной, что и проблема 2024 года, но уже с понятным путём атаки. В тот же день то же самое независимо нашла OpenAI.
24 августа дополнительные сценарии атаки прислала компания Wiz, а 18 сентября — снова OpenAI. Именно эти отчёты, по словам фонда, показали реальный масштаб проблемы, и с этого момента исправление стало главным приоритетом команды.
OpenAI утверждает, что её модель помогла исследователям Calif найти одну из уязвимостей. Компания называет это новым этапом, когда ИИ находит баги масштаба всего интернета раньше атакующих. Это заявление самой OpenAI, и независимо оценить вклад конкретной модели пока нельзя.
У этой медали есть и обратная сторона. С 1 июля команда безопасности PHP опубликовала 15 CVE и разобрала больше сотни отчётов, которые оказались ошибочными, повторными или не воспроизводились. Фонд связывает рост потока отчётов с распространением исследований с помощью ИИ. ИИ помогает команде их сортировать, но каждое решение и каждый патч по-прежнему делает человек.
Главный вывод фонд формулирует так: инструменты теперь находят баги быстрее, чем когда-либо, причём и для защитников, и для атакующих. Но выбрать правильное исправление для давнего архитектурного решения они не могут. Для этого нужны инженеры, которые знают весь код PHP, и таких людей сейчас слишком мало.
Как сорвался скоординированный выпуск
Серьёзные уязвимости обычно раскрывают по правилам координированного раскрытия. Разработчики готовят исправление тайно, а дистрибутивы Linux и компании с долгосрочной поддержкой получают его заранее, под эмбарго — обязательство ничего не публиковать до назначенного часа. Так пользователи могут обновиться в тот момент, когда об уязвимости узнают все, включая атакующих.
На этот раз схема дала сбой сразу в нескольких местах. Вот хронология по данным PHP Foundation (время по UTC):
- 20 октября, около 15:00. Номера уязвимостей появились на форумах и в соцсетях — с неверной датой выпуска и завышенной оценкой 10,0 вместо 9,2. Технические детали при этом не утекли.
- 20 октября, 19:30. PHP опубликовал предупреждение и перенёс выпуск с 22 на 21 октября. Раньше было нельзя: дистрибутивы ещё готовили пакеты.
- 20 октября, около 20:00. Calif, одна из компаний, нашедших уязвимости, по ошибке опубликовала видео с работающим прототипом атаки. Его удалили, но копии разошлись по соцсетям. По оценке фонда, это ускорило появление самодельных эксплойтов.
- 21 октября, 07:41. Компания Chainguard, которая поставляет защищённые контейнерные образы, выложила сборки с исправлением более чем за шесть часов до общего выпуска. По словам фонда, с этого момента любой атакующий мог изучать исправление, пока остальные пользователи PHP ещё ждали.
- 21 октября, 14:00. Официальный выпуск обновлений.
Две стороны спора
Глава Chainguard Дэн Лоренц не оспаривает хронологию, но с обвинением не согласен. По его словам, компания ничего не сливала, а выпустила исправления потому, что, по данным других поставщиков, атаки в реальной среде уже начались (The Register). Как отмечает Socket, этих поставщиков и доказательства атак он не назвал. Позже Лоренц извинился за дополнительную нагрузку на команду PHP.
Фонд, в свою очередь, настаивает, что к моменту выпуска не нашёл работающих публичных эксплойтов, хотя и не исключает атак где-то ещё.
На наш взгляд, у обеих сторон есть аргументы. Правило «эмбарго действует, пока нет атак» звучит разумно, но непонятно, кто и по каким данным решает, что атаки уже идут. Чем больше участников знает о проблеме заранее — исследователи, ИИ-компании, дистрибутивы, — тем труднее удержать общий график.
Открытый вопрос. Кто будет платить за безопасность языка, на котором работает большая часть интернета? Сейчас ею занимается небольшая группа разработчиков на зарплате PHP Foundation и несколько волонтёров. Фонд просит о поддержке компании, хостинги и государства. Если ИИ продолжит находить уязвимости быстрее, чем люди успевают их исправлять, нынешней модели может не хватить.
Что это значит для разработчиков и бизнеса
Мы видим четыре практических вывода.
- Скорость обновлений стала частью безопасности. Если между выходом патча и первыми атаками проходят часы, подход «обновимся в следующем спринте» больше не работает. Нужен заранее продуманный план, как выкатить срочное обновление за день.
- Устаревшие версии — это долг, который приходится возвращать в самый неудобный момент. По оценке Cisco, примерно половина доступных из интернета установок не может получить официальное исправление.
- Важно знать, от кого вы зависите. Хостинг, подрядчик, поставщик образов — в кризис именно они определяют, как быстро обновится ваш сайт.
- Открытый код нужно финансировать. Компании, которые зарабатывают на PHP, пользуются бесплатной инфраструктурой. Эта история показывает, во что может обойтись такая экономия.
Итог
Уязвимости в PHP — серьёзная, но решаемая проблема. Исправление уже вышло, и его нужно установить как можно быстрее. Если обновиться нельзя, безопаснее временно отключить сайт.
Важнее то, что эта история показала об устройстве интернета. Ошибку в одном из его главных языков заметили ещё в 2024 году, но не смогли исправить из-за нехватки людей и тяжёлых компромиссов. ИИ помог найти её снова и показать масштаб, но он же ускоряет атаки и заваливает маленькую команду отчётами. Пока безопасность такой инфраструктуры держится на нескольких инженерах, подобные кризисы будут повторяться.