ИИ раскопал уязвимость в底层 PHP, скрывавшуюся более десяти лет — кибербезопасность уже не будет прежней

PanewslabPanewslab

Автор: Казик

 

Прошлая ночь, возможно, стала кошмаром для кибербезопасности.

И бессонной ночью для многих инженеров.

Можно лишь сказать, что вся наша эпоха и общество под ускорением ИИ становятся всё более измотанными.

Вот как всё произошло.

Сначала позавчера, то есть ночью 20 октября около 11 часов, на Hacker News внезапно появился пост.

Заголовок был пугающим: говорилось о двух уязвимостях удалённого выполнения кода в PHP с оценкой CVSS 10.0, которые скоро будут раскрыты.

Автор поста сам написал, что, кроме «источник: просто поверь мне» (trust me, bro), у него нет никаких доказательств, и даже приложил номера уязвимостей.

Но такие посты в интернете появляются сотнями каждый день, никто не воспринял это всерьёз.

Однако через несколько часов эту информацию подтвердила компания по безопасности watchTowr. Их дословные слова: «Мы должны были ждать до четверга».

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

Ещё через час с лишним PHP официально выпустил предупреждение: обновление безопасности, изначально запланированное на 22 октября, вынужденно перенесли на 21 октября, 22:00 по пекинскому времени, чтобы максимально сократить окно.

Но как только официальное предупреждение вышло, произошло нечто ещё более нелепое.

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

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

Вот и всё.

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

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

А в этот момент до официального выпуска исправления, доступного для скачивания всем, оставалось ещё 16 часов.

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

Ещё более нелепо то, что 21 октября в 15:41 компания, занимающаяся контейнерными образами, выпустила уже пропатченный образ на 6 с лишним часов раньше оговорённого срока. PHP Foundation прямо возмутился: «Проигнорировали недели координационной работы множества сторон».

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

Но администраторы огромного числа обычных сайтов ещё не имели готового к установке пакета обновлений, а это означало, что атакующие получили всевидящее око и получили фору.

И тогда начался коллапс.

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

IT-подрядчик финского правительства также отключил ряд сервисов. Американская компания BambooHR, занимающаяся HR-софтом, полностью остановила обслуживание, предупредив клиентов, что операции, связанные с выплатой зарплаты, могут пострадать. Японские niconico и pixiv перешли в режим экстренного технического обслуживания.

Поскольку в Японии PHP-сайтов чрезвычайно много, даже Такаити Санаэ опубликовала пост в X, рекомендуя превентивно уйти в офлайн до выхода обновления PHP в 22:00.

 

Уязвимость в языке программирования заставила Такаити Санаэ писать посты среди ночи и побудила правительства нескольких стран добровольно отключить свои сайты. Честно говоря, такой картины я ещё не видел.

Так мир, спотыкаясь, пережил эти десять с лишним часов.

Никто не знает, что за эти часы получила скрытая тёмная сторона.

В 22:00 вышло обновление безопасности PHP. Для этих двух серьёзных уязвимостей не существовало никаких полных мер по смягчению последствий — обновление было единственным безопасным выбором.

Одновременно OpenAI признала, что эти две эпические уязвимости PHP были обнаружены при содействии GPT.

И эти уязвимости были найдены не какой-то новой моделью, а несколько месяцев назад с помощью GPT-5.6 Sol. Поэтому можно представить, что если бы более мощные невыпущенные внутренние модели компаний-разработчиков ИИ начали сканировать мировую сетевую инфраструктуру, то, возможно, действительно всё оказалось бы под угрозой...

Также OpenAI срочно выпустила инструмент (skill), помогающий определить, подвержен ли ваш сайт влиянию.

 

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

Я знаю, многие скажут: «Разве это не просто одна уязвимость? Чего так волноваться?»

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

Я не эксперт, поэтому постараюсь описать это на доступном мне языке.

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

А PHP — один из самых часто используемых языков для написания бэкенда.

Но из-за того, что он слишком старый, многие компании сейчас уже не используют его в новых продуктах или новых технологических стеках. И что интересно, PHP в кругах программистов всегда был объектом насмешек: «PHP — лучший язык в мире» — этот мем существует уже больше десяти лет, и многие считают его пережитком прошлого века.

Однако в мире сайты, построенные на PHP, по-прежнему занимают 70%. Даже в относительно более новом Китае, хотя Java чрезвычайно много, по данным на октябрь 2026 года, более половины сайтов построены на PHP.

Все над ним смеются, но, честно говоря, все от него зависят.

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

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

А в этот раз лопнул сам PHP.

