Команда Arch Linux временно остановила отправку любых изменений в пользовательский репозиторий AUR. Решение принято после новой волны вредоносных захватов осиротевших пакетов.
Сначала, 30 июля 2026 года, разработчики отключили возможность принимать такие пакеты на сопровождение. Этой меры оказалось недостаточно: 1 августа команда Arch Linux полностью заблокировала отправку коммитов в AUR. Сопровождающие временно не могут публиковать новые пакеты и обновлять уже существующие.
Чтение репозитория при этом не остановлено. Пользователи по-прежнему могут открывать страницы пакетов и получать опубликованные ранее сценарии сборки. Ограничение касается записи новых изменений.
Инцидент стал продолжением атаки, обнаруженной ещё в июне. Злоумышленники регистрировали учётные записи, принимали на сопровождение оставшиеся без владельцев пакеты и добавляли в них команды для загрузки вредоносных зависимостей из экосистемы JavaScript.
На момент проверки 2 августа Arch Linux не назвал срок восстановления отправки изменений.
AUR, или Arch User Repository, представляет собой пользовательское хранилище описаний пакетов. В нём находятся не готовые программы, а файлы PKGBUILD, установочные сценарии и другие инструкции, необходимые для получения исходного кода, сборки и создания пакета.
30 июля участник команды Arch Linux Robin Candau сообщил в официальной рассылке, что принятие пакетов на сопровождение временно отключено из-за потока вредоносных операций и последующих коммитов.
Уже 1 августа он дополнил сообщение: команда отключила все отправки изменений. Это означает, что даже законные сопровождающие временно не могут загружать новые версии своих пакетов.
Сам AUR не был удалён или полностью выключен. Уже опубликованные сценарии остаются доступными для просмотра и сборки, если служба отвечает на запросы.
Первые массовые сообщения о подозрительных захватах появились 11 июня. Владельцы и бывшие сопровождающие пакетов начали получать уведомления о том, что проекты без активного владельца были приняты на сопровождение недавно созданными аккаунтами.
Новые сопровождающие добавляли в файлы пакетов послеустановочные команды, которые запускали npm или Bun и загружали посторонние JavaScript-зависимости.
12 июня Arch Linux официально предупредил о большом количестве вредоносных захватов и обновлений в AUR. Команда начала искать опасные коммиты, блокировать связанные аккаунты и препятствовать загрузке новых изменений. Пользователей попросили внимательно проверять все изменения в PKGBUILD и установочных сценариях.
15 июня разработчики временно закрыли регистрацию новых аккаунтов. Доступ восстановили 13 июля после усиления защиты.
AUR начал отклонять одноразовые почтовые адреса. Для новых аккаунтов стала обязательной проверка электронной почты, а ссылка подтверждения получила срок действия в 24 часа. Изменение адреса блокируется на период проверки.
Новые меры усложнили массовую регистрацию, но не остановили кампанию окончательно. В конце июля команда снова обнаружила вредоносные принятия пакетов и коммиты, после чего сначала отключила функцию смены сопровождающего, а затем заблокировала все отправки.
Пакет AUR может остаться без сопровождающего, если прежний владелец отказывается от него или перестаёт заниматься обновлениями. Такой проект получает статус осиротевшего.
До введения ограничений зарегистрированный пользователь мог принять осиротевший пакет на сопровождение. После этого он получал возможность отправлять изменения в его Git-репозиторий.
Механизм нужен для нормальной работы AUR. Старые программы не должны навсегда оставаться без обновлений только потому, что прежний сопровождающий ушёл.
Атакующие автоматизировали эту процедуру. Новые аккаунты быстро забирали несколько проектов, после чего публиковали похожие изменения.
Один участник рассылки зафиксировал аккаунт, который принял на сопровождение 16 пакетов за две минуты. В одном из них почти сразу появились зависимость от Bun и новый послеустановочный сценарий.
В отдельных коммитах злоумышленники также подменяли сведения об авторах. Имя прежнего сопровождающего могли сохранить, а адрес электронной почты заменить. Такая запись визуально выглядела привычнее и могла затруднить беглую проверку истории.
Ранние вредоносные изменения запускали npm install и загружали пакет atomic-lockfile вместе с обычными JavaScript-библиотеками.
Например, в одном из захваченных проектов появилась команда установки atomic-lockfile, chalk и minimist. Автор исходной программы подтвердил, что пакет не использовал JavaScript и не нуждался ни в одной из этих зависимостей.
После обнаружения первой схемы злоумышленники начали менять названия и инструменты. В следующих коммитах встречались js-digest и lockfile-js, а вместо npm использовалась среда выполнения Bun.
Один из обнаруженных послеустановочных сценариев содержал команду:
bun add minimist js-digest
Она выполнялась после установки пакета и загружала указанную зависимость из внешнего реестра.
Позже команды начали маскировать. Название Bun разбивали на отдельные строки и управляющие последовательности, чтобы простейший поиск по слову bun не находил подозрительный фрагмент.
Эта техника не превращала код в сложную криптографическую упаковку. Она была рассчитана на обход автоматических проверок по ключевым словам и на пользователя, который лишь бегло просматривает разницу между версиями.
Во время июньской волны один из участников сообщества проверил зеркало истории AUR и нашёл около 900 веток, где за последние часы появилось упоминание js-digest.
Повторный поиск выдал список из 879 пакетов. Число уменьшалось по мере того, как администраторы удаляли вредоносные изменения и принудительно возвращали безопасные версии.
Эти 879 записей нельзя называть официально подтверждённым числом заражённых пакетов. Речь идёт о результате пользовательского поиска по истории Git за ограниченный период.
Число тем более не показывает количество заражённых компьютеров. Опасный коммит мог быть удалён до того, как кто-либо установил или обновил пакет. Один человек мог использовать несколько затронутых проектов, а часть результатов нуждалась в дополнительной проверке.
13 июня представитель Arch Linux сообщил, что команда удалила все известные на тот момент вредоносные коммиты. Участники сообщества продолжили находить дополнительные ветки, после чего список дополнялся.
Окончательную статистику по числу затронутых пакетов, установок и пользователей проект пока не опубликовал.
Наиболее надёжно подтверждённая часть атаки — внедрение команд, загружавших подозрительные JavaScript-пакеты через npm или Bun.
Участники рассылки обнаружили в двоичных данных atomic-lockfile ссылки на каталоги с данными Telegram Desktop и предположили, что нагрузка могла искать пользовательскую информацию. Это предварительный анализ сообщества, а не законченный отчёт Arch Linux.
Официального описания всех функций вредоносной программы пока нет. Также неизвестно, были ли разные названия JavaScript-пакетов вариантами одной нагрузки или несколькими связанными инструментами.
PKGBUILD — это сценарий Bash, содержащий инструкции для получения исходников и сборки пакета. Утилита makepkg выполняет содержащиеся в нём функции и создаёт архив, который затем можно установить через pacman.
Сборка обычно происходит от имени обычного пользователя. Поэтому фраза о том, что любой вредоносный PKGBUILD автоматически выполняет код с повышенными правами, неточна.
При этом пакет может содержать отдельный установочный сценарий .install. Его функции запускаются менеджером пакетов во время установки, обновления или удаления. Именно такой механизм использовали во многих обнаруженных коммитах.
При системной установке pacman обычно работает с правами администратора. Вредоносный послеустановочный сценарий поэтому опаснее обычной команды, выполненной только во время пользовательской сборки.
Риск создаёт не сам формат AUR, а сочетание исполняемых сценариев, смены сопровождающего и привычки устанавливать обновления без внимательного изучения изменений.
Инцидент относится к Arch User Repository. AUR отделён от официальных репозиториев Arch Linux и содержит пользовательские описания сборки для программ, отсутствующих в основном дереве пакетов.
Новый пользователь AUR не может таким способом изменять пакеты из официальных репозиториев core и extra.
Arch Linux не сообщал о компрометации pacman, серверов официальной сборки, подписей сопровождающих или зеркал бинарных пакетов.
Пользователи, которые устанавливали программы только из официальных репозиториев, не подвергались именно этой схеме через принятие AUR-пакетов.
Само появление вредоносного коммита не выполняет его на уже работающих компьютерах. Пользователь должен был скачать новую версию сценариев, собрать пакет и установить или обновить его после внедрения опасных изменений.
Если программа была установлена раньше и в период атаки не пересобиралась, новый послеустановочный сценарий на компьютере не запускался.
Помощники AUR вроде yay и paru не создавали уязвимость. Они автоматизируют получение, сборку и обновление пользовательских пакетов. Опасность возникает, когда человек подтверждает изменения, не просмотрев PKGBUILD, .install и список новых зависимостей.
Arch Linux прямо рекомендует проверять все изменения в этих файлах перед обновлением, особенно во время текущего инцидента.
Возврат безопасного PKGBUILD защищает будущие установки, но не отменяет команды, которые уже успели выполниться на компьютере.
Послеустановочный сценарий способен создать файлы за пределами обычного состава пакета, скачать дополнительные компоненты или изменить настройки системы. Простое удаление исходного AUR-пакета такие изменения не обязательно откатит.
Пользователям, которые обновляли AUR-пакеты с 11 июня, стоит проверить журнал /var/log/pacman.log и определить, какие пользовательские пакеты устанавливались или пересобирались в этот период.
В каталогах сборки yay, paru или другого помощника можно искать изменения, содержащие atomic-lockfile, js-digest, lockfile-js, вызовы npm install, npm add, bun add и необычные послеустановочные функции.
Текущая версия пакета может выглядеть безопасной, поскольку администраторы принудительно удаляли вредоносные коммиты. Для расследования важна версия, реально использованная во время установки.
При подтверждённом запуске неизвестной нагрузки требуется полноценная проверка системы. Удаление одного пакета нельзя считать гарантированной очисткой.
Вопросы и ответы
Arch Linux полностью отключил AUR?
Нет. Заблокирована отправка новых изменений. Уже опубликованные страницы и сценарии остаются доступными для чтения.
Когда началась атака?
Первые массовые сообщения появились 11 июня 2026 года. Официальное предупреждение Arch Linux опубликовано 12 июня.
Когда отключили принятие пакетов?
Функцию временно отключили 30 июля. Все отправки изменений в AUR заблокировали 1 августа.
Что означает принятие пакета на сопровождение?
Пользователь становится новым сопровождающим проекта, оставшегося без владельца, и получает возможность загружать обновления.
Сколько пакетов пострадало?
Окончательного официального числа нет. Пользовательский поиск во время июньской волны сформировал список из 879 веток с подозрительными изменениями, но это не число заражённых компьютеров.
Какие вредоносные зависимости использовались?
В обсуждениях подтверждены atomic-lockfile, js-digest и lockfile-js. Они загружались через npm или Bun.
Пострадали ли официальные пакеты Arch Linux?
Признаков компрометации официальных репозиториев нет. Инцидент относится к пользовательскому AUR.
Опасен ли пакет, установленный до атаки?
Риск возникает, если пакет был установлен, обновлён или пересобран после появления вредоносного коммита. Простое наличие старой версии на компьютере не запускает новый сценарий.
Виноваты ли yay и paru?
Нет. Они автоматизируют работу с AUR, но не являются причиной захвата пакетов. Пользователю всё равно необходимо проверять изменения перед сборкой.
Достаточно удалить подозрительный пакет?
Не обязательно. Выполненный установочный сценарий мог загрузить дополнительные файлы или изменить систему вне контроля пакетного менеджера.
Когда восстановят обновления AUR?
Точная дата не объявлена. Команда Arch Linux обещала выпустить новое сообщение после завершения очистки и защитных работ.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.