CVE-2023-54391 у Proxmox VE: як перевірити сервер і закрити обхід автентифікації

Якщо у вас ще працює Proxmox VE 7.x або початковий реліз 8.0, перевірте не тільки загальну версію платформи, а й пакет libpve-access-control. У CVE-2023-54391 вразливий саме він.

Помилка дозволяє атакувальнику обійти перевірку пароля для активного користувача, у якого не налаштований другий фактор. Для атаки має бути доступний API Proxmox на порту 8006 - безпосередньо з інтернету або через reverse proxy. Proxmox повідомляє про незалежні звіти щодо експлуатації цієї вразливості.

Усі вразливі релізи вже завершили життєвий цикл. Підтримувані версії Proxmox VE не вразливі. Тому довгострокове рішення - не маскувати проблему окремим firewall rule, а перейти на підтримуваний реліз.

Що перевірити негайно

Почніть із чотирьох питань:

1. Яка версія libpve-access-control встановлена на кожному вузлі?
2. Чи доступний management API на TCP 8006 з інтернету або недовірених мереж?
3. Чи є активні користувачі без другого фактора?
4. Чи можна за логами перевірити входи та зміни конфігурації за період до оновлення?

Якщо одночасно встановлений вразливий пакет, API доступний потенційному атакувальнику і є активний користувач без 2FA, сервер потребує термінового containment та оновлення.

Перевірка версії без зміни конфігурації

На кожному вузлі виконайте read-only команду:

dpkg-query -W -f '${Version}\n' libpve-access-control

Альтернативно подивіться версії всіх пакетів Proxmox:

pveversion -v

Вразливий діапазон:

libpve-access-control >= 7.0-7 і < 8.0.4

Виправлення є в libpve-access-control 8.0.4, випущеному 20 липня 2023 року, та в усіх пізніших версіях.

Не робіть висновок лише зі строки Proxmox VE 7.4 або 8.0. Proxmox окремо попереджає, що версія платформи й версія залежного пакета корелюють не точно. Для рішення потрібен фактичний номер libpve-access-control на кожному вузлі.

Перевірка доступу до API

Уразливий код знаходиться в API автентифікації. Для експлуатації атакувальник повинен мати мережевий доступ до порту 8006, напряму або через reverse proxy.

Перевірте:

• чи опублікований TCP 8006 на зовнішній IP;
• чи проксуює його Nginx, HAProxy, Cloudflare Tunnel або інший gateway;
• чи дозволений доступ з користувацьких VLAN;
• чи є окрема management-мережа;
• чи обмежений доступ VPN та списком довірених адрес;
• чи однакові правила на всіх вузлах кластера.

Тест виконуйте з погодженої зовнішньої точки. Не скануйте чужі адреси й не надсилайте exploit-запити. Для перевірки exposure достатньо встановити, чи доступний management endpoint з мережі, з якої він не повинен бути доступним.

Якщо API відкритий назовні, перший крок - обмежити management-доступ на периметрі або reverse proxy. Зміни firewall потрібно виконувати з out-of-band доступом або людиною на майданчику, щоб не втратити керування вузлом.

Перевірка користувачів і 2FA

Цей шлях атаки стосується активних користувачів без налаштованого другого фактора. Proxmox зазначає, що користувачі з будь-яким налаштованим second factor не вразливі саме до цього обходу.

Перевірте в Datacenter → Permissions:

• активних локальних і зовнішніх користувачів;
• користувачів з адміністративними ролями;
• root@pam;
• сервісні облікові записи;
• облікові записи колишніх працівників і підрядників;
• API tokens та їхні привілеї;
• наявність другого фактора для кожного інтерактивного адміністратора.

Увімкнення 2FA зараз зменшує поточний ризик, але не доводить, що доступу не було раніше. Якщо management API був опублікований, потрібна окрема перевірка журналів і змін.

Що робити, якщо пакет вразливий

1. Обмежити management-доступ

Закрийте порт 8006 від недовірених мереж. Залиште доступ через окрему management VLAN, VPN або погоджений allowlist. Перевірте не тільки firewall самого вузла, а й NAT, reverse proxy, зовнішній firewall та cloud gateway.

2. Зафіксувати поточний стан

До оновлення збережіть:

• версії пакетів на всіх вузлах;
• список користувачів, ролей, realms і API tokens;
• конфігурацію firewall та reverse proxy;
• стан кластера й storage;
• статус актуальних backup;
• журнали входів і системних подій.

Не копіюйте секрети в загальний тикет або месенджер. Вивантаження з обліковими даними зберігайте у погодженому захищеному сховищі.

3. Перейти на підтримуваний Proxmox VE

Proxmox вказує, що жоден підтримуваний реліз не вразливий, а всі affected releases мають EOL-статус. Перед міграцією потрібно перевірити:

• підтримуваний upgrade path;
• сумісність CPU, kernel, QEMU, LXC, ZFS/Ceph та сторонніх модулів;
• вільне місце;
• стан кластера і quorum;
• резервні копії критичних VM і контейнерів;
• доступ до консолі;
• порядок оновлення вузлів;
• rollback або recovery plan.

