Действительно ли были взломаны 5000 разработчиков? К каким последствиям привело заражение плагина Cursor на данный момент?

Примечание автора: в этой статье разберём, что на самом деле означает оценка «затронуто до 5000 человек» в инциденте с заражённым расширением Cursor, как развивалась атака, какие случаи подтверждены, кому грозит утечка API-ключа и как проверить свою систему. Это поможет отделить подтверждённые факты от преувеличений.

29 октября 2026 года в маркетплейсе расширений Cursor появилось модифицированное злоумышленниками расширение Claude Code. В следующие несколько дней начали распространяться заголовки вроде «Взломаны 5000 разработчиков» и «Массовая утечка API-ключей Claude». На самом деле 5000 — это названная Cursor верхняя граница числа потенциально затронутых пользователей, а не число подтверждённых успешных взломов.

Это не попытка преуменьшить риск. Cursor, команда исследователей безопасности Microsoft, Phorion, Expel и другие организации подтвердили, что инцидент произошёл, а на устройствах клиентов уже обнаружена вредоносная активность. В статье мы рассмотрим шесть этапов — «распространение, запуск, запись, возможность эксплуатации, фактический взлом, потеря данных» — и разберём, какие факты уже подтверждены, а какие данные пока не обнародованы.

Что вы узнаете: после прочтения вы сможете оценить реальные последствия инцидента для себя и своей команды, а также проверить систему и обновить учётные данные в соответствии с официальными рекомендациями.

Главное об атаке через расширение Cursor

Начнём с подтверждённых фактов. Важно понимать границы инцидента: это была атака на цепочку поставок ПО для разработки, а не взлом модели Claude или внутренних систем Anthropic.

Anthropic заявила, что не разрабатывала и не публиковала эти вредоносные сборки, а инцидент не затронул её внутренние системы и компьютеры сотрудников. По состоянию на 2 ноября публичных выводов расследования о том, как злоумышленники получили право публиковать сборки в магазине Cursor, не было.

Хронология атаки через расширение Cursor

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

Изначально также сообщалось об атаке на Open VSX. Позже OpenSourceMalware исправила это утверждение, а Socket, проверив записи реестра Open VSX, не нашла соответствующих вредоносных версий. На данный момент Cursor Marketplace — единственный канал, атака на который подтверждена.

Как работает внедрение вредоносного кода в плагин Cursor: от загрузчика в 66 строк до обратного SSH-туннеля

По данным анализа Phorion и OpenSourceMalware, злоумышленники вставили около 66 строк вредоносного JavaScript-загрузчика в начало файла extension.js легитимного расширения — перед обычным кодом. Загрузчик срабатывал сразу при загрузке модуля расширения: пользователю не нужно было отправлять сообщение Claude или разрешать выполнение задач по программированию. Интерфейс и функции Claude Code продолжали работать как обычно, а часть ошибок обрабатывалась без уведомлений, поэтому заметить атаку было сложно.

Цепочку атаки можно свести к шести шагам:

1. Сбор информации об устройстве: имя хоста, имя пользователя, операционная система и архитектура процессора, домашний и рабочий каталоги, глобальный адрес электронной почты Git, публичный IP-адрес и другие данные.
2. Добавление авторизованного SSH-ключа: в файл authorized_keys пользователя записывался публичный ключ злоумышленника с меткой svc-telemetry.
3. Попытка запустить SSH-сервис: если на устройстве был открыт доступ по SSH, злоумышленник мог войти с помощью добавленного ключа.
4. Создание обратного SSH-туннеля: устройство жертвы само подключалось к серверу злоумышленника по TCP-порту 22, после чего соединение перенаправлялось на локальный SSH-сервис. Это позволяло обойти часть ограничений на входящие подключения.
5. Закрепление в системе: в macOS и Windows настраивалось автоматическое переподключение после входа в систему, а в Linux использовался crontab @reboot. Благодаря этому бэкдор мог работать независимо от расширения. При сбое подключения повторная попытка выполнялась примерно каждые 60 секунд.
6. Передача статуса выполнения: информация об устройстве и результаты каждого этапа отправлялись на сервер через HTTP-маяк по TCP-порту 8099.

Почему подмена плагина Cursor — это не инъекция промпта

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

Два изъяна в реализации вредоносного кода

Из-за ошибок в коде атака оказалась менее опасной, чем могла бы быть. В macOS вредоносная программа проверяла статус Remote Login без прав администратора. В результате система возвращала ошибку доступа, а не ответ «выключено». Программа же пыталась включить SSH, только если явно получала ответ «выключено». Поэтому на многих Mac, где SSH изначально не был включён, этот шаг не срабатывал. В Windows при установке OpenSSH Server программа по ошибке вызывала /bin/sh — путь в стиле Unix, которого нет в стандартной среде Windows.

