История с критическими уязвимостями PHP показала, как искусственный интеллект меняет стоимость исследования и взлома программ. Александр Вартанян, директор по маркетингу и AI/martech в Битрикс24, объясняет, почему это касается бизнеса, даже если компания ничего не разрабатывает сама.
21 октября 2026 года владельцы сайтов и онлайн-сервисов по всему миру готовились к экстренному обновлению PHP. Некоторые заранее ограничили работу своих систем. В инфраструктуре Wikimedia, например, временно отключили несколько сервисов, включая Cloud VPS и Toolforge. Об этом сообщила сама организация.
Мы в Битрикс24 тоже на несколько часов отключили часть возможностей сервиса, пока шла работа по установке исправлений. Для пользователя это выглядело странно: привычное действие внезапно перестало работать. Но для нас это была крайняя мера, на которую мы пошли ради проактивного снижения рисков и защиты данных наших пользователей.
Такие истории случаются. Но у этой есть особенность: важную часть работы по обнаружению уязвимостей и доказательству возможности взлома выполнили ИИ-агенты под руководством исследователей.
Мне нравится объяснять сложные технологии простым языком. Поэтому предлагаю разобраться, что произошло и какие изменения за этим стоят. Они касаются гораздо большего, чем один язык программирования.
Почему одна ошибка затрагивает разные сайты
Почти весь современный софт состоит из компонентов. Корпоративная система, интернет-магазин, стриминг или криптобиржа используют программы и библиотеки, написанные другими людьми.
Примерно как смартфон. На корпусе — один бренд, а внутри работают компоненты разных производителей. Компания собирает из них конечный продукт, связывает все между собой и отвечает за результат.
С программами похожая история. Пользователь видит сайт конкретной компании, но под ним находится несколько слоев чужого программного обеспечения. Один из таких компонентов — PHP.
Здесь возникает небольшая путаница. PHP — язык программирования. Однако этим же названием обозначают программу, которая выполняет написанный на нем код. Чтобы сайт работал, такая программа должна быть установлена на сервере.
Допустим, вы заказали сайт на WordPress или «1С-Битрикс: Управление сайтом». Вам не нужно самостоятельно писать весь код. Но сама система управления сайтом все равно зависит от PHP.
Поэтому ошибка внутри этого компонента может одновременно затронуть совершенно разные продукты. Их разработчики могут правильно написать собственный код, а уязвимость окажется в программе, которая его выполняет.
В этом инциденте проблема находилась в PHP, а не в коде продуктов CMS. Обновить только CMS было недостаточно: требовалось установить исправление серверного компонента. Именно такой порядок действий указали разработчики PHP.
Для бизнеса это неприятное открытие: можно ничего не менять на своем сайте и все равно однажды получить срочное сообщение от администратора.
Как исследователь и ИИ нашли проблему
В обнаружении уязвимостей участвовали несколько команд, включая Calif, OpenAI и Wiz. Особенно показателен рассказ исследователя Calif.
Он знал историю ошибок PHP и предполагал, где могут оставаться похожие проблемы. С этим направлением поиска он обратился к ИИ. Агент помог найти опасную последовательность операций в коде и проследить ее последствия.
Дальше произошло самое интересное. Исследователь попросил обобщить найденную ошибку: сформулировать закономерность, по которой можно искать другие уязвимые места. На основе первой находки агент продолжил анализ и помог обнаружить дополнительные варианты проблемы. Подробности — в разборе Calif.
Для человека, который работает с агентами, процесс узнаваемый: поставить задачу, получить результат, проверить его, выделить полезный подход и применить снова.
При этом экспертиза исследователя никуда не исчезла. Он выбирал направление, интерпретировал результаты и понимал историю технологии. Агент выполнял значительную часть анализа.
Еще одна важная деталь: первые признаки одной из корневых проблем разработчики заметили в 2024 году. Тогда практическую возможность взлома не доказали, а варианты исправления создавали сложные компромиссы по совместимости и поведению системы. Работа затянулась. PHP Foundation открыто описывает причины этой задержки.
В 2026 году исследователи с помощью ИИ смогли показать реальную опасность.
Несколько часов, за которые нужно успеть защитить интернет
Представьте масштаб: миллионы сайтов используют один и тот же программный компонент. Исследователи находят в нем возможность удаленного взлома. Исправление еще нужно подготовить, проверить и передать тем, кто выпускает обновления для разных серверов.
В обычной ситуации эту работу стараются закончить до публичного раскрытия. Разработчики и исследователи согласуют дату, поставщики готовят пакеты, защитные сервисы — правила фильтрации атак. Это дает владельцам сайтов возможность начать обновление сразу после объявления.
С PHP подготовка шла именно так. Но за два дня до намеченного выпуска сведения об уязвимостях начали расходиться по сети. Затем по ошибке опубликовали видео с демонстрацией взлома. Копии продолжили распространяться даже после удаления оригинала.
Выпуск исправлений пришлось перенести на день вперед — на 21 октября, 17:00 по Москве. Хронологию описала PHP Foundation.
В этот момент у владельцев сервисов возникает неприятный выбор. Продолжать работу с уязвимым компонентом — риск. Отключить сервис — тоже ущерб: пользователи не могут работать, бизнес теряет заказы, поддержка получает обращения. А готового обновления пока нет.
По миру начинаются предупредительные отключения. Временно недоступны сайты государственных учреждений и крупные онлайн-площадки. Где-то ограничивают отдельные функции, где-то оставляют только чтение. Wikimedia отключает несколько инфраструктурных сервисов. Список опубликован организацией.
Наконец исправления выходят. Но на этом история только входит в следующую фазу.
Теперь тысячи независимых команд должны установить их на свои серверы. У одних уже все подготовлено. Другие ждут готовых пакетов. Третьим предстоит разобраться с совместимостью старого приложения. Каждая такая задержка продлевает время, в течение которого система остается под угрозой.
Одновременно исследователи безопасности и атакующие изучают опубликованные подробности. Появляются новые инструменты проверки и попытки эксплуатации.
Позже AWS сообщит, что ее серверы-ловушки зафиксировали попытку атаки еще 17 октября — за четыре дня до выпуска исправлений. Успех этой попытки на реальной системе не установлен, но сама дата показывает: для некоторых участников гонка началась раньше публичного объявления. Исследование AWS.
Вот почему в таких историях считают часы. Пока одна команда проверяет обновление, другая уже устанавливает его, а кто-то по другую сторону пытается найти еще не защищенный сервер.
И у интернета нет общей кнопки «обновить всё».
Для нас в Битриксе это был спринт сразу для нескольких подразделений. Ещё до выхода исправлений мы ограничили потенциально опасные функции облака: решили, что безопасность данных важнее временных неудобств. Решение оказалось болезненным — ограничения затронули файлы, формы, почту и работу со сделками. Параллельно мы предупреждали клиентов через все доступные каналы, сайты и соцсети, объясняли происходящее и готовили инструкции для владельцев коробочного Битрикс24 и сайтов на «1С-Битрикс: Управление сайтом». Первая предупредительная рассылка по всем пользователям ушла за несколько часов до выхода исправлений, вторая уже содержала готовую инструкцию по установке вышедших обновлений. О ходе работ мы сообщали в соцсетях и на Хабре. Работа облака была полностью восстановлена через несколько часов после выхода обновлений от разработчиков PHP. Мы пошли на крайние меры, но все принятые решения были верными.
Частью защиты всегда была стоимость взлома
Мы обычно думаем о безопасности как о наборе технических средств: пароли, шифрование, фильтры, обновления. Но у нее есть и экономическая сторона.
Некоторые атаки требуют столько времени и квалификации, что применять их к небольшой компании просто невыгодно. Если ради одного интернет-магазина нужно потратить неделю дорогого специалиста, потенциальный результат может не оправдать усилий.
ИИ меняет эту экономику. Он помогает читать код, проверять гипотезы, разбирать ошибки и повторять исследование. В работе над PHP исследователи Wiz использовали модели в том числе для адаптации эксплуатации к разным окружениям и проверки исправлений. Они описали этот процесс отдельно.
Для массовой атаки особенно удобен инструмент, который работает сразу на множестве целей. Различия между сайтами и конфигурациями усложняют задачу. Если адаптация становится дешевле, атакующие получают возможность уделять больше внимания каждой отдельной системе.
Это не означает, что любой человек теперь способен взломать любой сайт одной командой. Но стоимость некоторых сложных действий снижается. А вместе с ней расширяется круг целей, за которые экономически имеет смысл браться.
Принцип «работает — не трогай» становится дороже
Бизнес любит стабильность. Если сайт принимает заказы, интеграции передают данные, а сотрудники знают интерфейс, менять что-либо страшно. После обновления могут появиться проблемы. Эта осторожность понятна. Но у отказа от обновлений тоже есть цена.
Сайт может годами выглядеть одинаково. За это время инструменты его исследования становятся мощнее, а знания об используемых компонентах — доступнее. Прошлогодняя оценка безопасности не обязательно описывает сегодняшнюю ситуацию.
Появляется важное различие между системой, которая продолжает работать, и системой, которую продолжают обслуживать.
Первая просто не остановилась. У второй есть ответственный, актуальные компоненты, проверяемые резервные копии и понятный порядок обновления.
Для бизнеса способность безопасно обновляться становится полноценной характеристикой продукта. Она влияет на непрерывность работы не меньше, чем производительность или набор функций.
Атака и защита ускоряются по-разному
Атакующему нужно найти работающий способ добраться до подходящей цели.
Защитнику приходится сделать гораздо больше: выяснить, где используется компонент, выбрать исправление, проверить совместимость, обновить серверы и убедиться, что сайт действительно работает на новой сборке.
При этом нельзя потерять заказы, остановить оплату или сломать интеграцию с учетной системой.
ИИ способен помочь и здесь. Но он не отменяет организационные ограничения: отсутствие документации, забытые серверы, зависимость от подрядчика, недостаток тестов.
Для меня это главный управленческий вывод из истории с PHP. Скорость технического анализа растет, а скорость принятия решений и изменения инфраструктуры может оставаться прежней.
Можно купить самый современный инструмент безопасности и все равно несколько дней выяснять, кто отвечает за конкретный сервер. Именно такие задержки будут становиться особенно дорогими.
Компании стоит заранее понимать хотя бы три вещи:
- Кто отвечает за сайт, его компоненты и обновления.
- Как быстро можно установить критическое исправление и проверить основные функции.
- Как продолжить работу, если часть системы придется временно ограничить.
Ответы нужны до следующего срочного уведомления.
Почему защита иногда выглядит как поломка
В случае с PHP некоторые организации временно отключали сервисы или отдельные возможности. Для них это был способ снизить риск на период подготовки и установки исправлений.
Для пользователя ситуация выглядит иначе. Он собирался отправить документ, обработать заявку или закончить рабочую задачу — и не смог.
В Битрикс24 мы увидели эту разницу непосредственно. Защитное ограничение конкретного механизма отражается на привычных действиях людей. Пользователь не обязан знать, какие серверные компоненты участвуют в загрузке файла.
Поэтому безопасность становится еще и продуктовой задачей. Нужно понимать, какие функции связаны между собой, что произойдет при отключении одной из них и как объяснить происходящее человеку.
Если подобных ситуаций станет больше, сервисам понадобится умение работать с частичными ограничениями: сохранять введенные данные, оставлять доступными независимые функции, понятно сообщать о временных изменениях.
Интернет будет сильнее разделяться по качеству обслуживания
Я ожидаю, что разница между хорошо обслуживаемыми системами и заброшенными проектами станет заметнее.
У одних компаний есть возможность постоянно проверять инфраструктуру и быстро устанавливать обновления. У других сайт работает на сервере, доступ к которому остался у давно ушедшего подрядчика.
В такой ситуации самостоятельное размещение сервиса требует все более осознанного решения. Нужно учитывать стоимость его дальнейшего обслуживания, а не только разработки и запуска.
Управляемые платформы могут снять часть этой нагрузки. Но само слово «облако» ничего не гарантирует. Значение имеют реальные процессы: как поставщик обновляется, как обнаруживает проблемы, как восстанавливает работу и что сообщает клиентам.
Для небольшого бизнеса это станет одним из критериев выбора сервиса. Рядом с ценой и возможностями появится вопрос: насколько быстро команда сможет защитить мою работу, когда обнаружится следующая серьезная проблема?
Почему утечки в интернете могут стать массовее
Удешевление атак затрагивает весь рынок цифровых сервисов: интернет-магазины, форумы, приложения доставки, образовательные платформы, небольшие сайты с личными кабинетами.
Каждому из них люди оставляют часть информации о себе. Где-то — имя и телефон, где-то — адрес доставки, историю покупок или переписку. При этом качество обслуживания этих систем сильно различается.
Если искать и использовать уязвимости становится дешевле, атакующим выгоднее заниматься всё большим количеством целей. В том числе небольшими сервисами, которые раньше не оправдывали затрат на сложную атаку.
Я ожидаю, что это усилит давление на плохо обслуживаемые системы и создаст условия для роста числа утечек.
Здесь может начаться то, что я называю инфляцией персональных данных. При увеличении предложения отдельные украденные базы могут дешеветь, а собирать из разных источников подробную информацию о человеке станет доступнее.
Для пострадавшего это слабое утешение. Чем больше контекста есть у мошенника, тем убедительнее он может обратиться: сослаться на реальную покупку, знакомую организацию или недавнюю заявку. Такое сообщение сложнее отличить от настоящего.
Это прогноз развития угрозы, а не установленный итог инцидента с PHP. Количество попыток атак само по себе не показывает, сколько сервисов взломано и какие сведения похищены.
Однако для цифрового бизнеса направление понятно: способность регулярно обновляться и защищать информацию будет все сильнее влиять на доверие клиентов. Даже если сами клиенты никогда не слышали о PHP.
ИИ оказался и на стороне защиты
В этой истории есть позитивная часть. Исследователи использовали ИИ, чтобы найти опасные ошибки, доказать их значимость и помочь проверить исправления. Результат позволил защитить множество продуктов, использующих общий компонент.
Те же возможности, которые снижают стоимость подготовки атак, могут сделать качественное исследование безопасности доступнее защитникам. Но найденную проблему еще нужно исправить, доставить обновление и проверить его работу.
Для бизнеса это означает, что обсуждение ИИ пора расширять. Мы уже оцениваем, сколько времени агент экономит на подготовке отчета или разработке приложения. Теперь придется учитывать, как он меняет возможности тех, кто исследует наши системы с совсем другими намерениями.
Сайт может остаться прежним. Возможности атакующего — уже нет.
Такой вот киберпанк. И в случае с PHP ИИ помог нам к нему подготовиться.