Російськомовне угруповання-вимагач Aur0ra використало AI-асистента для написання коду Cursor, щоб зламати щонайменше сім компаній у квітні-травні 2026 року. Деталі атак оприлюднили дослідники з Gambit Security, які відстежували активність групи протягом кількох місяців.

Це один із перших задокументованих випадків, коли комерційний AI coding assistant застосували не для розробки продукту, а як робочий інструмент вимагацької кампанії — не в лабораторних умовах, а в реальних атаках із реальними жертвами. За даними Techmeme, дослідники Gambit Security опублікували технічний розбір того, як угруповання інтегрувало Cursor у власний конвеєр атак.

Для індустрії, що масово переходить на vibecoding і агентну розробку, це сигнал: інструменти, які прискорюють написання легітимного продукту, так само прискорюють написання експлойтів, скриптів ексфільтрації даних і payload-ів для шифрування.

Що саме сталося?

Aur0ra — угруповання-вимагач, що діє за моделлю подвійного вимагання (шифрування даних і вимога викупу під загрозою публікації) — застосувало Cursor AI для написання коду атак і скомпрометувало щонайменше сім компаній у квітні-травні 2026 року. За даними Techmeme, саме дослідники Gambit Security зафіксували й описали цю активність.

Чому AI-асистент прискорює роботу зловмисника так само, як роботу розробника?

Cursor та подібні агентні редактори (GitHub Copilot Workspace, Windsurf, Claude Code) проєктовані для одного сценарію: швидко перетворити намір розробника на робочий код. Модель під капотом не перевіряє, чи мета — легітимна фіча, чи скрипт для обходу захисту: вона виконує технічну постановку задачі. Це та сама причина, чому AI-асистенти скорочують час розробки продукту на десятки відсотків — вона ж працює і для написання інструментів компрометації, лише мета інша.

Для угруповання на кшталт Aur0ra це означає нижчий поріг входу: не потрібна команда досвідчених exploit-розробників — достатньо оператора, який вміє формулювати технічні задачі й перевіряти результат. Свого роду аутсорсинг «brainpower» частини атаки на модель.

Що це означає для команд, які самі впроваджують агентних асистентів?

Головний висновок — не в тому, що Cursor «небезпечний» сам по собі, а в тому, що агентний код, незалежно від того, хто його написав — людина чи AI, і незалежно від намірів автора, потребує того самого рев'ю, що й будь-який інший продакшн-код. За нашою оцінкою, компанії, що дозволяють AI-асистентам писати й деплоїти код без окремого security-гейту, ризикують не лише випадковими вразливостями, а й тим, що зловмисник, який отримав доступ до їхньої інфраструктури, використає ті самі інструменти для розвитку атаки зсередини.

Висновок AiiN

Злам семи компаній кодом, написаним у Cursor, закриває дискусію про те, чи стануть AI coding assistants інструментом атакуючих, — вони вже ним стали, і питання зараз практичне: як компанія відрізняє «розробник прискорив роботу асистентом» від «зловмисник прискорив атаку тим самим асистентом», коли обидва залишають схожий слід у git-історії. Наша теза: у міру того як агентний код стає нормою, security-рев'ю має зміститися з питання «хто написав цей код» на питання «що цей код фактично робить і які права йому дали» — бо перше питання найближчим часом стане непридатним для відповіді.

Чи винен Cursor у цих зломах?

Немає підстав вважати, що вразливість чи навмисна вада була в самому Cursor — за наявними даними, угруповання використало легітимний інструмент за його прямим призначенням, написання коду, тільки зі зловмисною метою. Це той самий клас ризику, що й у будь-якого потужного інструменту подвійного призначення.

Як компанії захиститися від зловживання AI coding assistants у своєму периметрі?

Базовий набір: моніторинг аномальної активності в репозиторіях і CI/CD, обмеження прав сервісних токенів, які використовують агентні інструменти, і обов'язковий security-рев'ю для коду перед деплоєм — незалежно від того, людина його написала чи AI-асистент.