JetBrains закрыла в IntelliJ IDEA уязвимость, которая позволяет запустить произвольный код на компьютере разработчика. Ошибка кроется в подсистеме Structural Search, а срабатывает она при открытии недоверенного проекта. Сведения о проблеме опубликованы под идентификатором CVE-2026-100256, степень опасности - High. Исправление вошло в версию 2026.2.3.
Уязвимость CVE-2026-100256
Structural Search (поиск по структуре кода) помогает находить фрагменты, похожие по строению, а не по точному тексту. Разработчик описывает шаблон, и среда прогоняет его по всему проекту. Скрипты расширяют этот механизм: они умеют проверять условия, подставлять значения и менять найденные совпадения. По сути, это код, который исполняется внутри среды. Поэтому в недоверенных проектах для таких скриптов действуют ограничения. Среда должна спросить у пользователя разрешение или заблокировать запуск. Настройки и шаблоны часто переходят вместе с проектом, и пользователь редко их просматривает.
Обойти эти ограничения и оказалось возможно. Классификация CWE-829 описывает такой случай как включение функциональности из недоверенной сферы управления. Проще говоря, барьер, рассчитанный на безопасный проект, не сработал. Скрипт из чужого репозитория получил право на исполнение. Злоумышленнику достаточно подготовить проект с нужным шаблоном поиска. Как только разработчик клонирует репозиторий и откроет его в среде, код запустится без явного согласия. Никаких дополнительных действий от жертвы не требуется. Успех зависит только от доверчивости человека и содержимого репозитория.
Механизм доверия к проекту появился не случайно. Программисты ежедневно открывают десятки репозиториев. Среди них чужой код, примеры с форумов, тестовые сборки и форки. Режим недоверенного проекта как раз ограничивает опасные возможности в незнакомом коде. Он отключает автоматический запуск сборки, исполнение скриптов и другие рискованные операции. Если проверка обходится, последний барьер между злоумышленником и рабочей машиной исчезает.
Последствия зависят от того, к чему у среды есть доступ. Среду разработки нельзя назвать изолированной песочницей. Через неё проходят исходный код компании, ключи доступа, токены к репозиториям и учётные данные к облачным сервисам. Получив исполнение кода на такой машине, атакующий заберёт эти секреты. Дальше открывается путь к сборочным конвейерам, внутренним сервисам и инфраструктуре. Оценка риска для одного программиста и для крупной компании сильно различается. Во втором случае потери растут многократно, ведь одна скомпрометированная машина тянет за собой цепочку поставок.
Здесь и кроется главная причина внимания к таким уязвимостям. Инструменты разработки стоят в самом начале пути создания продукта. Через них проходит код, который потом попадёт к заказчикам. Компрометация среды разработки позволяет незаметно править исходники. Атакующий может добавить вредоносную строку в чужой проект и дождаться, пока её выложат в релиз. Для этого ему не нужны права администратора в инфраструктуре. Достаточно, чтобы разработчик открыл подготовленный репозиторий.
Технически вредоносный проект выглядит обычным. В нём нет файлов сборки, которые сразу бросаются в глаза. Шаблон поиска прячется в настройках среды, а не в отдельном запускаемом файле. Жертва вряд ли увидит предупреждение до срабатывания. Под удар попадают разные категории специалистов. Фрилансеры, участники открытых проектов, сотрудники подрядчиков и штатные разработчики. У каждого свой набор доступов к рабочим системам. У кого-то это личный ноутбук, у кого-то корпоративная машина с выходом во внутреннюю сеть. Потому одна уязвимость бьёт по людям с разной ценой ошибки.
Массовость усугубляет картину. Открытый исходный код приучил программистов запускать чужие проекты без долгих раздумий. Ссылки на интересные репозитории приходят в мессенджерах, в трекерах задач и в письмах. Проверить каждую из них досконально удаётся редко. Уязвимости такого рода в инструментах разработки уже встречались. Похожие проблемы находили в расширениях редакторов и в плагинах. Каждый раз схема повторяется: пользователь доверяет привычному инструменту, а инструмент доверяет чужому коду.
JetBrains выпустила исправление в версии 2026.2.3. Всем, кто работает на более ранних сборках ветки 2026.2, нужно обновиться. Заодно проверьте настройки доверия к проектам. Чужой репозиторий разумно открывать после просмотра его содержимого. Сторонние шаблоны поиска и плагины тоже заслуживают внимания. Если среда разрешает исполнение скриптов в незнакомом проекте, ограничьте эту возможность вручную. Когда обновление невозможно прямо сейчас, отключите выполнение скриптов поиска в настройках.
Свидетельств об эксплуатации в реальных атаках вендор не приводит. Уязвимость обнаружил исследователь под ником n0_be3r. Внутренний номер задачи - IJPL-253651. Публичный идентификатор CVE уже присвоен, поэтому со временем детали разойдутся по базам. Чем дольше пользователи тянут с обновлением, тем выше шанс появления рабочего эксплойта, то есть вредоносного кода, который использует уязвимость. Окно для спокойного обновления пока открыто.
Для команд есть отдельный повод пересмотреть практики. Разработчикам стоит работать с чужими проектами на изолированных стендах или в контейнерах. Учётные данные, которые лежат рядом с кодом, лучше держать с минимальными правами. После открытия подозрительного репозитория не помешает сменить токены и пароли. Управление исправлениями в такой ситуации проверяет себя на прочность. Регулярное обновление сред - часть базовой гигиены, а не разовая акция.
Инструменты разработки давно стали частью поверхности атаки. Через них проходят секреты, доступы и сборочные процессы. Одна обойдённая проверка в таком месте стоит дорого. Обновление до 2026.2.3 закрывает конкретный путь для атакующего. Дисциплина при работе с чужим кодом снижает остальные риски.
Ссылки
