Уязвимость FreeIPA с оценкой 9,8 по CVSS позволяет клиенту без входа в систему создать Kerberos-идентичность и в итоге получить права администратора Linux-домена. По данным The Hacker News, Red Hat дважды воспроизвела цепочку на стандартной установке, включая сценарий с машиной без какого-либо доступа. Для команд, которые держат централизованную аутентификацию Linux-инфраструктуры на FreeIPA, это не теоретическая проблема из серии «когда-нибудь поправим».
FreeIPA — это система управления идентификацией, политиками доступа и Kerberos-аутентификацией в Linux-доменах. В продуктах Red Hat она поставляется как Identity Management, пакет называется ipa. Внутри FreeIPA хранит учётные записи и служебные идентичности в базе 389 Directory Server, доступной через LDAP. Именно связка FreeIPA и 389-ds дала неприятный результат: одна ошибка открывала лишнюю запись, вторая ошибочно считала анонимного клиента владельцем этой записи.
Первую часть Red Hat отслеживает как CVE-2026-76578 и предварительно оценивает в критические 9,8 балла. FreeIPA поставляет правило доступа ACI, которое разрешает пользователю управлять собственным одноразовым OTP-токеном. Проблема в том, что правило не требовало, чтобы клиент уже был аутентифицирован, и не ограничивало достаточно жёстко, какие поля можно записать вместе с токеном. Само по себе это выглядело бы как неаккуратная модель прав, но в паре со второй ошибкой превращалось в способ создать пригодные для повторного использования административные учётные данные.
Вторая часть цепочки — CVE-2026-76560 в 389 Directory Server, оценённая Red Hat в 7,5 балла. В механизме контроля доступа есть правило вида «разрешить только аутентифицированному владельцу записи». Проверка сравнивала имя клиента с сохранённым значением как обычный текст. У анонимного клиента имя пустое; если поле владельца тоже пустое, проверка проходила. В результате клиент, который фактически является «никем», мог создать запись OTP-токена с пустыми полями владельца, пройти контроль и дописать Kerberos-имя с паролем.
FreeIPA оказалась именно той конфигурацией, где ошибка 389-ds становится опасной из коробки. Red Hat отдельно подчёркивает: в Red Hat Directory Server такого правила по умолчанию нет, поэтому сам CVE-2026-76560 критичен прежде всего там, где администраторы вручную создали похожую схему доступа. Но стандартная FreeIPA уже содержит правило нужной формы. Поэтому атака работает на нетронутой установке, а не только на экзотической инфраструктуре, которую кто-то творчески настроил в пятницу вечером.
История осложняется тем, что похожий путь уже пытались закрыть раньше. Первоначальный отчёт описывал подмену реального аккаунта admin через создание Kerberos-имени, совпадающего с ним. Исправление CVE-2026-13097 в FreeIPA 4.13.3 заблокировало такую коллизию, но не убрало базовую возможность неаутентифицированной записи. Теперь, по версии Red Hat, атакующий выбирает новое имя и приходит к тому же практическому результату: административным полномочиям. Проект FreeIPA формулирует осторожнее: внедряемая идентичность не должна уже существовать, захват существующих аккаунтов заблокирован, а атака может стать ступенью к административным правам.
Исправление со стороны проекта FreeIPA вышло в версии 4.13.4. Для 389-ds-base Red Hat 8 сентября выпустила серию из 14 advisories для разных выпусков; например, RHSA-2026:64785 закрывает проблему в Red Hat Enterprise Linux 10 с 389-ds-base-3.2.0-10.el10_2 и заодно включает ещё четыре исправления 389-ds. При этом на момент проверки источника 8 сентября в bug records Red Hat для двух ошибок FreeIPA ещё не было указанного исправленного пакета ipa и отдельного advisory для RHEL-пакетов FreeIPA. Fedora-обновление тогда находилось в статусе ON_QA. Это важная деталь для администраторов: версия апстрима уже есть, но путь до конкретного дистрибутива может занять время.
Пока фикс недоступен, Red Hat предлагает два временных шага для цепочки: ограничить доступ к LDAP-сервису, обычно это порты 389 и 636, только доверенными хостами, а также рассмотреть отключение анонимных LDAP bind. Второй вариант нельзя делать вслепую: старые интеграции, мониторинг или внутренние сервисы могут зависеть от анонимного чтения LDAP. Но оставлять LDAP доступным шире, чем нужно, после такого описания атаки — уже не «удобство эксплуатации», а приглашение на аудит с неприятными вопросами.
Отдельно Red Hat раскрыла ещё одну ошибку FreeIPA — CVE-2026-79678 с оценкой 8,1. Она не связана с цепочкой админских Kerberos-учёток. Команда idp-add передавала два пользовательских значения, имя организации и базовый URL, в Python eval() до проверки прав администратора identity provider. Red Hat пишет, что выполнение кода невозможно из-за ограничивающего шаблона, запрещающего скобки. Зато обычный пользователь сервера может читать переменные окружения процесса по одной через ошибки и расходовать память коротким арифметическим выражением. В обычной пакетной установке там, как правило, лежат документированные пути и настройки. В контейнерах риск выше: официальный образ FreeIPA при первом запуске часто получает пароль Directory Manager и администратора через переменные окружения, и эти значения надо проверить после инициализации.
Публичных признаков эксплуатации в реальных атаках в опубликованных материалах нет. Но для бизнеса это слабое утешение: уязвимость FreeIPA бьёт по слою, который решает, кто вообще имеет право входить в Linux-домен, получать Kerberos-билеты и обращаться к встроенным сервисам вроде Dogtag CA. Red Hat также указывает, что в установках с Windows-style security identifiers атакующий может получить Kerberos-ticket с authorization data, расширив доступ к HTTP- и Dogtag-сервисам FreeIPA.
Главный практический вопрос теперь не только «поставили ли мы FreeIPA 4.13.4», а «можем ли мы доказать, что до патча никто не создал лишнюю идентичность». В advisories и bug reports, судя по опубликованному описанию, нет готовых правил детекта и индикаторов компрометации. Значит, администраторам придётся самостоятельно проверять новые Kerberos principal, членство в административных группах, подозрительные OTP-записи и историю LDAP-изменений. Эта уязвимость FreeIPA хорошо напоминает: identity-инфраструктура редко выглядит эффектно на презентациях, зато при ошибке ломает сразу весь контур доверия.