Уразливість APT у Debian та Ubuntu: як MitM-атака підміняє перевірені пакети і запускає код із правами root

Що сталося

4 листопада 2026 року розробники Debian, Canonical (Ubuntu) та команда самого APT одночасно опублікували повідомлення про уразливість CVE-2026-109518 у пакетному менеджері APT — основі оновлення програмного забезпечення для Debian, Ubuntu та всіх похідних від них дистрибутивів. Це одна з тих вразливостей, які б'ють у саму основу довіри до Linux-систем: вона дозволяє атакуючому, що контролює мережевий трафік між сервером і дзеркалом пакетів, підмінити вже перевірений пакет своїм власним — і цей підмінений код виконується з правами root.

Уразливість виявив дослідник Max Justicz, який у соцмережі X описав свій процес коротко й показово: «Я використовував ШІ дві години і знайшов zero-day, яка дозволила б державі зламати будь-який сервер на звичайному Ubuntu». Ubuntu оцінила уразливість як High із балом CVSS 4.0 = 7,7, а самі розробники APT називають її критичною. Важливо, що на момент публікації ані Debian, ані Canonical не повідомляли про випадки реальної експлуатації — але це не привід відкладати оновлення.

Суть уразливості: hard links і повторні завантаження

APT — це інструмент, якому адміністратори довіряють безумовно: коли ви запускаєте apt install, менеджер завантажує пакети з репозиторію, перевіряє їхні цифрові підписи і лише після цього встановлює. Встановлення відбувається з привілеями root, тому що у складі пакета виконуються так звані maintainer-скрипти — службові сценарії, які налаштовують систему після розпакування файлів.

Проблема криється у двох механізмах, які у звичайній ситуації працюють непомітно. Перший — це обробка HTTP-редиректів: коли дзеркало перенаправляє запит, APT може «склеїти» два завантаження різних пакетів, якщо вони опинилися за однією адресою. Другий — це повторні спроби завантаження (retries): якщо сервер тимчасово не відповідає або повертає помилку, APT повторює завантаження. Під час цієї повторної спроби файл повторно використовується через hard link, і саме тут атакуючий може підмінити вміст уже після того, як пакет пройшов перевірку підпису.

У базі MITRE уразливість віднесено до двох класів: CWE-62 (UNIX hard link) і CWE-367 — гонка «час перевірки / час використання» (TOCTOU). Класична схема, коли система перевіряє один файл, а використовує згодом уже інший.

Щоб зрозуміти, чому це серйозно, варто нагадати, як APT перевіряє пакети. Менеджер не підписує кожен .deb окремо: репозиторій містить підписаний GPG-ключем файл Release, у якому перелічені контрольні суми всіх пакетів. APT звіряє завантажений файл із цими сумами, і лише якщо вони збігаються, вважає пакет «перевіреним». Уразливість же дозволяє підмінити файл уже після того, як цей збіг підтверджено, — тобто мітка «перевірено» приклеюється до зовсім іншого, атакуючого, вмісту.

Як працює атака

Головна вимога до атакуючого — можливість змінювати HTTP-трафік між APT і сервером пакетів. Це може бути машина на мережевому шляху, зловмисне дзеркало репозиторію або скомпрометований проксі-сервер. Атака розгортається так:

1. Атакуючий використовує HTTP-редиректи, щоб змусити два різні завантаження пакетів отримати однакову адресу — APT починає сприймати їх як один і той самий файл.
2. Звичайні тимчасові помилки сервера (наприклад, 500 або 503) змушують APT зробити повторну спробу завантаження.
3. Під час повторної спроби APT перевикористовує файл через hard link, і атакуючий підставляє свій пакет замість уже перевіреного.
4. Пакет встановлюється, його maintainer-скрипти виконуються з правами root — атакуючий отримує повний контроль над системою.

Ключова передумова — параметр Acquire::Retries має бути більшим за нуль. За замовчуванням значення 3 встановлено починаючи з Debian 12 (Bookworm) і Ubuntu 22.04 LTS. Саме тому старіші випуски в дефолтній конфігурації не вразливі — але розробники APT застерігають, що багато скриптів, образів і систем керування конфігурацією вмикають retries вручну навіть на старих версіях.

Хто під загрозою

Список вразливих систем довгий саме тому, що APT — це спільна основа:

• Debian 12 (Bookworm) і Debian 13 (Trixie) у дефолтній конфігурації.
• Debian testing (Forky) — на момент розкриття ще працював на вразливій версії APT 3.3.5.
• Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS і 26.10.
• Похідні дистрибутиви — Ubuntu прямо зазначає, що вразливі й збірки, побудовані на Debian/Ubuntu, не називаючи конкретних.
• Debian 11 (Bullseye) і Ubuntu 20.04 та старіші — лише якщо retries увімкнено вручну.

Окремий аспект підкреслила Amazon: уразливість стосується екземплярів Amazon EC2 на Ubuntu/Debian і контейнерних образів на їх основі. Для контейнерів це особливо неприємно, бо «перепекти» образ доводиться вручну по всьому пайплайну.

Важлива деталь: повідомлення описують атаку через HTTP-джерела пакетів. Сам факт, що багато інсталяцій досі використовують незашифровані HTTP-дзеркала для внутрішніх репозиторіїв, розширює реальну поверхню атаки.

Що вже виправлено

Патчі вийшли того ж дня, 4 листопада 2026 року. Ubuntu випустила оновлення у бюлетені USN-8996-1:

• Ubuntu 26.10 → apt 3.3.3ubuntu0.1
• Ubuntu 26.04 LTS → apt 3.2.1ubuntu0.1
• Ubuntu 24.04 LTS → apt 2.8.4ubuntu0.1
• Ubuntu 22.04 LTS → apt 2.4.15ubuntu0.1
• Старіші LTS (20.04 і нижче) — лише через підписку Ubuntu Pro (наприклад, 20.04 → 2.0.12+esm1)

