Arch Linux 1 серпня тимчасово зупинив усі внесення змін до Arch User Repository (AUR), а перед цим заборонив передавання покинутих пакетів новим супроводжувачам через нову хвилю шкідливих захоплень. Підтверджений поточний випадок починається з openconnect-sso: отруєний процес складання доставляв завантажувач для Linux, а потім інфостілер, троян віддаленого доступу та SSH-черв’як. AUR — спільнотний, а не офіційний репозиторій Arch, однак після складання чи оновлення ураженого пакета потрібно перевірити хост: зупинка репозиторію не видаляє код, який уже запустився.
Команда Arch DevOps оголосила про блокування передачі пакетів 30 липня, а 1 серпня поширила обмеження на всі внесення змін до AUR [1]. Independent Federated Intelligence Network (IFIN) називає openconnect-sso першим підтвердженим пакетом цієї хвилі та повідомляє, що шкідливу зміну вже відкочено [2]. Відкат захищає нове складання від саме цієї зміни, але не скасовує попереднє виконання пакета.
Кому потрібно перевірити Arch Linux
| Ситуація | Ризик і наступна дія |
|---|---|
| Ви використовуєте лише офіційні репозиторії Arch | Задокументований шлях починається в AUR, тому саме цей інцидент із захопленням пакетів не стосується офіційних сховищ. Переконайтеся, що помічник AUR або ручне складання не використовувалися. |
| Ви користуєтеся AUR, але не оновлювали пакети 29 липня-1 серпня | Перегляньте історію пакетів і помічника AUR. Публічна оцінка масштабу ще змінюється. |
openconnect-sso складали чи оновлювали в цей період | Вважайте пакет потенційно ураженим. Звірте точну зміну AUR і файли складання, а потім шукайте ознаки завантажувача та закріплення. |
| Сценарій складання або корисне навантаження виконалося | Ізолюйте хост і вважайте доступні йому дані браузерів, менеджерів паролів, гаманців, cloud/API токенів, месенджерів та SSH-ключів потенційно розкритими. |
| Знайдено ознаки першого чи другого етапу | Збережіть докази, приберіть хост із процесів складання та розгортання, відновіть систему з довіреного джерела й змініть секрети з чистого пристрою. |
Не перетворюйте непідтверджений список спільноти на діагноз. Публічні дописи стверджують, що пакетів значно більше, але Arch не опублікував повного переліку для цієї хвилі. Одного підтвердженого пакета й офіційної зупинки AUR достатньо для цільової перевірки, але не для твердження, що заражено кожен пакет або кожну систему Arch.
Що робить підтверджене шкідливе ПЗ
Проаналізований перший етап — це завантажувач Linux x86-64. Він шукає ознаки налагодження, ізольованих середовищ, cloud-платформ і CI, після чого може скопіювати себе до системного або прихованого каталогу користувача та закріпитися через systemd і cron. Далі він завантажує Tor із легітимного архіву Tor Project, запускає процес під назвою dbus-daemon і отримує другий етап з onion-сервісу [3]. Сам доступ до легітимного архіву Tor не доводить зараження; важлива послідовність із неочікуваним завантаженням, замаскованим процесом, закріпленням і наступним файлом.
Другий етап поєднує викрадення облікових даних, віддалене керування та поширення через SSH. Він шукає профілі браузерів, дані менеджерів паролів, криптогаманці, сесії месенджерів, конфігурації cloud і Kubernetes, облікові дані реєстрів пакетів, Git-токени, ключі AI-сервісів та SSH. Викрадені SSH-ключі разом з історією відомих хостів дають змогу копіювати й запускати шкідливий файл на інших системах [4]. Саме тому робоча станція розробника або CI runner може стати початком ширшого інциденту. Схожий ризик для секретів розробника створюють шкідливі пакети TrapDoor, хоча спосіб доставки тут інший.
Які ознаки перевірити
| Ознака | Чому вона важлива |
|---|---|
Історія помічника AUR і /var/log/pacman.log | Показує, чи складали або встановлювали openconnect-sso чи інший щойно переданий пакет під час інциденту. |
Неочікувані системні або користувацькі модулі systemd із назвою лише .service | Проаналізований завантажувач використовує systemd і може вмикати тривалу роботу служб користувача після виходу з облікового запису. |
Нові записи @reboot або невідомі файли, які запускає cron | Завантажувач застосовує cron як резервний спосіб закріплення. |
Tor, запущений під назвою dbus-daemon | Шкідливе ПЗ маскує Tor-процес. Звичайний dbus-daemon є нормальним, тому звіряйте шлях до файла, батьківський процес, мережеву активність і час запуску. |
/dev/shm/.agent.bin або незрозумілі приховані виконувані файли | Публічний аналіз називає цей файл проміжним артефактом другого етапу, але його відсутність після видалення не доводить чистоту системи. |
| Невідомі SSH-сеанси або розгортання | Другий етап може повторно використати викрадені ключі для поширення на хости з локальної історії. |
Хеші з IFIN корисні для пошуку відомих зразків, але перевірки лише за хешами недостатньо. Автори звіту попереджають, що поширеність зразків ще невідома, а випадкові назви файлів послаблюють цінність одного фіксованого шляху. Зіставляйте історію пакетів, виконання процесів, закріплення, мережеву активність і використання облікових даних.
Порядок реагування після підозрілого оновлення AUR
- Зупиніть подальше виконання. Призупиніть автоматичні запуски помічника AUR. Не видаляйте кеш пакетів і журнали, доки не зафіксуєте версію, зміну AUR, каталог складання, часові мітки та хеші.
- Визначте стан. Розрізняйте появу пакета в історії, його складання, виконання сценарію, запуск завантажувача та наявність другого етапу.
- Ізолюйте уражений хост. Від’єднайте його від чутливих мереж і приберіть із CI, підписування, публікації пакетів та розгортання. Не змінюйте на ньому паролі й не створюйте нові ключі.
- Збережіть докази. Зберіть історію пакетів, pacman logs, системні та користувацькі модулі, записи cron, дані про процеси й мережу, історію shell, SSH-активність та cloud identity logs.
- Відновіть довіру до системи. Після підтвердженого виконання надійніше перевстановити систему з довіреного джерела, ніж видалити лише видимий пакет. Перевірте всі артефакти складання, створені в період ризику.
- Змініть секрети з чистого пристрою. Відкличте browser і password-manager sessions, Git/package-registry tokens, cloud/API credentials, доступ до гаманців та SSH-ключі. Видаліть старі SSH public keys із серверів.
- Шукайте подальше використання. Перевірте SSH-автентифікацію, активність репозиторіїв, публікації пакетів, cloud actions, CI jobs і нові токени після найранішого можливого запуску.
- Повертайтеся до AUR обережно. Перевірте поточний офіційний допис про інцидент, переглядайте зміни
PKGBUILDта install-файлів, звіряйте upstream sources і checksums та не вважайте знайому назву пакета доказом надійного супроводжувача.
Порядок такий самий, як після інших компрометацій пакетів: спочатку приберіть шкідливе закріплення й поверніть довірене середовище, а вже потім відкривайте йому нові секрети. У випадку зламаних пакетів Joyfill тригер відрізнявся, але відокремлення факту встановлення від факту виконання так само визначає масштаб реагування.
Джерела
- Robin Candau, Arch Linux DevOps. «AUR packages adoption disabled». Список розсилки Arch Linux aur-general, опубліковано 30 липня, оновлено 1 серпня 2026 року, дата звернення: 2 серпня 2026 року. офіційний допис про інцидент.
- Matt Taggart. «New AUR Attack Prompts Adoption Lock». Independent Federated Intelligence Network, опубліковано 30 липня, оновлено 31 липня 2026 року, дата звернення: 2 серпня 2026 року. звіт про поточну хвилю та індикатори.
- ysf. «AUR validator.malware (stage 1)». GitHub Gist, створено 29 липня 2026 року, дата звернення: 2 серпня 2026 року. аналіз завантажувача.
- ysf. «AUR validator.malware (stage2 agent linux x86_64)». GitHub Gist, створено 30 липня 2026 року, дата звернення: 2 серпня 2026 року. аналіз другого етапу.
