В открытых источниках в июне 2026 года появилась информация об инциденте, связанном с репозиторием Arch User Repository (AUR). Сообщалось, что более 1900 пакетов могли быть затронуты изменениями, потенциально ведущими к компрометации учётных данных разработчиков. Подобные атаки на цепочку поставок становятся всё более распространёнными, и их последствия для бизнеса могут быть значительными — от утечки токенов до несанкционированного доступа к CI/CD. В данном материале рассматриваются公开ные данные об инциденте, типовые техники злоумышленников и меры, которые позволяют снизить риски для организаций в России с учётом требований 152-ФЗ и нормативных актов ФСТЭК.
Что известно об инциденте
Согласно сообщениям сообщества Arch Linux и аналитических компаний (в частности, Sonatype), в конце мая — начале июня 2026 года был выявлен факт модификации значительного числа пакетов в AUR. По оценкам, количество изменённых рецептов сборки (PKGBUILD) достигало почти двух тысяч. В публичных отчётах указывалось, что злоумышленники могли получить контроль над пакетами, которые длительное время не обновлялись, и добавить в них вредоносные сценарии.
Один из описанных кейсов (данные из открытых источников) касается разработчика, использовавшего пакет alvr. После установки через AUR через некоторое время были зафиксированы попытки передачи SSH-ключей во внешнюю сеть. Благодаря системам мониторинга инцидент удалось своевременно обнаружить. Такие ситуации — не единичны, и компании сталкиваются с подобными рисками регулярно.
Важно отметить, что уязвимость связана не с самим Arch Linux, а с моделью доверия в AUR. Любой желающий может взять на сопровождение заброшенный пакет при отсутствии активности предыдущего мейнтейнера. Этим, по данным исследователей, и воспользовались атакующие: они находили давно не обновляемые проекты, становились их сопровождающими и незаметно встраивали в PKGBUILD или .install-файлы дополнительные команды.
Среди пакетов, упоминавшихся в публикациях, — premake-git (популярный среди разработчиков игр), alvr, libwebsockets-org, polybar-git и многие другие. Вредоносный код, по анализу экспертов, был нацелен на извлечение данных из браузеров на Chromium, токенов мессенджеров (Slack, Discord), SSH-ключей и файлов конфигурации (.npmrc, .dockercfg и т.п.). Собранная информация, как сообщалось, отправлялась на скрытые серверы (в том числе через Tor).
Техники, которые могли использоваться
На основе публичных разборов (в том числе отчётов сообщества Arch и исследователей безопасности) можно выделить типовую схему:
- Разведка — автоматический поиск пакетов, не обновлявшихся более 6–12 месяцев, с пометкой «брошенный» или с давно неактивным сопровождающим.
- Захват — через веб-интерфейс AUR злоумышленник берёт пакет на сопровождение. Модерация минимальна, если нет жалоб.
- Внедрение — в PKGBUILD или .install-скрипты добавляются вызовы, загружающие вредоносный код (например, через замаскированные зависимости npm или прямые команды). В некоторых случаях использовался скомпрометированный npm-пакет atomic-lockfile версии 1.4.2, в preinstall-скрипте которого находился исполняемый файл.
- Маскировка — вредоносные команды соседствуют с большим количеством легитимных зависимостей (python, git, base-devel), что затрудняет визуальное обнаружение.
В ряде публикаций также упоминалось использование eBPF-программ для сокрытия активности после получения привилегий root. Однако, по имеющимся данным, такая техника применялась лишь в целевых сценариях и не являлась массовой. В большинстве случаев вредоносный код ограничивался кражей данных из профиля пользователя — этого достаточно для компрометации доступа к репозиториям и системам CI/CD.
Вторая волна (конец июня) по информации из открытых источников была связана с использованием JavaScript-рантайма Bun и скомпрометированного npm-пакета js-digest. Это указывает на то, что атака могла быть частью хорошо спланированной кампании, однако официальных attributions пока не опубликовано.
Рекомендации по защите от атак на цепочку поставок
На основе анализа подобных инцидентов можно сформулировать набор мер, которые помогают существенно снизить риски для организаций.
- Контроль PKGBUILD перед сборкой
Принято за правило просматривать содержимое PKGBUILD (хотя бы поверхностно) на предмет подозрительных конструкций: вызовов curl, wget, установки пакетов из незнакомых источников. Даже беглый осмотр позволяет выявить грубые аномалии. - Проверка истории пакета в AUR
Инструменты вроде aur log показывают, когда и кем менялись файлы. Резкая смена сопровождающего после длительного простоя — повод для дополнительной проверки. - Использование локальных репозиториев с верификацией
Системы управления пакетами с поддержкой контрольных сумм (например, aurutils) позволяют сравнивать PKGBUILD с доверенным источником. Это не абсолютная защита, но повышает порог для атакующего. - Запрет на сборку AUR-пакетов в CI/CD и на серверах
Лучшая практика — использовать AUR только на изолированных рабочих станциях разработчиков. В контейнерах и на продакшен-серверах зависимости должны быть заморожены и проверены. - Анализ состава ПО (SBOM + SCA)
Инструменты вроде Dependency-Track, Snyk или OWASP Dependency-Check способны детектировать пакеты с низкой репутацией или известными вредоносными паттернами. Однако нулевые уязвимости могут оставаться незамеченными. - Мониторинг исходящего трафика
На рабочих станциях полезно отслеживать попытки соединения с аномальными адресами (в том числе с .onion-доменами). При обнаружении таких попыток следует незамедлительно реагировать. - Обязательная двухфакторная аутентификация
Для GitHub, GitLab, npm, Docker Hub и других критических сервисов. Даже при краже токена второй фактор предотвращает его использование (за исключением случаев хардкода токенов). - Регулярная ротация SSH-ключей и токенов
Рекомендуемый интервал — раз в 90 дней. Особенно после крупных инцидентов в публичных репозиториях. - Обучение разработчиков
Краткий практикум по выявлению признаков вредоносных PKGBUILD значительно снижает вероятность человеческой ошибки. По данным некоторых компаний, после таких воркшопов количество инцидентов сокращается более чем на 60%. - Использование защищённых корпоративных репозиториев
Внутреннее кэширование AUR-пакетов с последующим сканированием антивирусными средствами и проверкой подписей — обязательная мера для крупных организаций.
Что делать при подозрении на компрометацию
Если возникли основания полагать, что система могла быть заражена (например, обнаружены аномальные сетевые соединения или подозрительные файлы), рекомендуется следующий порядок действий:
- Изоляция — отключить компьютер от сети, заблокировать исходящий трафик на межсетевом экране.
- Сбор артефактов — скопировать подозрительные файлы, логи установки пакетов, список процессов и сетевых соединений без удаления.
- Поиск индикаторов — использовать известные из открытых источников сигнатуры (например, SHA-256 вредоносных файлов) для проверки системы.
- Ротация секретов — с чистой системы (LiveUSB) сменить все SSH-ключи, пароли, токены доступа к репозиториям, облачным провайдерам и браузерные сессии.
- Переустановка системы — при подтверждении заражения это наиболее надёжный способ удалить возможные закладки (автозагрузка, изменённые конфиги).
- Уведомление регуляторов — если затронуты персональные данные или объекты КИИ, следует уведомить Роскомнадзор и ФСТЭК в порядке, предусмотренном 152-ФЗ и 187-ФЗ.
Обратите внимание: сокрытие инцидента, связанного с утечкой данных или компрометацией ключей на объектах КИИ, может повлечь административную ответственность.
Анализ рисков для российских компаний
AUR остаётся одновременно и мощным инструментом, и источником рисков. В российских организациях, как показывает практика, часто отсутствует формальная политика использования AUR. Разработчики получают разрешение на установку пакетов без проверки. С учётом роста числа атак на цепочки поставок в 2026 году такой подход становится недопустимым.
Для снижения рисков рекомендуется на корпоративном уровне:
- Утвердить политику, согласно которой AUR-пакеты используются только после проверки специалистом по безопасности.
- Развернуть внутренний репозиторий верифицированных пакетов (с помощью repoctl или аналогичных инструментов).
- Настроить автоматическую проверку каждого нового PKGBUILD в CI — поиск опасных команд, проверка GPG-подписей, сверка с известными IOC.
Для объектов критической информационной инфраструктуры также важно соблюдать требования по документированию цепочки поставок ПО (в соответствии с 187-ФЗ и приказом ФСТЭК № 239).
Часто задаваемые вопросы
- Насколько распространены атаки на AUR?
Крупные инциденты случались и ранее (например, в 2018 году с майнером в PDF-вьювере). Однако текущий инцидент, по данным открытых источников, является самым массовым в истории AUR. - Могут ли пострадать обычные пользователи, не разработчики?
Да, если они устанавливают из AUR любые программы (игры, утилиты) и используют помощников типа yay с флагом --noconfirm. - Как проверить, заражена ли система?
Наиболее надёжный способ — сравнить текущий список установленных из AUR пакетов с резервной копией до предполагаемой даты инцидента. Также можно проверить наличие аномальных файлов во временных директориях. - Затронуты ли дистрибутивы на основе Arch (Manjaro, EndeavourOS)?
Да, они используют тот же AUR, поэтому пользователи этих систем также подвержены риску. - Может ли стилер получить root-доступ?
Сам по себе вредоносный код, описанный в открытых источниках, не содержал эксплойтов для повышения привилегий. Однако в случае наличия на системе не закрытых уязвимостей (Polkit, sudo) теоретически возможна эскалация. - Какие меры рекомендует ФСТЭК?
Официальных бюллетеней по данному инциденту пока нет. Однако эксперты рекомендуют рассматривать Arch с AUR как систему с повышенным риском и применять меры из приказа № 239 (защита цепочки поставок ПО). - Я использую Flatpak или Snap — насколько я защищён?
Эти системы имеют лучшую изоляцию (песочницу), но не гарантируют полной защиты от кражи данных из домашней директории. Расслабляться не стоит.
Если вы хотите оценить уровень защищённости вашей инфраструктуры от атак на цепочки поставок, можно провести аудит с привлечением профильных специалистов. Компании сталкиваются с этими рисками регулярно, и своевременная диагностика позволяет предотвратить серьёзные инциденты.
Мы рекомендуем провести внутреннюю проверку политик использования внешних репозиториев, а также организовать обучение разработчиков. При необходимости вы можете обратиться за консультацией по настройке систем мониторинга и реагирования.
Итог
Инцидент с пакетами в Arch User Repository, по данным открытых источников, затронул почти две тысячи рецептов сборки. Это не единичный сбой, а системная проблема модели доверия в сообщественных репозиториях. Однако паниковать не стоит — достаточно внедрить ряд привычек и организационных мер: просмотр PKGBUILD, отслеживание смены сопровождающих, двухфакторная аутентификация, запрет на сборку из AUR в критических средах. Безопасность — это непрерывный процесс, и сегодняшние проверки могут предотвратить завтрашние утечки. Для российских компаний также важно учитывать требования законодательства об инцидентах с персональными данными и КИИ.
Если вам важно понять реальный уровень защищённости вашей инфраструктуры от подобных угроз, можно провести аудит цепочки поставок ПО и систем мониторинга.
⚖️ Данный материал носит информационно-аналитический характер. Все выводы основаны на открытых источниках и не являются утверждением фактов, не подтверждённых официально. Материал не является юридической или технической рекомендацией. Любые решения принимаются читателем самостоятельно.
══════
Оставьте заявку на бесплатную консультацию: [Перейти на сайт]