Однако ошибки не означают, что атака не сработала. Вредоносный код по-прежнему мог записывать публичный ключ, создавать скрипты для закрепления в системе, устанавливать сетевые соединения и отправлять сведения об устройстве. Устройства, на которых SSH уже был включён, подвергались гораздо большему риску. Сооснователь Phorion Калум Холл в интервью WIRED также отметил, что при правильной реализации это могло бы стать очень опасной точкой входа для атаки.

Взломали ли 5000 разработчиков: шесть уровней последствий атаки на расширение Cursor

Цифра «5000» взята из первого объявления Cursor от 29 октября: «At most 5,000 users were affected», то есть пострадали не более 5000 пользователей. Это верхняя граница, названная самой компанией, а не число взломов, независимо подтверждённое экспертами по безопасности. В первом объявлении упоминалась только версия 2.1.313, затем к ней добавили 2.1.312. При этом Cursor не раскрыл, сколько пользователей пришлось на каждую версию, и не опубликовал полный пересмотренный подсчёт.

Если разделить последствия на шесть уровней, станет понятнее, что уже подтверждено, а что остаётся предположением:

Разница между левой и правой частью диаграммы показывает, насколько заголовки могут расходиться с доказательствами. Чем ниже уровень воронки, тем меньше публичных данных. На данный момент нет подтверждений ни тому, что «5000 компьютеров были полностью взяты под контроль», ни тому, что «у 5000 человек украли API-ключи».

Что показывают четыре реальных случая Expel

29–30 октября Expel разбирала четыре связанных инцидента у четырёх клиентов. В каждом случае была затронута одна машина Mac: на трёх использовался CrowdStrike Falcon, на одной — Microsoft Defender for Endpoint. Во всех четырёх случаях были зафиксированы сетевые соединения с IP-адресом сервера злоумышленника. Это значит, что дело уже вышло за рамки лабораторного анализа кода.

Особого внимания заслуживает случай с отложенным запуском. 30 октября в 12:44 по пекинскому времени пользователь вошёл в систему Mac и запустил Cursor. Через минуту началась вредоносная активность, а в 22:29 соединения с IP-адресом злоумышленника всё ещё продолжались — почти 10 часов спустя. К этому моменту вредоносный пакет уже давно удалили из маркетплейса. Наиболее вероятное объяснение: пакет успели скачать, пока он был доступен, а сработал он только после того, как пользователь снова открыл Cursor.

У этих данных есть чёткие ограничения. Четыре случая не означают, что во всём мире заразились только четыре устройства. Нельзя разделить 4 на 5000 и получить долю заражений. А обнаружение SSH-туннеля ещё не значит, что злоумышленник успешно вошёл в систему. Phorion тоже обнаружила образцы на клиентских Mac, но неизвестно, пересекаются ли эти случаи с инцидентами Expel, поэтому просто складывать их нельзя. Кроме того, Expel обнаружила на одной машине процесс вредоносного туннеля, но не нашла маркер открытого ключа svc-telemetry. Это показывает, что при поиске по одному маркеру легко пропустить заражение.

Риски для API-ключей при внедрении вредоносного кода в плагин Cursor

Вредоносный код отбирал до 40 переменных окружения, в названиях которых встречались KEY, TOKEN, SECRET, PASS, AWS или GCP. Например, если на компьютере была задана переменная OPENAI_API_KEY, атакующий мог узнать, что на нём используется соответствующий сервис. Однако исследователи подтвердили, что при первоначальной отправке передавались только названия переменных, а не их значения.

Поэтому точнее сказать так: атакующий код способен определить категории конфиденциальных настроек. Если бэкдор действительно использовали, атакующий мог получить доступ к локальным учётным данным и исходному коду. Но публичных данных о том, сколько API-ключей было украдено на самом деле, пока нет. Утверждение «украдены API-ключи всех пользователей» приравнивает возможности атаки к её результатам. Впрочем, именно из-за неопределённости стоит превентивно сменить учётные данные.

Последствия внедрения вредоносного кода в плагин Cursor

Для разработчиков

