ИИ научился создавать уязвимости, которых не существует.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">В базы уязвимостей попали сообщения о критических проблемах SQLite с оценками до 9,8 балла, однако проверка исходного кода не подтвердила ни одной заявленной ошибки. Исследователи JFrog обнаружили в отчетах несуществующие функции, невозможные номера строк и примеры эксплуатации, которые не вызывали сбоев или утечек памяти. Результаты проверки компания опубликовала 30 июля.
Шесть записей о SQLite входили в подборку из 55 бюллетеней, размещенных в новом малоизвестном репозитории GitHub . Сведения попали в Национальную базу уязвимостей США NVD, а программа обогащения данных CISA добавила собственные оценки. Записи получили от 7,5 до 9,8 балла по шкале CVSS и выглядели как предупреждения о серьезных ошибках управления памятью.
Автоматический анализ выявил признаки вероятной генерации текстов языковой моделью. JFrog не стала полагаться только на детектор и собрала указанные версии SQLite в изолированной среде. Специалисты изучили исходный код, запустили приложенные SQL-запросы под контролем AddressSanitizer и сопоставили описания с данными NVD и GitHub Security Advisories.
Запись CVE-2026-51302 описывала use-after-free, то есть обращение к уже освобожденной области памяти. База Red Hat первоначально присвоила сообщению максимальные 10 баллов, а затем снизила оценку до 7,6. Авторы утверждали, что функция <code>exprComputeOperands()</code> вызывает ошибку в SQLite 3.41.0, хотя указанная функция появилась только в середине 2025 года и отсутствовала в названной версии. Приложенный пример эксплуатации выполнился без сбоя.
В описании CVE-2026-51300 авторы сослались на строки исходного кода, не связанные с предполагаемой ошибкой. SQL-запрос отработал штатно и не вызвал утечек памяти. Запись CVE-2026-51296 указывала на строки 3555 и 3575 файла <code>json.c</code>, хотя файл в SQLite 3.41.0 содержал только 2706 строк. Другие примеры завершались синтаксической ошибкой либо вызывали функции с неправильным числом аргументов.
Расширенная проверка охватила все 55 бюллетеней из репозитория. JFrog признала 54 записи полностью вымышленными. Оставшаяся публикация содержала реальную программную ошибку, но сопровождалась неподтвержденными сведениями о CVE. Помимо SQLite, материалы затрагивали библиотеку обработки RAW-изображений LibRaw и библиотеку декодирования звука ESP32-audioI2S для Arduino.
MITRE впоследствии отклонила всю серию заявок. Официальная страница проекта SQLite также пометила шесть записей как невоспроизводимые проблемы, которые отсутствуют в SQLite и похожи на галлюцинации искусственного интеллекта. Информацию о массовом отклонении заявок опубликовали в рассылке OSS-Security .
Инцидент выявил слабое место системы регистрации уязвимостей. Центры нумерации CVE не всегда располагают нужной программной средой, исходным кодом и ресурсами для самостоятельного воспроизведения каждого отчета. Организации часто полагаются на добросовестность заявителей, особенно при обработке сообщений о сторонних проектах.
NVD автоматически получает записи из списка CVE, после чего аналитики дополняют сведения оценками опасности, перечнями затронутых продуктов и другими метаданными. Действующая система не требует обязательного независимого воспроизведения каждой ошибки. Правдоподобно составленный бюллетень способен попасть в GitHub Security Advisories , сторонние базы и корпоративные сканеры без рабочего примера эксплуатации.
Дополнительную проблему создает очередь необработанных записей NVD. NIST признал рост очереди в феврале 2024 года после резкого замедления анализа. Согласно отчету Управления генерального инспектора Министерства торговли США, число необработанных уязвимостей выросло примерно с 13 000 в начале июня 2024 года до более чем 27 000 к концу 2025 года. Аудиторы связали кризис с отсутствием стратегического плана, недостаточной скоростью обработки и дублированием части работы NIST и CISA.
Ложные CVE заставляют команды безопасности проверять несуществующие угрозы, открывать ненужные задачи и отвлекать специалистов от реальных уязвимостей. Автоматические сканеры и системы управления рисками могут присвоить вымышленной проблеме высокий приоритет, после чего разработчики начнут менять код, который никогда не содержал описанного дефекта.
JFrog рекомендует проверять подтверждение со стороны разработчика, наличие исправляющего коммита или запроса на включение изменений, соответствие версий и корректность метаданных. Ссылки на отсутствующие функции, строки за пределами файла и участки кода без связи с предполагаемой ошибкой служат серьезными признаками подделки. Перед началом срочного исправления специалисты также должны по возможности воспроизвести проблему в безопасной среде.
Исследователи сообщили о находке команде GitHub Security Advisory, Red Hat и операторам NVD. JFrog ожидает дальнейшего роста числа вымышленных бюллетеней, поскольку генеративные модели позволяют быстро создавать технически убедительные описания, а проверка исходного кода, сборка нужной версии и воспроизведение ошибки по-прежнему требуют времени и квалификации.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">В базы уязвимостей попали сообщения о критических проблемах SQLite с оценками до 9,8 балла, однако проверка исходного кода не подтвердила ни одной заявленной ошибки. Исследователи JFrog обнаружили в отчетах несуществующие функции, невозможные номера строк и примеры эксплуатации, которые не вызывали сбоев или утечек памяти. Результаты проверки компания опубликовала 30 июля.
Шесть записей о SQLite входили в подборку из 55 бюллетеней, размещенных в новом малоизвестном репозитории GitHub . Сведения попали в Национальную базу уязвимостей США NVD, а программа обогащения данных CISA добавила собственные оценки. Записи получили от 7,5 до 9,8 балла по шкале CVSS и выглядели как предупреждения о серьезных ошибках управления памятью.
Автоматический анализ выявил признаки вероятной генерации текстов языковой моделью. JFrog не стала полагаться только на детектор и собрала указанные версии SQLite в изолированной среде. Специалисты изучили исходный код, запустили приложенные SQL-запросы под контролем AddressSanitizer и сопоставили описания с данными NVD и GitHub Security Advisories.
Запись CVE-2026-51302 описывала use-after-free, то есть обращение к уже освобожденной области памяти. База Red Hat первоначально присвоила сообщению максимальные 10 баллов, а затем снизила оценку до 7,6. Авторы утверждали, что функция <code>exprComputeOperands()</code> вызывает ошибку в SQLite 3.41.0, хотя указанная функция появилась только в середине 2025 года и отсутствовала в названной версии. Приложенный пример эксплуатации выполнился без сбоя.
В описании CVE-2026-51300 авторы сослались на строки исходного кода, не связанные с предполагаемой ошибкой. SQL-запрос отработал штатно и не вызвал утечек памяти. Запись CVE-2026-51296 указывала на строки 3555 и 3575 файла <code>json.c</code>, хотя файл в SQLite 3.41.0 содержал только 2706 строк. Другие примеры завершались синтаксической ошибкой либо вызывали функции с неправильным числом аргументов.
Расширенная проверка охватила все 55 бюллетеней из репозитория. JFrog признала 54 записи полностью вымышленными. Оставшаяся публикация содержала реальную программную ошибку, но сопровождалась неподтвержденными сведениями о CVE. Помимо SQLite, материалы затрагивали библиотеку обработки RAW-изображений LibRaw и библиотеку декодирования звука ESP32-audioI2S для Arduino.
MITRE впоследствии отклонила всю серию заявок. Официальная страница проекта SQLite также пометила шесть записей как невоспроизводимые проблемы, которые отсутствуют в SQLite и похожи на галлюцинации искусственного интеллекта. Информацию о массовом отклонении заявок опубликовали в рассылке OSS-Security .
Инцидент выявил слабое место системы регистрации уязвимостей. Центры нумерации CVE не всегда располагают нужной программной средой, исходным кодом и ресурсами для самостоятельного воспроизведения каждого отчета. Организации часто полагаются на добросовестность заявителей, особенно при обработке сообщений о сторонних проектах.
NVD автоматически получает записи из списка CVE, после чего аналитики дополняют сведения оценками опасности, перечнями затронутых продуктов и другими метаданными. Действующая система не требует обязательного независимого воспроизведения каждой ошибки. Правдоподобно составленный бюллетень способен попасть в GitHub Security Advisories , сторонние базы и корпоративные сканеры без рабочего примера эксплуатации.
Дополнительную проблему создает очередь необработанных записей NVD. NIST признал рост очереди в феврале 2024 года после резкого замедления анализа. Согласно отчету Управления генерального инспектора Министерства торговли США, число необработанных уязвимостей выросло примерно с 13 000 в начале июня 2024 года до более чем 27 000 к концу 2025 года. Аудиторы связали кризис с отсутствием стратегического плана, недостаточной скоростью обработки и дублированием части работы NIST и CISA.
Ложные CVE заставляют команды безопасности проверять несуществующие угрозы, открывать ненужные задачи и отвлекать специалистов от реальных уязвимостей. Автоматические сканеры и системы управления рисками могут присвоить вымышленной проблеме высокий приоритет, после чего разработчики начнут менять код, который никогда не содержал описанного дефекта.
JFrog рекомендует проверять подтверждение со стороны разработчика, наличие исправляющего коммита или запроса на включение изменений, соответствие версий и корректность метаданных. Ссылки на отсутствующие функции, строки за пределами файла и участки кода без связи с предполагаемой ошибкой служат серьезными признаками подделки. Перед началом срочного исправления специалисты также должны по возможности воспроизвести проблему в безопасной среде.
Исследователи сообщили о находке команде GitHub Security Advisory, Red Hat и операторам NVD. JFrog ожидает дальнейшего роста числа вымышленных бюллетеней, поскольку генеративные модели позволяют быстро создавать технически убедительные описания, а проверка исходного кода, сборка нужной версии и воспроизведение ошибки по-прежнему требуют времени и квалификации.
- Источник новости
- www.securitylab.ru