Debian закрив проблему двома бюлетенями: DSA-6607-1 для Trixie (apt 3.0.4) і DLA-4880-1 для Bookworm (apt 2.6.2). Для Debian unstable виправлення вийшло у версії 3.3.6. Окремо розробники APT опублікували виправлений пакет 2.2.5 для Debian 11 (Bullseye), довгострокова підтримка якого завершилася ще 31 серпня 2026 року.

Сам фікс, який ще 12 жовтня підготував розробник APT Julian Andres Klode, змінює код завантаження так, щоб файл призначення відкривався ексклюзивно, а наявні файли видалялися перед копіюванням частково завантаженого вмісту. Це прибирає саму можливість «склеювання» двох завантажень через hard link.

Контекст: не перша знахідка того самого дослідника

Для Max Justicz це вже друга знайдена уразливість саме в APT. У січні 2019 року він виявив CVE-2019-3462 — тоді обробник HTTP-редиректів не коректно «чистив» поля, які передаються мережею, і атакуючий «посередині» міг впровадити шкідливий вміст, який APT сприймав як валідний пакет і встановлював із правами root. Тоді теж радили тимчасово відключати редиректи: apt -o Acquire::http::AllowRedirect=false update.

Схожість симптомів показова: і сім років тому, і зараз проблема лежала не в конкретному пакеті, а в самому транспортному рівні APT — у тому, як менеджер довіряє даним, що приходять мережею, ще до того, як звірити їх із підписаним маніфестом. Саме тому такі баги виправляють негайно, а бюлетені публікують того самого дня.

Як перевірити, що ви вже захищені

Після оновлення варто не вірити на слово, а перевірити фактичну версію пакета командою apt-cache policy apt.

Очікувані виправлені версії: Ubuntu 22.04 LTS — 2.4.15ubuntu0.1, Ubuntu 24.04 LTS — 2.8.4ubuntu0.1, Ubuntu 26.04 LTS — 3.2.1ubuntu0.1, Ubuntu 26.10 — 3.3.3ubuntu0.1; Debian Bookworm — 2.6.2, Debian Trixie — 3.0.4, Debian unstable — 3.3.6. Якщо у тій самій гілці ви бачите нижчу версію — система ще вразлива, і оновлення не встановилося (наприклад, немає доступу до репозиторію безпеки).

Окремо зверніть увагу на старі системи. Debian 11 (Bullseye) і Ubuntu 20.04 та нижче не входять у дефолтний список уразливих, але якщо на них уручну ввімкнено Acquire::Retries — вони теж під ударом. Для них виправлення існують (Bullseye — apt 2.2.5, Ubuntu 20.04 — через Ubuntu Pro), але надійніше спланувати перехід на підтримуваний випуск.

Як захиститися

1. Оновіть APT негайно. Базові команди: sudo apt-get update && sudo apt-get upgrade. Якщо у вас великий парк серверів або контейнерів, проженіть оновлення через штатну систему керування конфігурацією (Ansible, Puppet тощо) і переконайтеся, що пакет apt замінився на виправлену версію зі списку вище.
2. Тимчасовий запобіжник до оновлення. Якщо оновитися прямо зараз неможливо, вимкніть повторні спроби: echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-no-retries. Це не виправлення, а лише прибирає одну з двох умов атаки — і на нестабільному з'єднанні може зробити оновлення менш надійним. Після встановлення патча обов'язково поверніть значення або видаліть файл.
3. Використовуйте HTTPS-дзеркала. Якщо ваші джерела sources.list досі вказують на http://, переведіть їх на зашифровані https://-дзеркала — це знижує ризик перехоплення трафіку на мережевому шляху.
4. Переберіть контейнерні образи. Для Docker/Kubernetes перебудуйте базові образи з виправленим APT і проженіть скан вразливостей по registry — старі образи можуть «спати» місяцями і чекати, поки їх знову розгорнуть.
5. Оновіть застарілі системи. Debian 11 (Bullseye) уже без довгострокової підтримки; якщо такі машини досі в роботі — плануйте міграцію, а не покладайтеся на окремі «заплатки» розробників.
6. Підвищуйте обізнаність команди. Ця вразливість — чудовий приклад того, чому базова гігієна оновлень і розуміння ланцюга постачання важливіші за будь-який окремий патч. Почати можна з нашого матеріалу «Кібербезпека: навчання».

Висновок

CVE-2026-109518 б'є в місце, де більшість адміністраторів почувається у повній безпеці, — у пакетний менеджер. Вона не потребує ні помилки користувача, ні складного експлойта: достатньо опинитися на мережевому шляху або контролювати проксі/дзеркало, і перевірений пакет можна підмінити «на льоту». Саме тому її називають критичною попри порівняно «скромний» бал CVSS.

Добра новина — у тому, що механізм атаки вимагає одночасно двох умов (редиректи плюс повторні спроби), а патчі вже доступні для всіх актуальних випусків. Жодних випадків реальної експлуатації не зафіксовано, але це не гарантія на майбутнє: як показує практика, публічне розкриття таких вразливостей зазвичай запускає гонку між адміністраторами, що оновлюються, і зловмисниками, які пишуть експлойт.

Головний урок ширший за один пакет. Довіра до інструментів, які ми використовуємо «на автоматі», має регулярно проходити перевірку — і у випадку з APT ця перевірка вкотре підтвердила: своєчасне оновлення і зашифровані канали доставки пакетів залишаються двома найдешевшими й найефективнішими лініями захисту будь-якої Linux-інфраструктури.