Не оновлюйте весь кластер одночасно. Для кожного вузла потрібні окремі pre-check, maintenance window і перевірка після перезавантаження.

4. Якщо оновитися зараз неможливо

Vendor advisory містить тимчасову patch-процедуру для EOL-інсталяцій. У цій статті команда навмисно не наведена: вона змінює production-код і перезапускає служби керування. Помилка може залишити вузол у вразливому стані або порушити доступ.

Тимчасовий патч має сенс лише як короткий containment-крок із backup файлу, перевіркою результату та планом відкату. Він не повертає EOL-системі підтримку і не замінює міграцію.

Як перевірити, чи не було стороннього входу

Наявність вразливої версії не означає автоматичну компрометацію. Так само оновлення не доводить, що стороннього доступу не було до нього.

Для triage перевірте:

• успішні й невдалі входи в management API;
• незвичні джерела, час і користувачів;
• створення або зміну користувачів, ролей та API tokens;
• зміни firewall, reverse proxy і network configuration;
• нові scheduled jobs та завдання backup;
• зміни VM, контейнерів, storage і cluster configuration;
• події на всіх вузлах, а не лише на одному;
• логи VPN, зовнішнього firewall і reverse proxy.

Якщо є підозріла активність, спочатку збережіть журнали та інші volatile evidence. Потім ізолюйте management plane, відкличте підозрілі сесії й tokens, змініть облікові дані через довірений канал і перевірте критичні VM. Не обмежуйтеся зміною пароля root@pam.

Перевірка після оновлення

Роботу не можна вважати завершеною лише тому, що пакетний менеджер повернув успішний статус.

Acceptance checklist:

• libpve-access-control має версію 8.0.4 або новішу;
• сам Proxmox VE перебуває на підтримуваній гілці;
• management API недоступний з непогоджених мереж;
• адміністратори мають персональні облікові записи й 2FA;
• зайві користувачі й tokens відкликані;
• web UI та API працюють через погоджений management path;
• кластер має quorum;
• VM і контейнери запускаються та мігрують за штатним сценарієм;
• storage доступний на всіх потрібних вузлах;
• backup jobs завершуються без помилок;
• журнали надходять у визначене місце;
• зафіксовані версії, дата робіт і результат перевірки.

Коли потрібен інженер

Не виконуйте оновлення без підготовки, якщо:

• це кластер із Ceph або спільним storage;
• немає перевіреної резервної копії;
• management API відкритий в інтернет;
• є ознаки стороннього входу;
• невідомий порядок оновлення між major versions;
• вузол містить критичні VM без maintenance window;
• немає фізичної або out-of-band консолі;
• конфігурація залежить від нестандартних kernel modules чи сторонніх репозиторіїв.

IT Advanced працює з Proxmox VE, ZFS, Ceph, кластерами та реплікацією в межах послуги обслуговування серверів. Почати можна з read-only перевірки версій, exposure management API, користувачів, 2FA, backup і стану кластера. Оновлення, міграція, відновлення та інші проєктні роботи погоджуються окремо.

Часті запитання

Які версії вразливі до CVE-2023-54391?

Точний діапазон - libpve-access-control від 7.0-7 включно до версій нижче 8.0.4. Це приблизно відповідає Proxmox VE 7.0-7.4 і початковому 8.0, але перевіряти потрібно саме пакет.

Чи вразливий актуальний Proxmox VE?

За advisory Proxmox, жоден підтримуваний реліз не вразливий. Усі affected releases вже завершили життєвий цикл.

Чи захищає 2FA?

Користувач із налаштованим другим фактором не вразливий до описаного шляху обходу. Але 2FA не замінює оновлення EOL-системи та обмеження management API.

Чи достатньо закрити порт 8006?

Обмеження доступу прибирає мережеву передумову атаки з непогоджених джерел, але не виправляє вразливий код і не вирішує проблему EOL. Потрібен перехід на підтримуваний реліз.

Чи входить CVE до CISA KEV?

У перевіреній версії каталогу CISA KEV 2026.09.01 точного запису CVE-2023-54391 немає. Водночас Proxmox повідомляє про незалежні звіти щодо експлуатації, а VulnCheck включив уразливість до власного KEV.

Чому CVE має 2023 у номері, якщо advisory з'явився у 2026 році?

Номер CVE не є датою публікації статті. Запис CVE опублікований 1 вересня 2026 року, а vendor advisory датований тією ж датою. Уразливий код був змінений ще в липні 2023 року як частина іншої переробки.

Перевірити Proxmox VE

Проведемо read-only перевірку версій, доступу до management API, користувачів, 2FA, backup та стану кластера. Якщо система вразлива, підготуємо порядок containment, оновлення й перевірки без універсальних production-скриптів.

CTA: Замовити перевірку Proxmox VE

Для первинної оцінки достатньо версії Proxmox VE, версії libpve-access-control, кількості вузлів і відповіді, чи опублікований порт 8006. Паролі, tokens, приватні ключі та конфігурації через форму не надсилайте.