Как открытые модели ИИ помогают хакерам искать уязвимости в коде

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

Для криптобирж, кошельков и платёжных платформ это вполне конкретная угроза. Ошибка в проверке прав, обработке вывода средств или взаимодействии сервисов может стать отправной точкой атаки. ИИ помогает исследовать такие ошибки и проверять больше предположений. При этом его результативность зависит от качества модели, доступного кода и инструментов, которые проверяют её выводы.

Информационный дисклеймер. Статья носит информационный и аналитический характер. Её цель — объяснить угрозы и способы защиты. Описания не являются инструкцией по проведению атак. Проверять безопасность систем следует только с разрешения владельца. Примеры для криптосервисов иллюстрируют возможные риски; результаты исследовательских тестов не равны вероятности взлома действующей компании.

Почему хакеры запускают модели ИИ на своих серверах

У привычного облачного чат-бота есть оператор: компания, которая обслуживает модель, задаёт правила и может ограничить доступ. Скачанная модель работает иначе. Её владелец сам выбирает, где она запускается, какие данные получает и к каким программам имеет доступ.

Точнее называть такие модели моделями с открытыми весами, или open-weight. Веса — это параметры, которые модель приобрела во время обучения. Доступ к ним позволяет запускать модель самостоятельно, хотя обучающие данные и все подробности её создания могут оставаться закрытыми. Так работают и законные системы, например инструменты проверки конфиденциального корпоративного кода.

Для злоумышленника самостоятельное размещение ценно тем, что разработчик модели теряет контроль над использованием конкретной копии. Он не видит каждый запрос и не может остановить её работу блокировкой аккаунта. Британский AI Security Institute отдельно указывает на этот риск: после публикации весов меры контроля облачных сервисов невозможно распространить на все независимые развёртывания.

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

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

Как ИИ ищет уязвимости в коде сервиса

Представим платёжный сервис с несколькими тысячами файлов. Проверка прав находится в одном модуле, работа со счетами — в другом, а обработка вывода средств — в третьем. Чтобы заметить опасную ошибку, нужно понять, как эти части связаны.

ИИ может помочь восстановить такую связь: откуда приходит значение, какие проверки оно проходит и какая операция использует его в конце. Например, модель замечает, что обработчик удостоверяется во входе пользователя в систему, но не проверяет, принадлежит ли ему запрошенный счёт. Это известный класс ошибок авторизации, который OWASP описывает как Broken Object Level Authorization. Проще говоря, сервис узнал пользователя, но не убедился, что ему разрешено действовать с конкретным объектом.

Одного убедительного объяснения недостаточно. Модель могла не заметить проверку в другом файле или неверно понять назначение функции. Поэтому её подключают к программной оболочке, которая предоставляет нужные фрагменты кода, запускает тесты и возвращает результаты. Модель предлагает гипотезу, получает ответ программы и уточняет вывод. Так устроен ИИ-агент для анализа кода: он может продолжать исследование после первого ответа.

На изолированной копии приложения такая система проверяет, возникает ли ошибка в действительности. Если тест завершается неудачно, агент разбирает причину. Если предполагаемая уязвимость обнаруживается и в исправленной версии, это повод усомниться в проверке. Разработчики исследования Semgrep используют подобные проверки, чтобы отличать понимание ошибки от реакции на знакомые имена и фрагменты кода.

Повторение меняет практическую ценность ИИ. Человек не обязан вручную разбирать каждый промежуточный результат: часть этой работы получает агент. Однако настройка среды, проверка находок и оценка последствий по-прежнему требуют ресурсов и компетенций.

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

Что открытые модели уже умеют на практике

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

Показательный результат опубликовала Aikido в августе 2026 года. Исследователи проверяли модели на 32 недавно раскрытых уязвимостях в реальных проектах. Модели получали исходный код; доступ в интернет был отключён. Сравнивался основной этап анализа внутри общей системы, а не самостоятельная работа каждой модели без дополнительных инструментов.

DeepSeek V4 Pro 0813 обнаружила 17 уязвимостей в первом проходе. Если объединить находки трёх проходов, получаются уже 28 из 32. Но стабильно, во всех трёх проходах, модель находила только 10.

