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 не затронуты. Поэтому долгосрочное решение состоит в переходе на поддерживаемый релиз, а не в попытке навсегда оставить EOL-систему за одним firewall rule.

Что проверить прямо сейчас

Ответьте на четыре вопроса:

1. Какая версия libpve-access-control установлена на каждом узле?
2. Доступен ли management API на TCP 8006 из интернета или пользовательских сетей?
3. Есть ли активные пользователи без второго фактора?
4. Сохранились ли логи, по которым можно проверить входы и изменения до обновления?

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

Как безопасно проверить версию

На каждом узле выполните 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 и списком доверенных адресов;
• одинаково ли защищены все узлы кластера.

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

Если API доступен снаружи, сначала ограничьте доступ на периметре или reverse proxy. Менять firewall нужно при наличии out-of-band доступа или сотрудника на площадке, иначе можно потерять управление узлом.

Проверьте пользователей и 2FA

Этот путь атаки работает против активных пользователей без второго фактора. Proxmox указывает, что пользователи с любым настроенным second factor не затронуты именно этим обходом.

В Datacenter → Permissions проверьте:

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

Настройка 2FA сейчас снижает текущий риск, но не доказывает, что стороннего доступа не было раньше. Если management API был опубликован, отдельно проверьте логи и конфигурационные изменения.

Что делать с уязвимым сервером

1. Ограничить management plane

Закройте порт 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;
• backup критичных VM и контейнеров;
• доступ к консоли;
• очередность обновления узлов;
• recovery plan.

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

4. Если обновление сейчас невозможно

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

Временный patch можно рассматривать только как короткий containment-шаг с резервной копией изменяемого файла, проверкой результата и планом отката. Он не возвращает 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.

Почему в номере указан 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, приватные ключи и конфигурации через форму не отправляйте.