ИИ теперь имитирует кибератаки

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

Команда безопасности JFrog недавно обнаружила тревожную тенденцию: 54 сфабрикованные уязвимости SQLite, исходящие из одной новой учетной записи GitHub. Аудит 55 бюллетеней из этого источника выявил только одну реальную ошибку; остальные были чистой выдумкой. Примечательно, что анализ GPTZero пометил эти бюллетени как однозначно сгенерированный ИИ контент.

Изучите анатомию одного такого призрака, CVE-2026-51302. В бюллетене утверждалось о наличии уязвимости типа use-after-free в куче в функции exprComputeOperands в SQLite 3.41. Однако расследование JFrog подтвердило, что exprComputeOperands не существовала в этой версии, а появилась только в середине 2025 года. Это не было единичным случаем; в шести бюллетенях JFrog обнаружила последовательные закономерности: упоминание несуществующих функций, номера строк, превышающие лимиты файлов, и патчи, которых никогда не существовало.

Поразительно, но эта откровенная фальсификация все же получила начальную оценку серьезности 9.8 'Critical' от Red Hat. Этот высокий рейтинг вызвал реальные оповещения в организациях, демонстрируя, как легко ИИ-сгенерированный призрак может проскользнуть мимо первичных фильтров. Инцидент подчеркивает опасный новый рубеж, где ИИ может использовать информацию как оружие, создавая правдоподобные угрозы, требующие немедленного, но в конечном итоге бесполезного внимания.

Ахиллесова пята системы теперь обнажена и открыта для эксплуатации. С февраля 2024 года NIST NVD (Национальная база данных уязвимостей) прекратила глубокий анализ заявок, будучи перегруженной огромным объемом невыполненной работы. Этот критический сбой означает, что к концу 2025 года ожидается более 27 000 необработанных уязвимостей, что является резким скачком по сравнению с 13 000 в феврале 2024 года, при этом программа обогащения данных CISA аналогичным образом тонет в собственных очередях.

Усугубляя этот системный сбой, сам процесс подачи CVE практически не предусматривает контроля. Он не требует ни проверки личности, ни какого-либо доказательства концепции для принятия уязвимости. Эта политика «открытых дверей» обеспечивает беспрепятственный путь для любого — или чего угодно — для внесения заявлений непосредственно в глобальную инфраструктуру безопасности без лишних вопросов.

Это создает идеальный шторм, катастрофическое стечение системных уязвимостей. Огромная очередь на анализ в официальной базе данных в сочетании с порталом подачи заявок, не требующим никакой проверки, означает, что низкокачественный ИИ-сгенерированный «мусор» теперь легко попадает в базы данных, от которых зависят инструменты безопасности по всему миру. Автоматизированные системы защиты теперь вынуждены просеивать синтетический шум, потенциально охотясь за несуществующими функциями или пытаясь исправить код, который никогда не был сломан.

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

Представьте автономного агента, пытающегося исправить CVE-2026-51302 — вымышленную уязвимость в SQLite, изначально помеченную Red Hat как критическую. Он потратит вычислительные ресурсы, пытаясь найти несуществующую функцию exprComputeOperands в SQLite 3.41 или исправляя код, который никогда не был сломан. Это не просто теоретическая проблема: аудит JFrog выявил 54 сфабрикованных уведомления из 55, поступивших от одной учетной записи GitHub, и все они были созданы для того, чтобы заставить агентов заниматься бесполезной работой.

Асимметрия этой проблемы поражает. Создание убедительного фальшивого CVE с помощью ИИ практически ничего не стоит — всего несколько центов на вычисления. Однако проверка и опровержение требуют значительных усилий экспертов-людей: кропотливого анализа кода, перекрестных ссылок и независимого исследования. Это создает непосильную нагрузку на команды безопасности, утопающие в море шума, созданного ИИ. Чтобы глубже изучить это явление, прочитайте SQLite Critical CVEs or LLM Slop? - JFrog Security Research.

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

Это не просто совет, а необходимость, продиктованная системными сбоями. Задержка в NIST NVD, которая к концу 2025 года выросла до более чем 27 000 необработанных уязвимостей, создала благоприятную среду для обмана. Система подачи заявок, лишенная проверки личности или доказательства концепции, позволяет сфабрикованным уведомлениям проходить беспрепятственно.

Консенсус в индустрии теперь резко смещается от полностью автоматизированных AI agents для триажа уязвимостей. Будущее требует гибридных моделей, где эксперты-люди проверяют угрозы, выявленные ИИ, выступая в качестве критического фильтра против изощренного цифрового обмана, способного присвоить критический балл 9.8 несуществующему коду.

Созданный ИИ «мусор» будет все больше снижать соотношение сигнал/шум в публичных лентах, заставляя организации адаптировать свою стратегию безопасности. Исходите из того, что каждый новый отчет потенциально является поддельным, пока не доказано обратное, и отдавайте приоритет угрозам, подтвержденным вендором. Ваши операции по безопасности должны стать по своей сути скептичными, инвестируя в человеческий опыт, способный отличить подлинные угрозы от призраков, созданных ИИ. Стоимость проверки сейчас ничтожна по сравнению с операционными затратами на то, чтобы быть обманутым.

Что такое фальшивые CVE, созданные ИИ?

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

Как фальшивая CVE получила критический балл 9.8?

Фальшивое уведомление было отправлено в официальную программу CVE. Из-за огромного объема невыполненной работы NIST NVD проводит менее глубокий анализ, позволяя обрабатывать непроверенные отчеты. Вторичные вендоры, такие как Red Hat, затем присвоили начальный балл на основе ошибочных данных.

Почему фальшивые CVE представляют серьезную угрозу безопасности?

Они вводят в заблуждение автоматизированные инструменты безопасности и команды специалистов, тратя критические ресурсы на несуществующие угрозы. Ситуация «мальчик, который кричал: «Волки!» подрывает доверие и может привести к тому, что команды пропустят реальные уязвимости.

Как защитить свою организацию от фальшивых CVE?

Всегда проверяйте критические CVE на официальной странице рекомендаций по безопасности от поставщика, прежде чем предпринимать какие-либо действия. Внедрите процесс «человек в контуре» (human-in-the-loop) для проверки оповещений от автоматизированных систем и никогда не доверяйте CVE без дополнительной проверки.