В пересчёте это 87,5% уязвимостей хотя бы в одной попытке и 31,3% во всех трёх. Расчёт сделан нами по опубликованным числам. Разница объясняет, почему одиночный ответ плохо описывает возможности системы: повторные проверки расширяют охват, но результат остаётся нестабильным. Это тест на повторное обнаружение известных ошибок, а не показатель успешности взлома криптобирж.

Более широкую картину даёт оценка AI Security Institute. В использованных им заданиях ведущие открытые модели соответствовали уровню закрытых моделей, выпущенных на четыре–семь месяцев раньше. Это оценка конкретных тестов, включая искусственно подготовленные сети, а не универсальный рейтинг. Для защитников она означает, что серьёзные возможности анализа становятся доступны и за пределами контролируемых облачных сервисов.

Что показывают реальные инциденты

В мае 2026 года исследователи Sysdig описали атаку через уязвимость marimo, инструмента для работы с Python. После первоначального проникновения атакующий использовал найденные учётные данные для дальнейшего доступа и добрался до внутренней базы PostgreSQL. По совокупности признаков записанной сессии авторы связали действия после проникновения с ИИ-агентом, который учитывал промежуточные результаты. Какую модель использовали и где она работала, установлено не было. Материал также не доказывает, что первоначальную уязвимость нашёл ИИ.

В июньском разборе Sysdig об использовании чужих вычислительных ресурсов видна другая часть картины. Оператор подключил доступный без авторизации сервер Ollama к инструменту автоматизированного тестирования безопасности. Ollama — программное обеспечение для запуска моделей на собственной инфраструктуре. Исследователи наблюдали, как инструмент менялся и получал новые этапы работы.

В этом эпизоде сервер был чужим, а цели находились в частных учебных сетях. Он показывает техническую архитектуру и злоупотребление вычислительными ресурсами, но не подтверждает успешную атаку таким инструментом на публичную компанию.

Эти случаи помогают понять, какие части процесса уже существуют. Они не дают оснований приписывать конкретное хищение криптоактивов открытой модели на сервере хакера. Для такого вывода нужны дополнительные свидетельства: например, журналы запросов к модели и следы работы связанной с ней программы. Быстрые или необычные действия атакующего сами по себе этого не доказывают.

Какие ошибки особенно опасны для криптосервисов

Для криптокомпании последствия зависят от того, куда ведёт найденная ошибка. Доступ к обычной странице и возможность повлиять на вывод средств имеют разный вес. Поэтому при анализе риска мы связываем дефект в коде с полномочиями сервиса и финансовой операцией, которую он способен изменить.

Один из чувствительных участков — API, интерфейс обмена данными между программами. Через него приложение запрашивает баланс, создаёт операции и получает их статус. Если сервер неправильно связывает пользователя со счётом или организацией, действующая сессия может давать лишние права. В таких местах важно проверять права на каждом серверном действии, включая менее заметные служебные и пакетные операции.

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

У децентрализованных сервисов дополнительный материал для анализа даёт опубликованный код смарт-контрактов. Модель может помогать исследовать правила доступа и движения активов. Но вывод о безопасности зависит также от настроек развёрнутого контракта, связанных контрактов и экономических условий. Даже корректно найденная программная ошибка не всегда превращается в возможность украсть средства.

Наконец, важны границы между сервисами. Компонент, обрабатывающий внешние данные, не должен автоматически получать полномочия на подпись транзакций или доступ ко всем секретам компании. Чем шире его права, тем больше возможностей даёт одна уязвимость.

Как защищаться от атак с помощью ИИ

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

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

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

При расследовании нужно связать события приложения с действиями в инфраструктуре и транзакциями в блокчейне. История переводов показывает движение активов, но обычно не объясняет, какая ошибка дала первоначальный доступ. Для этого нужны журналы запросов, операций и изменений прав. Поэтому рекомендуем заранее сохранять данные, которые позволят восстановить путь от обращения к сервису до финансового результата.

Открытые модели делают систематическое исследование кода доступнее. Для криптосервиса практический ответ — регулярно проверять критические операции и строить систему так, чтобы отдельная ошибка не давала доступа ко всем активам.