Prompt-injection через скиллы Claude Code: как проверить плагин перед установкой

Разработчик на Habr в июле 2026 года опубликовал практическое руководство по безопасности OSS-скиллов для AI-инструментов — и объяснил, почему вредоносный скилл опаснее стандартного prompt-injection: он запускается с правами пользователя без какой-либо изоляции.

Почему скилл — это не просто промпт?

Популярное заблуждение: скилл для Claude Code или похожего AI-инструмента — это текстовый конфиг, безопасный по определению. Открыл SKILL.md, прочитал инструкцию — и уверен, что всё под контролем.

На практике граница между «конфигом» и «исполняемым кодом» давно размыта. Современные скиллы включают:

• Python- или Bash-скрипты, выполняемые через tool_call
• Инструкции для работы с локальной файловой системой и переменными окружения
• Вызовы внешних API и webhook-эндпоинтов
• Многошаговые агентные пайплайны с расширенными правами доступа

Всё это работает с правами текущего пользователя — без sandbox-изоляции по умолчанию. Вредоносный скилл получает доступ к файлам, API-токенам, SSH-ключам и истории чатов: не к чему-то абстрактному, а к тому, что лежит на диске прямо сейчас.

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

Как злоумышленник использует скилл как вектор атаки

Классический prompt-injection: вредоносные инструкции прячутся в данных, которые обрабатывает модель — в тексте веб-страницы, документа, письма. Агент «читает» контент и выполняет скрытые команды. В случае со скиллами, содержащими исполняемый код, атака устроена иначе и сложнее в обнаружении.

Типичная цепочка атаки через OSS-скилл:

• Атакующий публикует скилл с реально полезной функцией — редактор, конвертер, поисковик
• Первые коммиты чистые, скилл набирает звёзды и устанавливается пользователями
• Через несколько обновлений добавляется вредоносная логика — сбор .env-файлов, токенов API, истории чатов
• Пользователь обновляет скилл без проверки diff — данные уходят на внешний сервер

«Скилл — это не конфиг и не просто промпт в SKILL.md.

Это буквально может быть исполняемым кодом с твоими правами»

В отличие от уязвимости в npm-пакете, которую ловит npm audit, вредоносный скилл не оставляет CVE-записи — его никто не сканирует автоматически.

Что проверять перед установкой скилла

Минимальный чеклист перед добавлением чужого скилла:

• Читай весь код, не только SKILL.md — Python, Bash, PowerShell в директории скилла требуют ручного просмотра
• Ищи внешние запросы — curl, fetch, requests.get к незнакомым URL без явной необходимости — красный флаг
• Проверяй доступ к чувствительным путям — ~/.ssh/, ~/.env, .credentials без явного разрешения пользователя недопустимы
• Изучай историю коммитов — вредоносный код часто появляется через несколько недель после чистого релиза
• Ищи обфускацию — base64-строки, динамический eval(), нестандартные имена переменных
• Аудируй зависимости — вредоносная логика может быть во вспомогательной библиотеке, а не в самом SKILL.md

Незнакомые скиллы стоит тестировать в изолированном окружении: отдельный профиль без реальных API-ключей, без доступа к рабочим файлам. Оптимальный вариант — выделенный тестовый аккаунт без продакшен-токенов.

Что это значит

OSS-экосистема скиллов для AI-ассистентов повторяет путь npm десятилетней давности: быстрый рост, слабая централизованная верификация, привычка устанавливать без аудита. Разница принципиальная: скилл работает не в изолированном Node-окружении, а напрямую в рабочей среде пользователя с его правами. Аудит скиллов перед установкой — не параноя, а та же гигиена безопасности, что npm audit перед деплоем.