Компания Sygnia, занимающаяся реагированием на инциденты, провела оценку приложения для онбординга клиентов, которое было в значительной степени создано с использованием Claude. Оно обрабатывало выданные государством удостоверения личности, данные для верификации личности, платежные реквизиты и номера социального страхования.
Обнаруженная уязвимость позволяла одному соискателю получить доступ к записям другого соискателя.
Что именно сломалось
Приложение решало вполне реальную проблему. Люди начинают заполнять заявку, уходят, а затем возвращаются до того, как у них появится аккаунт, поэтому система должна восстанавливать их прогресс без использования пароля.
Claude сгенерировал для этого модель временного доступа. Проблема крылась в том, как именно модель определяла, кто заслуживает получения токена.
Наличие глобального уникального идентификатора соискателя (GUID) считалось достаточным доказательством для выдачи или восстановления токена доступа для этого человека.
«По сути, GUID превратился в секретный токен на предъявителя», — отметила компания Sygnia в своем исследовании.
GUID идентифицирует запись. Он не доказывает, что тот, у кого он находится, действительно контролирует сеанс, устройство, личность или привязанный к ней верифицированный канал связи.
Любой обладатель GUID другого соискателя мог получить доступ к именам, контактным данным, статусу заявки, финансовой информации, данным проверки личности, платежным реквизитам, номерам социального страхования и записям созаявителей.
Стоит сделать паузу и упомянуть созаявителей. Это люди, чьи данные попали в систему просто потому, что кто-то другой указал их в своей заявке.
Все средства защиты были на месте
Вот что делает эту находку необычной, и это совсем не та история, которую обычно рассказывают об ошибках кодирования с помощью ИИ.
В реализации не было недостатка в безопасности. Sygnia описывает план, охватывающий временные токены, срок их действия, ограничение частоты запросов (rate limiting), аудит-логирование, восстановление сеансов и обнаружение подозрительной активности.
Каждый из этих элементов — вполне реальная мера защиты. Вот только ни один из них не отвечает на тот вопрос, на который система действительно должна была ответить.
«Что именно должно быть доказано перед тем, как бэкенд выдаст или восстановит токен доступа соискателя?» — задаются вопросом исследователи.
Уязвимость существовала еще до выдачи токена — в тот момент, когда система решала, заслуживает ли вообще запрашивающий получения этого токена.
«Проблема была не в том, что в системе не хватало средств контроля безопасности, — писала Sygnia. — Проблема заключалась в том, что эти средства были привязаны к неверному решению о доверии».
Краткосрочный токен все равно наносит ущерб, когда попадает не в те руки. Журналы аудита помогают при последующем расследовании, но ничего не предотвращают.
Почему сканеры упускают это из виду
Инструменты статического тестирования безопасности приложений (SAST) ищут небезопасные шаблоны кодирования и опасные потоки данных. Данный случай не относился ни к тому, ни к другому.
Это была архитектурная уязвимость. Она коренилась в допущении относительно доверия, написанном в коде, который следовал привычным соглашениям фреймворка и проходил базовые проверки.
«Рабочий код — не то же самое, что безопасный код», — заявил Зак Мид (Zach Mead), специалист по тестированию на проникновение из Sygnia, проводивший оценку.
«Код, сгенерированный ИИ, может компилироваться, следовать привычным шаблонам и проходить базовые проверки, но при этом содержать ошибочные предположения о границах доверия, авторизации, состоянии, правах владения или сторонних интеграциях», — отметил он.
Его указание для команд безопасности звучит бескомпромиссно: относитесь к результатам работы ИИ как к ненадежным до тех пор, пока они не будут проверены.
ИИ нашел то, что создал ИИ
Sygnia не обнаружила это вручную. Компания запустила языковую модель по фрагментам клиентской кодовой базы в поисках проблем с границами доверия и логических ошибок бизнес-логики.
Модель напрямую указала на проблему с токенами соискателей.
Резюме Sygnia по этому поводу — самая яркая фраза во всем исследовании. Архитектурная уязвимость безопасности, созданная в стиле «вайб-кодинга» (vibe-coding), была выявлена с помощью код-ревью, выполненного в том же стиле.
Это палка о двух концах, и компания прямо об этом говорит. Если защитники могут спросить модель, где отсутствуют границы доверия, то же самое может сделать любой, у кого в руках окажется утечка исходного кода или украденные проектные заметки.
Компания Cisco по этой же причине задействует модели с открытыми весами для поиска багов. Одна способность — два применения.
Проблема темпа
Это исследование соседствует со вторым кейсом Sygnia, и их сочетание убедительно подкрепляет общую мысль.
В ходе расследованного фирмой облачного инцидента первым сигналом тревоги был вовсе не эксплойт. Это была скорость.
Обнаружение учетных данных, перечисление облачных ресурсов, анализ исходного кода, зондирование CI/CD, доступ к базам данных и нарушение операционной деятельности — всё это происходило одновременно. Это больше напоминало действия группы операторов, а не одного человека.
Однако за всем этим стоял всего один человек, работавший с агентами.
Если сложить оба кейса вместе, картина становится предельно ясной. ИИ ускоряет процесс написания кода, обнаружения уязвимостей и превращения слабых мест в векторы атак. Мы уже отследили четыре отдельные атаки, имеющие в своей основе единую уязвимость.
Что Sygnia рекомендует клиентам
Не запрещать инструменты. Запреты лишь загоняют их использование в личные аккаунты, где их никто не сможет отследить.
Компания предлагает маркировать пулл-реквесты (pull requests), которые были сгенерированы или существенно изменены с помощью ИИ, указывать используемый инструмент и отмечать задачи, затрагивающие аутентификацию, платежи, экспорт данных или регулируемую клиентскую информацию.
Самый конкретный совет касается промптов (запросов). Запрос вроде «временные токены доступа для соискателей» — это неполная инструкция.
Более безопасный промпт должен уточнять, что идентификаторы соискателей нельзя рассматривать как секреты, что выдача токена требует независимого подтверждения того, что соискатель контролирует сеанс, и что негативные тесты должны доказывать невозможность получения одним соискателем доступа к записям другого.
Требования безопасности должны быть прописаны в самом запросе, поскольку модель не станет самостоятельно додумывать модель рисков конкретной организации.
Одно оговорка, которую стоит упомянуть
Это отчет вендора о безымянном клиенте, опубликованный одновременно с запуском новой коммерческой услуги.
Sygnia запустила направление AI Cybersecurity Services в тот же день, охватывающее оценку уровня защищенности, управление и тестирование на проникновение в ИИ-приложения. Никто не может независимым образом верифицировать эти выводы, и ни одна другая компания пока не сообщала о подобных инцидентах.
Тем не менее, описанный механизм поддается проверке и перекликается с нашими предыдущими материалами о кризисах безопасности вайб-кодинга, побегах из песочницы у агентов-кодеров и уязвимостях инъекции промптов в GitHub Action для Claude Code.
Что отличает данный случай, так это то, где именно находилась уязвимость. Раньше проблемы возникали в самих инструментах разработки. В этот же раз сгенерированный ИИ код принес уязвимость прямо в продакшн регулируемого бизнеса — и всё это вокруг данных, которые клиенты обязаны предоставлять по закону.
Опубликовано 28 июля 2026 - 10:35 Наверх
