Как AI-генерация кода создаёт уязвимости в WordPress-плагинах. Разбор 35 багов, практические советы по защите и новый закон ЕС. Начните аудит сейчас!
Представьте: вы выпускаете собственный AI-плагин для чата, проходите аудит безопасности и получаете 35 багов, три из которых — критические. Худший момент в карьере? А затем вы читаете отчёт за 2026 год и понимаете, что 35 — это ещё мелочи. В этой статье разберём, почему AI-код стал главной угрозой для плагинов, как защитить свой проект и что делать прямо сейчас.
Исследователи безопасности с помощью AI-статического анализа и автоматической верификации обнаружили более 300 критических zero-day уязвимостей в экосистеме WordPress-плагинов всего за 72 часа сканирования. Каждая находка была подтверждена вручную перед раскрытием. Отчёт Patchstack за 2026 год называет одну из причин: vibe coding — когда разработчики поставляют сгенерированный LLM код, который не могут проверить. Одно агентство сообщило о 100 проблемах безопасности в единственном плагине, написанном в стиле vibe coding.
AI одновременно ускорил обе стороны: пишет плагины быстро, пропуская скучные части безопасности (экранирование, проверки прав, nonce), и так же быстро находит эти дыры — уже со стороны атакующих. Два фактора, защищавшие маленькие плагины — неизвестность и время — исчезли. Patchstack измерил медианное время от публичного раскрытия до массовой эксплуатации: примерно 5 часов. Стандартный совет «обновляйте плагины» предполагает окно для реакции. 5 часов — это не окно.
Соло-авторы часто недооценивают одну вещь: AI-коду доверяют дважды. Сначала потому, что его написала нейросеть — значит, наверное, корректно. А затем внутри самого кода, где вывод модели считается безопасным и обрабатывается без проверки. Оба доверия были ошибочными в моём коде.
Конкретный пример: HTML-инъекция на стороне вывода. Я рендерил ответ модели прямо на страницу как HTML, потому что молчаливо предположил: раз сгенерировано моделью — значит, чисто. Но это не так. Вывод модели содержит чужой контент: то, что ввёл пользователь, то, что подтянулось из внешних источников. Если считать это безопасным, никакая защита на входе не спасёт — утечка произойдёт на выходе.
Я перестал считать «работает» синонимом «безопасно». Теперь я вручную читаю каждый AI-написанный обработчик в трёх местах: вход, выход и права доступа.
На выходе я рассматриваю ответ модели как недоверенный ввод и нейтрализую его в зависимости от контекста: экранирую для HTML, использую allowlist для Markdown, проверяю URL перед загрузкой. В терминах WordPress это скучные функции, которые модель любит пропускать: esc_html, wp_kses с жёстким allowlist, current_user_can и проверка nonce на каждой AJAX и REST точке входа, $wpdb->prepare на каждой записи. Ничего нового — это веб-безопасность, которую мы всегда делали, теперь направленная на половину кода, который я не писал сам.
И поверхность атаки растёт. WordPress 7.0 представил Abilities API, позволяющий плагинам стандартным образом открывать действия для AI-агентов. Это полезно, но это и свежее место для утечек из-за недостаточно ограниченных прав. Я внимательно слежу за этим, потому что плагин, дающий агенту больше полномочий, чем нужно — следующая версия той же ошибки.
Отчёт Patchstack показал: 52% разработчиков плагинов не выпускают патч до публичного раскрытия уязвимости, а 46% раскрытых уязвимостей вообще не имеют исправления на момент раскрытия. Поиск багов перестал быть узким местом — AI делает это за секунды. Узкое место — всё, что после. Большинство плагинов бесплатны, поддерживаются одним человеком в свободное от основной работы время. Плагин с нулевым доходом не может оправдать затраты на быстрый патч безопасности. Режим отказа экосистемы в 2026 году не в том, что баги трудно найти, а в том, что люди, которые могли бы их исправить, не получают за это оплату. AI не создал этот разрыв — он лишь сделал его видимым в масштабе и дал атакующим фору в 5 часов.
Это переопределяет понятие «ответственности» для таких разработчиков, как я. Писать аккуратнее — необходимо, но недостаточно, потому что даже при аккуратности пропущенные дыры теперь находятся за секунды тем, кто не на моей стороне.
Есть и временные рамки. К сентябрю 2026 года разработчики плагинов и тем, распространяющие их среди пользователей ЕС, обязаны по закону иметь программу раскрытия уязвимостей. Для соло-автора это звучит как лишняя бюрократия, но это единственное структурное исправление, соответствующее угрозе: реальный канал, куда можно сообщить о найденном AI баге тихо, до того как он станет публичным CVE с пятичасовым таймером. Создать такой канал несложно: контакт для безопасности в readme плагина или файл SECURITY, место для отчётов, отличное от публичного трекера, и заявленное время ответа, чтобы репортёр знал, что сообщение не останется непрочитанным. Суть не в формальностях, а в том, чтобы у нашедшего баг было место отправить его до превращения в публичный CVE.
35 багов научили меня не доверять коду, который я не писал. Этот год научил остальному. Окно для исправления моих ошибок стало короче, чем когда-либо, и неизвестность никогда меня не защищала.
Если вы поставляете плагины, с AI-помощью или без, ваше действие — не писать аккуратнее и надеяться. Действие — предположить, что дыры уже находятся за секунды, и построить защиту, которая поймает их первой: ручная проверка входа, выхода и прав, санитизация вывода, канал раскрытия, через который дружелюбный незнакомец свяжется с вами раньше, чем это сделает недружелюбный.
Что делать прямо сейчас:
esc_html, wp_kses).current_user_can) и nonce на каждую AJAX/REST точку.Источники: Отчёт Patchstack 2026 State of WordPress Security (vibe coding, медиана массовой эксплуатации 5 часов, цифры 52% и 46% патчей, требование ЕС о программе раскрытия). 300+ zero-day за 72 часа — отчёт Help Net Security. 100 проблем в одном плагине и WordPress 7.0 Abilities API — writeup hosting.com. Пожалуйста, сверьтесь с первоисточниками перед публикацией.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →