Hacker News Digest

Исследователи Wiz обнаружили в ядре PHP критические уязвимости, позволяющие без аутентификации выполнять код на сервере и читать память процесса — там могут лежать пароли, токены, API-ключи и сертификаты других запросов. Проблемы затрагивают почти все версии PHP за последнее десятилетие, начиная с 5.4, а сам язык лежит в основе WordPress, Drupal, Joomla и MediaWiki, на котором работает «Википедия». Уязвимости получили общий рейтинг CVSS 9.2 и не зависят от кода приложения поверх PHP.

Корень проблем — архитектурные решения более чем десятилетней давности. Эксплуатация требовала исключительно сложной цепочки шагов и подстройки под раскладку памяти каждой цели, что было на грани человеческих возможностей. Пограничные ИИ-модели существенно снизили этот барьер: с их помощью рабочие эксплойты для разных приложений удавалось собирать за часы. В ходе работы подтвердили удалённое выполнение кода на Drupal и WordPress, а 21 октября 2026 года вышли патчи. Авторы сравнивают находку с Heartbleed и Log4Shell и предупреждают: сложность перестаёт быть надёжной защитой, но те же инструменты дают защитникам шанс находить и закрывать давние дыры.

Обсуждение дополняет статью деталями о раскрытии уязвимости, роли ИИ и влиянии на инфраструктуру, включая отключение государственных сайтов. Уязвимость оценивается как критическая (на уровне Log4Shell и EternalBlue), так как затрагивает ядро PHP и популярные CMS (WordPress, Drupal, Joomla). Технически проблема в том, что фатальные ошибки (преимущественно OOM) оставляют поврежденное состояние памяти, которое может быть переиспользовано следующим запросом в рамках одного воркера PHP-FPM. При этом @WJW отмечает, что Wiz и Calif не детально описали механизм перехода от Use-After-Free к полноценному RCE. Пользователи спорят о независимости открытия: @fwlr предполагает, что OpenAI могла воспроизвести баг из обучающих данных после работы Calif, а @ToValueFunfetti считает LLM недостаточно эффективными для обучения по одиночным примерам. В то же время @asbv-1qq советует использовать ИИ для аудита legacy-систем, так как он эффективно находит баги в коде старше 20 лет. Отмечена проблема «ответственного раскрытия»: между отчетом Wiz (24 августа) и подтверждением PHP Foundation (21 сентября) прошел месяц, а ранее произошли утечки в соцсетях. Для временного смягчения утечки памяти (memory disclosure) предлагается снизить параметр pm.max_requests для более частого перезапуска воркеров, однако это не поможет против type confusion в OPcache.

Инициатива Patch the Planet позволила выявить критическую уязвимость в PHP — языке, на котором работает значительная часть сайтов и веб-приложений. Модель GPT‑5.6 Sol нашла изъян, а компания Wiz независимо обнаружила и сообщила об обеих уязвимостях. Исправления подготовили сопровождающие PHP при участии OpenAI, Wiz, Cloudflare и других партнёров, а также при содействии государственных киберведомств. По оценке авторов, это одна из самых значимых проблем безопасности за последнее время: она показывает, что ИИ способен находить уязвимости интернет-масштаба, но те же возможности помогают злоумышленникам быстро создавать эксплойты. Ключевой факт: передовые модели нашли эти дыры раньше атакующих, открыв «окно защитника» для подготовки исправлений до раскрытия.

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

Участники обсуждения опровергают «магию» ИИ, считая инициативу OpenAI маркетинговым ходом для создания имиджа «спасителя» кибербезопасности. @nr378 утверждает, что успех зависел от глубоких знаний исследователя Calif о кодовой базе, тогда как @senordevnyc отмечает, что OpenAI лишь указали на использование модели. @OlivOnTech и @aprilnya критикуют «навык» проверки версии PHP, считая бесполезным запуск `php -V`, а @post-it добавляет, что команда `php --version` не всегда показывает версию реально запущенного интерпретатора. @lifeisloving отмечает деградацию навыков молодых инженеров: некоторые Senior-разработчики не знают базовых команд ОС (например, grep) из-за зависимости от LLM. В споре об этике open source @12837615 называет обучение моделей на открытом коде «кражей», а @fritzo и @orangedog считают, что код был отдан добровольно. Вместо раздачи токенов ИИ @12837615 предлагает инвестировать в QA open source проектов для обеспечения 100% покрытия тестами, использования ASAN и фаззеров. @ptmkenny и @sevenzero заметили, что официальные патчи коснулись только поддерживаемых версий (от 8.2), в то время как устаревшие ветки 7.x и 5.6 патчатся сторонними энтузиастами (например, Mr Sury).

AI-ассистент GitHub Copilot случайно внёс критическую уязвимость в репозиторий Snowflake, заменив безопасный шаблон обработки данных на прямую подстановку пользовательского ввода в shell-скрипт. Это позволило любому пользователю GitHub выполнить произвольный код через создание специально оформленного issue — уязвимость была активна всего пять дней, пока Wiz Red Agent, автономный AI-инструмент для поиска уязвимостей, не обнаружил и эксплуатировал её, получив доступ к внутренней системе Jira Snowflake через украденный токен. AI-ревью не заметило опасность, потому что не понимало исторический контекст: ранее использовавшийся метод с env: и jq был специально добавлен для предотвращения инъекций.

Snowflake оперативно устранила уязвимость в тот же день, сменить токен и подтвердила, что Wiz был единственным субъектом доступа. Инцидент стал ярким примером рисков, связанных с автоматизацией кода: AI-агенты могут удалять защищающие паттерны, не понимая их назначения. Важно внедрять «охранительные барьеры», запрещающие AI заменять структурированные парсеры на прямую подстановку строк. Уязвимость не была следствием человеческой ошибки — она родилась в AI-автоисправлении, что ставит под сомнение надёжность текущих практик код-ревью с участием ИИ.

Уязвимость возникла не из-за AI, а из-за слабой проверки изменений, устаревших практик в GitHub Actions и некорректной обработки null-значений в шаблонах, что усиливает риск доверия автоматическим исправлениям без ручного аудита. AI не создаёт новых типов уязвимостей, но ускоряет их появление, делая распространёнными существующие ошибки: интерполяцию пользовательского ввода в shell-командах через ${{ }} без экранирования, использование curl вместо надёжных действий для взаимодействия с Jira (технический долг), и логику с `github.event.pull_request` в событиях `issues` — где `pull_request` всегда null, что возвращает `false` при любом условии. Оригинальный шаблон с `env` + `jq` был безопасен: переменные передавались через окружение, а не вставлялись в shell-строку. AI заменил его на опасную подстановку в одинарные кавычки. Ручной аудит диффов стал узким местом: AI упрощает генерацию изменений, но стоимость проверки не снизилась. Культура ревью «LGTM» без анализа превратила AI в просто замену человека в цепочке, не снизив риски. Советы: — Использовать статический анализ (например, zizmor) в CI для выявления template-injection до слияния. — Минимизировать логику в GitHub Actions, вынося сложные операции в отдельные скрипты. — Избегать интерполяции пользовательского ввода в shell через ${{ }} — использовать env-переменные и jq. — Системы, обрабатывающие пользовательский ввод в shell, должны fail-closed при null-значениях — поведение GitHub Actions по умолчанию небезопасно. AI обнажил системные слабости: устаревшие действия, отсутствие статического анализа и слепое доверие к автоматическим изменениям.