ИИ 15 лет хранил зомби-баг на плаву — но похоже, дни его сочтены
NewsMakerБаг из 2010 года не просто выжил — он стал частью ИИ.
Пятнадцатилетняя уязвимость , впервые опубликованная в Gist на GitHub в 2010 году , продолжает заражать открытые проекты, обучающие материалы и даже большие языковые модели. Несмотря на предупреждения разработчиков в 2012, 2014 и 2018 годах, пример с уязвимым кодом перекочевал в документацию MDN и ответы на Stack Overflow , а затем оказался в тренировочных данных LLM.
Исследователь Яфар Ахундали из Лейденского университета вместе с коллегами разработал автоматизированную систему, способную находить, эксплуатировать и устранять эту уязвимость в проектах на GitHub. Работа описана в препринте на arXiv под названием "Eradicating the Unseen: Detecting, Exploiting, and Remediating a Path Traversal Vulnerability across GitHub".
Речь идёт об экземпляре CWE-22 — типичной уязвимости обхода путей (path traversal), при которой с помощью конструкции вроде
Авторы провели тест с участием Claude, Gemini, GPT-3.5, GPT-4, GPT-4o и нескольких режимов Copilot. Когда модели просили написать простой сервер без сторонних библиотек, 76 из 80 запросов возвращали уязвимый код. Даже при прямом запросе на «безопасную» версию, 56 из 80 примеров оставались уязвимыми. Особенно плохо себя показали GPT-3.5 и Copilot (balanced) — они не сгенерировали ни одного безопасного варианта.
Автоматизированная система, построенная командой, способна сканировать публичные репозитории, воспроизводить атаку в песочнице, и при подтверждении уязвимости — автоматически формировать и отправлять патч. Для генерации исправлений используется GPT-4, а уведомления о находках направляются авторам проектов по email, чтобы не раскрывать уязвимости публично.
Из 40 546 репозиториев, система выявила 41 870 уязвимых файлов. После фильтрации статическим анализом осталось 8 397, из которых 1 756 оказались эксплуатируемыми. Было сгенерировано и отправлено 1 600 валидных патчей. Однако общее число проектов, применивших исправления, составило всего 63 — менее 15% из тех, кто получил уведомление.
По словам Ахундали, причина низкой реакции — в том, что многие проекты заброшены, либо уязвимый код не доходит до продакшн-среды. Тем не менее, это не снижает риск: если уязвимость используется в CI/CD или на машине разработчика, она может привести к компрометации системы.
Авторы отмечают: LLM сегодня становятся не только инструментом генерации кода, но и каналом распространения уязвимостей. Даже популярные модели уверенно выдают небезопасные решения, при этом утверждая, что они защищены. С учётом роста «агентов программирования» и практики «кодинга по вайбу», слепое доверие к ИИ-ассистентам без анализа их вывода — прямой путь к инцидентам .
Пятнадцатилетняя уязвимость , впервые опубликованная в Gist на GitHub в 2010 году , продолжает заражать открытые проекты, обучающие материалы и даже большие языковые модели. Несмотря на предупреждения разработчиков в 2012, 2014 и 2018 годах, пример с уязвимым кодом перекочевал в документацию MDN и ответы на Stack Overflow , а затем оказался в тренировочных данных LLM.
Исследователь Яфар Ахундали из Лейденского университета вместе с коллегами разработал автоматизированную систему, способную находить, эксплуатировать и устранять эту уязвимость в проектах на GitHub. Работа описана в препринте на arXiv под названием "Eradicating the Unseen: Detecting, Exploiting, and Remediating a Path Traversal Vulnerability across GitHub".
Речь идёт об экземпляре CWE-22 — типичной уязвимости обхода путей (path traversal), при которой с помощью конструкции вроде
path.join можно получить доступ к директориям за пределами разрешённой области. На практике это может привести как к утечке файлов, так и к DoS-атакам через переполнение памяти. Авторы провели тест с участием Claude, Gemini, GPT-3.5, GPT-4, GPT-4o и нескольких режимов Copilot. Когда модели просили написать простой сервер без сторонних библиотек, 76 из 80 запросов возвращали уязвимый код. Даже при прямом запросе на «безопасную» версию, 56 из 80 примеров оставались уязвимыми. Особенно плохо себя показали GPT-3.5 и Copilot (balanced) — они не сгенерировали ни одного безопасного варианта.
Автоматизированная система, построенная командой, способна сканировать публичные репозитории, воспроизводить атаку в песочнице, и при подтверждении уязвимости — автоматически формировать и отправлять патч. Для генерации исправлений используется GPT-4, а уведомления о находках направляются авторам проектов по email, чтобы не раскрывать уязвимости публично.
Из 40 546 репозиториев, система выявила 41 870 уязвимых файлов. После фильтрации статическим анализом осталось 8 397, из которых 1 756 оказались эксплуатируемыми. Было сгенерировано и отправлено 1 600 валидных патчей. Однако общее число проектов, применивших исправления, составило всего 63 — менее 15% из тех, кто получил уведомление.
По словам Ахундали, причина низкой реакции — в том, что многие проекты заброшены, либо уязвимый код не доходит до продакшн-среды. Тем не менее, это не снижает риск: если уязвимость используется в CI/CD или на машине разработчика, она может привести к компрометации системы.
Авторы отмечают: LLM сегодня становятся не только инструментом генерации кода, но и каналом распространения уязвимостей. Даже популярные модели уверенно выдают небезопасные решения, при этом утверждая, что они защищены. С учётом роста «агентов программирования» и практики «кодинга по вайбу», слепое доверие к ИИ-ассистентам без анализа их вывода — прямой путь к инцидентам .