У этой уязвимости есть имя — PHP2Shell. Shell — это командная строка сервера; получив её, можно считать, что вы практически получили контроль над сервером. Поэтому название предельно прямое: из PHP — прямиком в ваш сервер.

Она включает два номера: CVE-2026-109618 и CVE-2026-109619.

CVE можно понимать как идентификационный номер уязвимости, единый во всём мире.

Степень серьёзности оценивается по шкале CVSS, максимум 10 баллов. В первоначально утёкшей версии был максимум, но в итоге поставили 9,2 балла.

Чтобы объяснить эти две уязвимости, нужно сначала сказать об одном понятии, которое в последнее время всем бьёт по карману:

Память.

Когда программа запускается, она постоянно «занимает» у системы память для хранения временных данных, а после использования «возвращает» её. Интерпретатор PHP написан на языке C. C работает быстро, но занимание и возврат по-прежнему полностью зависят от того, как программист ведёт учёт, — системе всё равно.

Поэтому если в этом учёте допущена ошибка, случается беда.

 

Первая уязвимость, CVE-2026-109619, на профессиональном языке называется «использование после освобождения» (use-after-free).

Приведу пример. Вы открыли гостиницу. Первый гость пришёл сдать багаж, сотрудник положил его вещи в шкафчик №18 и записал это в журнал.

Потом гость ушёл, шкафчик освободили и отдали второму человеку.

Но вот проблема: сотрудник забыл удалить старую запись из журнала.

Как только второй человек положил свои вещи, сотрудник взял старую запись, пошёл и открыл шкафчик №18, думая, что там вещи первого гостя.

И тут начинаются неприятности: он мог увидеть вещи второго человека, а мог даже испортить то, что внутри.

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

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

Это и называется использованием после освобождения, по-английски Use-After-Free.

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

 

Вторая дыра: экстренная эвакуация при нехватке памяти, это CVE-2026-109618.

Эта уязвимость ещё интереснее. Снова возьмём пример с гостиницей.

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

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

внезапно отключилось электричество, и багаж ещё не был положен, а вся система была вынужденно прервана.

Дальше происходит ещё более нелепое: гостиница запускает экстренную процедуру очистки. Уборщик берёт журнал и видит: сегодня всего сдано 10 предметов багажа.

И начинает проверять один за другим по числу в журнале.

Но проблема в том, что 10-й предмет вообще не был положен, и на этом месте может лежать какой-то старый хлам.

А уборщик об этом не знает и не обращает внимания — он просто следует журналу и обрабатывает это как обычный багаж.

И вот тут вся система может дать сбой.

Вторая уязвимость PHP работает по похожему принципу.

При упорядочивании данных он сначала увеличивает счётчик на 1, а затем сохраняет сами данные. Если ровно между этими двумя шагами заканчивается память, PHP экстренно прерывает операцию.

Но программа, отвечающая за очистку, всё равно обрабатывает данные по тому числу, которое уже было увеличено на 1.

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

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

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

Каким бы осторожным ни был ваш собственный код, у вас может не оказаться даже шанса вмешаться.

Имеет ли это отношение к обычным людям? Конечно. Ваш собственный компьютер и телефон не пострадают, пострадают сайты, которыми вы пользовались. Если какой-нибудь заброшенный маленький сайт взломают, ваши учётные записи, пароли, номера телефонов и вся информация, оставленная на нём, могут утечь.

Именно поэтому многие инженеры в эти дни снова говорят, что такие языки, как C, где память полностью зависит от человека, рано или поздно приведут к подобным инцидентам. А языки с безопасной работой с памятью, такие как Rust, не позволяют совершать такие ошибки уже на этапе компиляции. Поэтому OpenAI не случайно специально спонсировала Rust Foundation.

Возвращаясь к этим двум уязвимостям: если копнуть историю, мы обнаружим, что они вовсе не новы.

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

Эту проблему действительно исправили, но её братья и сёстры остались.

В 2024 году PHP Foundation получил финансовую поддержку от немецкого агентства Sovereign Tech Agency и через координацию OSTIF пригласил французскую компанию по безопасности Quarkslab провести внешний аудит безопасности PHP, которого не было много лет.

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

Затем исправление так и затянулось: команда безопасности металась между несколькими вариантами, то останавливаясь, то возобновляя работу. Позже PHP Foundation в своём разборе сам признал, что это был так называемый «структурный провал», вызванный недостатками в процессе принятия решений и нехваткой кадров в команде безопасности.

И вот наступил 2026 год.

