Две критические уязвимости PHP, которые существовали годами, могли дать атакующим контроль над сервером, доступ к данным или возможность вывести сайт из строя. Быстрый путь к обновлению для множества систем обеспечил чешский разработчик Ондржей Сурый — волонтёр, более 20 лет поддерживающий PHP-пакеты для Debian и Ubuntu; для российского IT это ещё одно напоминание, что бизнес часто стоит на коде, за который почти никто не отвечает по найму.
О деталях инцидента и словах Сурого сообщает vc.ru. PHP Foundation узнала о масштабе проблемы в августе 2026 года после проверок OpenAI и компаний Calif и Wiz. В Wiz назвали найденные дефекты потенциально одними из наиболее серьёзных в истории программного обеспечения, хотя практическая эксплуатация, по оценке исследователей, потребовала бы чрезвычайно высокого уровня подготовки. Выявить уязвимости помог ИИ.
Впервые на подозрительные места в PHP обратили внимание ещё в 2024 году. Однако команда не выпустила исправления сразу: не был понятен реалистичный сценарий атаки, подходящий патч мог сломать работу существующего кода, а ресурсов на глубокую проработку не хватало. Это неприятная, но знакомая для инфраструктурных проектов развилка: риск уже виден, а безопасного и совместимого решения всё ещё нет.
Официальные обновления вышли для четырёх актуальных веток PHP. Сурый подготовил пакеты, которые позволяют администраторам быстро поставить исправления на Debian и Ubuntu, а также опубликовал собственные патчи для части старых версий. Без этой работы обновление превращалось бы для многих команд в ручную операцию со сборкой кода, проверкой зависимостей и риском сломать продакшен. Формально это «всего лишь упаковка», фактически — мост между исправлением в репозитории и тысячами серверов, которые должны пережить обновление.
Сурый не драматизирует собственную роль. Он рассказал, что не испытывал паники: решение существовало, а сама уязвимость не угрожала его личным проектам. Но ответственность перед пользователями он ощущал. После релиза разработчику начали массово отправлять пожертвования; по его словам, за сутки он получил примерно столько, сколько обычно получает за год, а позднее сообщил BBC о сумме свыше $10 тысяч за несколько дней.
Эти деньги выглядят заметно только на фоне обычного для независимого сопровождения нуля. Исполнительный директор PHP Foundation Элизабет Баррон ранее говорила, что в организации на полной ставке работает лишь она сама; ещё 14 подрядчиков заняты неполный день, а совет директоров состоит из добровольцев. Финансирование держится на донатах и грантах. При этом PHP используется при создании почти 70% сайтов, по приведённой в источнике оценке. Контраст между масштабом зависимости и моделью поддержки трудно не заметить.
Особенно тревожен второй слой истории — старые системы. Сурый подчёркивает, что установить патч смогут не все: устаревшие устройства и неподдерживаемые развёртывания нередко остаются без обновлений. Даже после публичного раскрытия критические уязвимости PHP не исчезают сами по себе: они остаются на серверах, где обновление отложили из-за нехватки времени, опасений за совместимость или отсутствия владельца системы. Для атакующих это обычная арифметика: чем дольше длится хвост непропатченных инсталляций, тем выше ценность готового эксплойта.
Для разработчиков вывод довольно приземлённый: проверять версию PHP и доступность обновлений стоит не только после громких заголовков. Нужны инвентаризация зависимостей, понятный владелец процесса патчинга, тестовый контур и план для legacy-систем, которые нельзя обновить одним нажатием. Для продуктовых и IT-руководителей вопрос шире: критичная зависимость должна иметь не только строку в SBOM, но и бюджет на сопровождение, аудит и время команды на обновления.
Сурый прямо называет нынешнее состояние open source эксплуатацией: компании извлекают из кода огромную пользу, а поддержка часто остаётся на энтузиастах. Он уже обсуждает преемственность своей работы с основателем французской IT-компании Freexian Рафаэлем Герцогом — разумная мера для человека, чей опыт стал частью цепочки поставки обновлений. История с PHP ставит неудобный вопрос: сколько ещё базовых проектов должны пройти через аварию, прежде чем поддержка открытого кода станет для компаний регулярной статьёй расходов, а не разовой реакцией на угрозу?