• Удалить плагин недостаточно: разработчик официально предупредил, что удаление или обновление до версии 2.1.314 не обязательно устранит уже добавленные публичные SSH-ключи, записи автозапуска и фоновые скрипты.
• Угроза сохраняется и после удаления из магазина: случай с отсроченным срабатыванием, описанный Expel, показывает, что пользователям, открывшим Cursor уже после удаления плагина из магазина, тоже стоит проверить свои устройства.
• Компьютеры с постоянно включённым SSH подвержены большему риску: разработчики часто оставляют Remote Login включённым для удалённой отладки, что позволяет вредоносному коду обойти собственный недочёт в реализации.
• Атакующие могли выяснить, какие учётные данные доступны: даже если использовать бэкдор не удалось, атакующие могли узнать, какими облачными сервисами и API вы пользуетесь.

Для команд и отрасли

• Распространение плагинов становится новым вектором атаки: версии одного и того же расширения в разных магазинах могут поступать из разных источников. При проверке нужно учитывать источник установки и хеш файла, а не только номер версии.
• Права, которые инструменты для программирования с ИИ получают на устройствах, нужно пересмотреть: плагины IDE обычно запускаются с правами пользователя, могут читать и изменять файлы в домашнем каталоге и устанавливать сетевые соединения. Компаниям стоит включить их в систему контроля конечных устройств.
• При реагировании на инцидент нужно учитывать весь жизненный цикл учётных данных: следует оценить риски для репозиториев, API-ключей, облачных учётных данных и токенов сеансов, к которым имели доступ затронутые устройства. Чем больше разных ключей используется в проектах, тем дороже их смена.

Как проверить Cursor на вредоносный плагин и заменить скомпрометированные учётные данные

Прежде всего рекомендуем использовать скрипты проверки и устранения угрозы для macOS и Windows из официального объявления Cursor. Приведённые ниже индикаторы и команды помогут разобраться в ситуации и провести дополнительную проверку, но не заменят официальные скрипты и анализ журналов.

Шаг 1. Быстрая проверка устройства на примере macOS

# 1. 检查授权公钥中是否有攻击者标记（注意：没找到不代表安全，可能漏报）
grep -n "svc-telemetry" ~/.ssh/authorized_keys

# 2. 检查持久化文件与启动项
ls -la ~/.config/.smt ~/.config/.smtk ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

# 3. 检查是否存在与恶意服务器的连接
lsof -nP -i | grep "134.209.82.225"

# 4. 确认 Remote Login 状态（需要管理员权限）
sudo systemsetup -getremotelogin

Пользователи Windows могут проверить запланированное задание командой schtasks /query /tn SysMon, а затем поискать sysmon.cmd в папке автозагрузки. Если обнаружен хотя бы один признак, сохраните свидетельства, изолируйте устройство и выполните очистку с помощью официального скрипта. Если восстановить доверенное состояние устройства не удаётся, стоит переустановить систему и заменить учётные данные на другом доверенном устройстве.

Шаг 2: составьте список переменных с учётными данными, которые могли утечь

Скрипт ниже отбирает переменные окружения по тем же ключевым словам, что и вредоносный код. Он выводит только названия, но не значения — это поможет составить список данных, которые нужно заменить. После замены выполните простой вызов API, чтобы убедиться, что новый ключ работает:

import os, re, openai

# 与恶意代码相同的关键词，列出可能被“摸底”的变量名
pattern = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")
print([k for k in os.environ if pattern.search(k.upper())])

# 在可信设备上轮换后，用新 Key 验证调用
client = openai.OpenAI(
    api_key=os.environ["NEW_API_KEY"],
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI 兼容接口
)
r = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "ping"}]
)
print(r.choices[0].message.content)

import os
import re
import openai
from typing import List

KEYWORDS = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")

def list_sensitive_env_names(limit: int = 40) -> List[str]:
    """只返回疑似凭证的环境变量名称，绝不输出值。
    limit 与恶意代码的筛选上限保持一致，用于还原攻击者可能看到的视图。"""
    names = [k for k in os.environ if KEYWORDS.search(k.upper())]
    return sorted(names)[:limit]

def verify_new_key(model: str = "gpt-4o-mini") -> bool:
    """轮换后验证新 Key 是否可正常调用"""
    client = openai.OpenAI(
        api_key=os.environ.get("NEW_API_KEY", ""),
        base_url="https://api.apiyi.com/v1"
    )
    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": "ping"}],
            max_tokens=10
        )
        return bool(resp.choices[0].message.content)
    except Exception as e:
        print(f"验证失败: {e}")
        return False

if __name__ == "__main__":
    print("可能暴露给攻击者的变量名：")
    for name in list_sensitive_env_names():
        print("  -", name)
    print("新 Key 验证结果：", verify_new_key())

Шаг 3: Ротируйте учётные данные по приоритету

