Угруповання Aur0ra зламало щонайменше 10 компаній, використовуючи AI-редактор коду Cursor для написання шкідливого програмного забезпечення та прискорення атак. Йдеться про російськомовних зловмисників, які замінили частину рутинної роботи з написання експлойтів і скриптів на запити до coding-агента — і отримали результат достатньо швидко, щоб масштабувати кампанію на десяток організацій.
Це не перший випадок, коли зловмисники використовують генеративний ШІ для допоміжних завдань — фішингові листи чи маскування коду писали й раніше. Але тут ідеться про інше: AI-асистента застосували не для тексту, а для написання робочого шкідливого коду в межах повноцінного циклу атаки. За даними Mezha, це один з перших задокументованих випадків масового зловживання coding-агентом у реальних, а не лабораторних атаках.
Для індустрії це важливий прецедент: Cursor — популярний інструмент серед розробників, побудований на великих мовних моделях, і те, що він однаково добре пише і легітимний, і шкідливий код, ставить під сумнів ідею, що безпека AI-асистентів — це виключно проблема вендора.
Що саме зробили хакери Aur0ra?
За наявними даними, угруповання застосувало Cursor як інструмент написання коду для атак на щонайменше десять компаній. AI-асистент допоміг прискорити розробку шкідливих скриптів — тобто зловмисники отримали ту саму перевагу продуктивності, яку coding-агенти дають звичайним розробникам, тільки застосували її до протилежної мети.
- Ціль — щонайменше 10 організацій, атакованих однією групою
- Інструмент — Cursor, AI-редактор коду на основі великих мовних моделей
- Роль AI — написання шкідливого коду й пришвидшення підготовки атак
Деталей про конкретні вразливості, галузі постраждалих компаній чи техніки проникнення джерело не наводить, тому робити висновки про масштаб збитків чи специфіку атак передчасно.
Чому coding-агенти такі привабливі для зловмисників?
Coding-агенти на кшталт Cursor знижують поріг входу в написання коду — саме тому вони настільки популярні серед розробників-початківців і нетехнічних продакт-менеджерів. Той самий ефект працює й у зворотному напрямку: людині не обов'язково глибоко розуміти мову програмування чи специфіку експлойта, щоб отримати від агента робочий фрагмент коду під конкретну задачу.
Ймовірно, ключова причина застосування Cursor саме зловмисниками — швидкість ітерації: агент дозволяє генерувати й одразу тестувати варіанти коду, не чекаючи на ручне написання кожного модуля з нуля. Це прямий аналог того, чому легітимні команди переходять на agentic coding, — тільки метрика успіху інша.
Що робити командам, які вже використовують AI coding-агентів?
Перший крок — визнати, що інструмент, який прискорює вашу розробку, так само прискорює й атакуючого, якщо агент чи його вивід потрапить не в ті руки. Це не привід відмовлятися від Cursor, Claude Code чи інших агентів, а привід поставити навколо них ті ж контролі, що й навколо будь-якого іншого каналу виконання коду.
- Логувати й переглядати запити до coding-агентів так само, як код-рев'ю — особливо для агентів з доступом до продакшн-систем
- Обмежувати права агента мінімально необхідним доступом, а не адмінським за замовчуванням
- Моніторити аномальну активність облікових записів розробників — швидкий сплеск комітів чи запитів може вказувати на компрометацію, а не на продуктивність
- Мати окремий інцидент-план саме для сценарію «зламаний обліковий запис + AI-агент», а не покладатися на загальні процедури реагування
Ми вже писали про те, як бракує контролю навіть у мирних сценаріях — наприклад, вендор AI cost-management не впорався з витратами власного агента. Якщо гардрейли підводять у звичайній експлуатації, розраховувати, що вони самі собою зупинять зловмисника, точно не варто.
Висновок AiiN
Наша теза проста: інструменти безпеки навколо coding-агентів досі відстають від темпів їх упровадження в командах розробки, і кейс Aur0ra — перший явний сигнал, що цей розрив вже експлуатують, а не лише обговорюють на конференціях. AI-вендори здебільшого фокусують захист на промпт-ін'єкціях і jailbreak-спробах усередині самого чату, тоді як реальна атака сталася на рівні використання готового продукту як звичайного інструменту розробника — без жодного «злому» самої моделі. Це означає, що відповідальність за гардрейли переходить із площини «безпечна модель» у площину «безпечний процес розробки», і саме там компаніям варто інвестувати найближчим часом.
Скільки компаній постраждало від атак Aur0ra з використанням Cursor AI?
За наявними даними, щонайменше 10 компаній. Точний список постраждалих організацій і галузей джерело не розкриває.
Чи означає цей випадок, що Cursor AI небезпечний сам по собі?
Ні — Cursor лишається звичайним AI-редактором коду для розробників. Проблема не в конкретному продукті, а в тому, що будь-який coding-агент можна застосувати як до легітимних, так і до шкідливих задач, тому контроль має лежати на стороні процесів компанії, яка ним користується, а не лише на стороні вендора.