В мае этого года та самая компания Calif запустила серию под названием «Месяц обнаружения уязвимостей с помощью ИИ». В одной из публикаций с помощью Claude в PHP была найдена уязвимость памяти 21-летней давности.

Затем ИИ продолжил ускоряться, и остановить его было невозможно.

30 июля Calif начала аудит PHP в рамках программы безопасности OpenAI «Patch the Planet».

Всего за 2 дня, 1 августа, они нашли первую точку входа, способную вызвать «исчерпание памяти».

11 августа Calif сообщила об уязвимости в PHP, и в тот же день исследователи OpenAI независимо сообщили о той же проблеме.

15 августа PHP подтвердил, что демонстрация атаки, предоставленная Calif, действительно работает.

24 августа и 18 сентября компании Wiz и OpenAI последовательно сообщили о дополнительных путях атаки.

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

Это жестокое сравнение: в 2024 году один ключевой разработчик долго искал и не мог найти способ использовать эту уязвимость, а в 2026 году от начала аудита до обнаружения первой точки входа прошло всего два дня.

А ещё более нелепо то, что

весь интернет построен на куче кода, за который никто не платит и который мало кто внимательно читает.

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

На Hacker News кто-то раскопал страницу спонсорства мейнтейнера, отвечающего за сборку PHP в Debian, и с сарказмом заметил: меньше 700 долларов в месяц?

А серверы по всему миру действительно ждут, пока эти люди встанут посреди ночи и выпустят релиз.

Но если эти базовые программы настолько хрупки, почему интернет все эти годы в целом работает нормально?

Причина очень проста — как и в недавно взорвавшемся тренде обратной разработки REA.

 

Потому что искать уязвимости слишком дорого.

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

Людей, способных находить и использовать уязвимости памяти в ядре PHP, OpenSSL и подобных местах, во всём мире, возможно, всего несколько сотен.

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

 

Но ИИ свёл на нет всю прежнюю «дороговизну» мира.

Anthropic в этом месяце только что объявила, что с ноября прошлого года по начало октября этого года её модель нашла в open-source проектах в общей сложности 29 439 кандидатов в уязвимости.

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

PHP2Shell — это не конец, а только начало. Таких случаев дальше будет всё больше, обязательно будет.

Но тут проявляется самый главный баг: как в математике, доказательства и открытия становятся всё быстрее, но ключевое узкое место сместилось на проверку. Недавно OpenAI выпустила более 700 статей, и если бы математикам всего мира пришлось проверять их корректность, на это потребовалось бы как минимум несколько месяцев, а то и год.

В кибербезопасности то же самое: обнаружение этой уязвимости PHP заняло всего 2 дня.

А вот исправление — целых два месяца.

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

Это как в нашей старой поговорке:

 

«Можно тысячу дней быть вором, но нельзя тысячу дней сторожить вора».

Мне вдруг вспомнилась одна история.

В 1871 году Льюис Кэрролл, автор «Алисы в Стране чудес», выпустил продолжение «Алиса в Зазеркалье». В книге есть Красная Королева, которая тащит Алису бежать изо всех сил. Пробежав долго, Алиса замечает, что пейзаж вокруг ничуть не изменился.

Красная Королева говорит ей: «Здесь нужно бежать со всех ног, чтобы только остаться на том же месте».

Похоже, именно в такую ловушку ИИ загоняет сегодня общество.

И не только безопасность. Научные открытия ускоряются, написание кода ускоряется, копирование программ ускоряется, атаки ускоряются, защита тоже ускоряется. Хорошее и плохое — всё вместе бешено разгоняется.

И каждый из нас участвует в этой гонке Красной Королевы.

Цена остановки — это те старые сайты, о которых никто не помнит, админ-панели, настроенные 15 лет назад и с тех пор ни разу не открывавшиеся, корпоративные системы, всё ещё работающие на PHP 5. В медленном мире они могли спокойно существовать долгие годы, а в быстром мире они — живые мишени.

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

Человек не обгонит ИИ — это уже не требует доказательств.

Но во всей этой истории на каждом ключевом узле принятия решений по-прежнему стоят люди.

С добрыми намерениями и со злыми.

Теперь этот всемогущий инструмент оказался в руках у всех.

Победит ли справедливость зло?

ИИ может за одну ночь дать человечеству силу, которую раньше было трудно вообразить, но не может за одну ночь научить человечество сдержанности, соразмерной этой силе.

Когда скорость технического прогресса

намного опережает скорость взросления человеческой природы,

мы на самом деле бежим к лучшему миру или ускоряемся навстречу собственной бездне?

Честно говоря, теперь я не знаю.

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