🎯 Технический совет: Если проект напрямую подключён к нескольким платформам, например OpenAI, Claude и Gemini, после инцидента придётся зайти в каждую консоль, чтобы отозвать и создать ключи заново. Рекомендуется объединить вызовы моделей через APIYI apiyi.com: один ключ даёт доступ к основным моделям разных поставщиков, а интерфейс совместим с OpenAI. При ротации достаточно изменить настройки в одном месте. Это также упрощает контроль использования и поиск аномальных расходов.

Частые вопросы FAQ

Главное об атаке через расширение Cursor

• Суть инцидента: через маркетплейс Cursor распространялось подменённое расширение. Это атака на цепочку поставок, а не уязвимость модели Claude
• Что означает 5000: это официальная оценка максимального числа потенциально затронутых пользователей, а не подтверждённое число взломов
• Что подтверждено: независимая организация наблюдала вредоносную активность и исходящие соединения на реальном Mac
• Что не раскрыто: число успешных удалённых входов, количество украденных ключей и размер финансового ущерба
• Главный риск: вредоносный код может сработать и после удаления расширения из маркетплейса. Само удаление расширения не гарантирует устранения бэкдора
• Что делать: запустить официальный скрипт, сменить учётные данные с доверенного устройства и сократить количество ключей с помощью APIYI apiyi.com

Итоги

Главное об атаке через расширение Cursor:

1. Отделяйте заголовки от доказательств: между «затронуто до 5000 человек» и «взломано 5000 человек» — большая разница. Пока публичные доказательства подтверждают лишь реальные случаи выполнения вредоносного кода.
2. Атака была реальной, но её эффективность ограничена: вредоносный код мог создавать бэкдор и закрепляться в системе, однако ошибки реализации для macOS и Windows снизили вероятность успешного удалённого входа.
3. Одной проверки недостаточно: нужно изучить источник установки, хеши файлов, процессы, сетевые соединения и элементы автозагрузки. Если искать только svc-telemetry, можно пропустить признаки заражения.

Если вы пользовались расширением Claude Code из маркетплейса Cursor с 29 по 30 октября, сначала проверьте систему по официальной инструкции, а затем смените учётные данные в порядке приоритета. Что касается API моделей, можно воспользоваться случаем и собрать разрозненные ключи в APIYI apiyi.com — в следующий раз экстренная смена ключей займёт гораздо меньше времени.

📚 Источники

1. Официальное уведомление Cursor о безопасности: время инцидента, версии, хеши вредоносных файлов и скрипты очистки
2. Ссылка: cursor.com/blog/claude-code-extension-security-notice

3. Описание: начните проверку с этого уведомления — в нём есть скрипты исправления для macOS и Windows

4. Microsoft Security Research: анализ цепочки атаки вредоносного расширения Claude Code

5. Ссылка: microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/

6. Описание: подробности о границах цепочки поставок, механизме SSH и способах закрепления в системе

7. Phorion: Official Claude Code Extension Compromise

8. Ссылка: phorion.io/blog/offical-claude-code-vsx-compromise/

9. Описание: технические детали загрузчика из 66 строк, различия между платформами и ошибки в коде

10. Expel: Fake Claude Code extensions in Cursor

11. Ссылка: expel.com/blog/blog-fake-claude-code-extension-cursor-ssh-backdoor/

12. Описание: четыре реальных инцидента у клиентов и примеры отложенного выполнения кода

13. Socket: Cursor Removes Malicious Claude Code Extension

14. Ссылка: socket.dev/blog/claude-code-extension-compromise
15. Описание: проверка записей Open VSX и npm и исправление ошибочных ранних сообщений

Автор: техническая команда APIYI
Технические вопросы: свяжитесь с нами через главную страницу APIYI apiyi.com. Дополнительные материалы по интеграции доступны в документации на docs.apiyi.com

Читайте также

• Расширение Claude Code скомпрометировано: бэкдор в версии 2.1.313, 5 шагов для проверки и удаления: 29 октября Claude Code 2.1.312 и 2.1.313 в Cursor Marketplace подменили сборками с SSH-бэкдором, подвергнув риску до 5000 пользователей; статья за 5 шагов поможет проверить открытый ключ svc-telemetry, удалить LaunchAgent и задачи планировщика, обновиться до 2.1.314+ и сменить данные GitHub, облака и ключ APIYI.
• Claude Max переименовали в Ultra: отменили ли 5-часовой лимит? Разбираем 3 изменения: Claude Max 20x переименован в Ultra, Max 5x — в Max, цены не изменились; для подтверждённых аккаунтов Ultra отменён 5-часовой лимит, недельный лимит сохранён; сравнительная таблица, самопроверка в 3 шага и расчёты помогут решить, стоит ли менять тариф.