Статья CVE-2026-42809 Apache Polaris: угон облачных credentials через staged table creation

NVD - cve-2026-42809

Четыре critical CVE в одном сервисе за один день. 4 мая 2026 года Apache Polaris получил security advisory, от которого у data-инженеров должно было подкоситься настроение. CVE-2026-42809 из этой связки - самый показательный: CVSS 9.4 (CRITICAL по CVSS 4.0), вектор AV:N/AC:L/AT:N/PR:L/UI:N. Аутентифицированный пользователь с минимальными правами шлёт один запрос к REST catalog API, и Polaris сам конструирует для него temporary storage credentials к произвольному cloud-объекту. Без exploit chain, без обхода WAF. Сервис работает как credential-автомат с кнопкой "выдать ключи от чужого бакета".

На русском языке этой уязвимости посвящены только карточки NVD и агрегаторов - технического разбора нет. Закрываю пробел.

Бизнес-логика атаки: зачем credential vending в data lakehouse опасен​

Apache Polaris - REST catalog для Apache Iceberg, open-source формата организации данных в data lakehouse. В production-деплоях Polaris управляет сотнями таблиц, разбросанных по S3 (AWS), GCS (GCP) или Azure Blob Storage. Каждый раз, когда клиент (Spark, Trino, Flink) обращается к таблице, Polaris может выдать ему temporary credentials - короткоживущие STS-токены, ограниченные по scope до конкретного storage prefix.

Это credential vending: каталог работает IAM-брокером между пользователем и облачным хранилищем. Пользователь не имеет прямого IAM-доступа к S3/GCS - он получает временные ключи через Polaris, и эти ключи ограничены только тем storage path, где лежат файлы конкретной таблицы.

Теперь проецируем на модель угроз. IAM-роль Polaris имеет доступ к десяткам бакетов с production-данными, потому что обслуживает весь каталог. Если атакующий управляет scope выдаваемых credentials - он получает доступ не к одной таблице, а к любому storage path в пределах IAM-роли сервиса. Финансовые данные, PII клиентов, аналитика, ML-модели - всё, до чего дотягивается service account Polaris, доступно через один HTTP-запрос. Для организации с терабайтами чувствительных данных в data lakehouse это полная компрометация data tier.

Механика CVE-2026-42809: как Apache Polaris выдаёт credentials без валидации​

Уязвимость сидит в stage-create flow - механизме создания "черновых" таблиц в Iceberg REST Catalog. Stage-create - двухфазная операция: сначала таблица создаётся как staged (черновик), получает storage credentials для записи начальных данных, и только потом фиксируется через commit как полноценная таблица.

Согласно NVD, корневая проблема: Polaris выдаёт temporary credentials до валидации location и до проверки на пересечение с другими таблицами (overlap checks). Разложу по шагам:

1. Атакующий шлёт запрос на stage-create с произвольным значением location - скажем, s3://finance-production-bucket/reports/.
2. Polaris принимает этот location как целевой для credential scoping.
3. Polaris конструирует delegated storage credentials (STS-токены), привязанные к указанному location.
4. Credentials возвращаются атакующему до того, как stage-create path выполнит location validation или overlap checks.
5. Атакующий использует полученные STS-токены для прямого доступа к S3/GCS - через aws cli, boto3, gsutil.

По данным NVD, stage-create flow также принимает свойства write.data.path и write.metadata.path в теле запроса. Это вторичный вектор: поля подставляются в effective table location set для credential vending и тоже не проходят валидацию перед выдачей credentials. Из advisory: "those fields are secondary to the main custom-location exploit, but they are still attacker-influenced location inputs that should be validated before any credentials are issued""Эти поля являются второстепенными по отношению к основной уязвимости, связанной с настройкой местоположения, но они всё же представляют собой вводимые данные о местоположении, на которые может повлиять злоумышленник, и их следует проверять перед выдачей каких-либо учётных данных".

Два CWE - два аспекта уязвимости Apache Polaris​

Согласно NVD (CNA: Apache Software Foundation), уязвимости присвоены два CWE:

CWE-20 (Improper Input Validation) - location, write.data.path и write.metadata.path принимаются от пользователя без проверки на принадлежность к разрешённому scope. По классификации MITRE, вероятность эксплуатации - High. Последствия: чтение и модификация данных, потенциальный DoS.

CWE-862 (Missing Authorization) - нет проверки авторизации на доступ к произвольному storage path. Polaris проверяет право на создание таблицы, но не право получить credentials к конкретному бакету. По MITRE: вероятность High, последствия - чтение и модификация данных, повышение привилегий.

Связка показательна: проблема не только в том, что input не фильтруется, но и в отсутствии авторизационного барьера между "право создать таблицу" и "право получить credentials к любому бакету в пределах IAM-роли сервиса". Два разных дефекта, одна точка входа.

Место в цепочке атаки: credential vending attack от initial access до exfiltration​

Для пентестера credential vending attack в Apache Polaris интересна тем, как чисто она ложится на kill chain. Маппинг на MITRE ATT&CK:

Этап	Техника ATT&CK	Действие атакующего
Initial Access	Exploit Public-Facing Application (T1190)	Аутентификация в Polaris REST API с low-priv credentials
Credential Access	Exploitation for Credential Access (T1212)	Отправка stage-create запроса с произвольным location
Credential Access	Steal Application Access Token (T1528)	Получение vended STS-токенов от Polaris
Collection	Data from Cloud Storage (T1530)	Прямой доступ к S3/GCS по полученным credentials
Exfiltration	Transfer Data to Cloud Account (T1537)	Копирование данных в контролируемый аккаунт

Обратите внимание: классического privilege escalation здесь нет. Атакующий не повышает привилегии в Polaris - он использует легитимный механизм credential vending, подставляя свой location. Сервис добровольно выдаёт ключи. По CISA-ADP Technical Impact - total: полная компрометация confidentiality, integrity и availability data tier.

Отдельная точка внимания - Cloud Instance Metadata API (T1552.005, Credential Access). Если Polaris развёрнут на EC2/GCE и получает IAM-credentials через instance metadata, credential vending path потенциально позволяет добраться до credentials уровня service account самого Polaris. Зависит от деплоя: при IRSA в EKS или Workload Identity в GKE риск снижается.

Также релевантна Cloud Accounts (T1078.004): украденные temporary credentials годятся для persistence - если scope достаточно широк, атакующий закрепляется в storage-слое, создавая backdoor-объекты или модифицируя metadata файлы существующих таблиц.

Предусловия и ограничения credential vending attack в Apache Polaris​

Работает если:

• Атакующий аутентифицирован в Polaris REST API (CVSS вектор: PR:L - low privileges, не анонимный доступ; TheHackerWire ошибочно указывают PR:N - по верифицированному CVSS-вектору от CNA Apache Software Foundation это именно PR:L)
• Polaris настроен на credential vending для staged tables (штатная конфигурация production-деплоев)
• IAM-роль Polaris имеет доступ к целевому storage path
• Целевой storage path "reachable" - Polaris может создать scoped credentials для него через механизм delegation IAM-провайдера

Не работает если:

• Polaris не использует credential vending (клиенты обращаются к storage напрямую с собственными IAM credentials - редкий, но возможный паттерн деплоя)
• VPC Service Controls (GCP) или S3 bucket policies ограничивают доступ по source VPC/IP - vended credentials бесполезны за пределами целевой сети
• IAM-роль Polaris ограничена единственным бакетом с минимальным scope (principle of least privilege на практике - редкость, но бывает)
• Apache Polaris обновлён до версии 1.4.1+ (уязвимый пакет: org.apache.polaris:polaris-runtime-service, все версии от 0 до 1.4.1)

EPSS-контекст: по данным FIRST.org на 13 июля 2026, EPSS составляет 0.0036 (0.36%), percentile 27.69% - ниже медианы всех CVE. Вероятность эксплуатации в ближайшие 30 дней оценивается как низкая. По CISA-ADP эксплуатация в дикой среде не зафиксирована (exploitation: none), атака не автоматизируема (automatable: no). Решение CISA: Track.

Низкий EPSS объясняется нишевостью продукта, а не сложностью атаки. Для организаций, у которых Polaris крутится в production, фактический риск на порядок выше статистического. EPSS считает по всей популяции CVE - а тут один запрос и полный доступ к data lake.

Воспроизведение: пошаговый сценарий эксплуатации CVE-2026-42809​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Шаг 3. Получение vended credentials - Polaris возвращает в ответе (или через отдельный credential-vending endpoint) временные STS-токены, scoped к указанному s3://target-data-bucket/sensitive-prefix/.

Шаг 4. Прямой доступ к storage - полученные credentials подставляем в AWS CLI: aws s3 ls s3://target-data-bucket/sensitive-prefix/ --profile vended. Дальше - скачивание, модификация или удаление объектов в зависимости от scope permissions.

Шаг 5. Итерация - если первый запрос сработал, перебираем другие storage paths: корневые prefix'ы бакетов, metadata-директории других таблиц, смежные бакеты. Каждый новый stage-create с новым location выдаёт новый набор credentials. По сути - сканирование IAM-scope через API каталога.

Ограничения при воспроизведении​

• Публичный PoC отсутствует (по данным TheHackerWire на момент публикации advisory)
• Точный механизм запроса credential vending (HTTP header, query parameter, отдельный endpoint) не детализирован в advisory и зависит от конфигурации Polaris
• MinIO может не полностью имитировать credential vending flow AWS STS - для полноценного воспроизведения нужен реальный cloud backend
• Stage-create может быть ограничен ACL Polaris на уровне realm/catalog/namespace - зависит от гранулярности настроенной авторизации
• Scope выданных credentials определяется IAM policy delegation - если IAM-роль Polaris использует session policies или permission boundaries, фактический scope может быть уже, чем запрошенный location

Связка с CVE-2026-42812: расширение attack surface через write.metadata.path​

CVE-2026-42809 - не единственный credential vending вектор в Polaris. Связанная CVE-2026-42812 (CVSS 9.4 CRITICAL, CVSS 4.0) эксплуатирует другой путь к тем же credentials: через ALTER TABLE-style изменение свойства write.metadata.path для уже существующей таблицы.

По данным TheHackerWire, в CVE-2026-42812 Polaris пропускает revalidation branch при изменении только write.metadata.path. Сервис записывает metadata файл по атакующему-контролируемому пути, а последующие table-load и credential API вызовы выдают credentials к этому пути без ревалидации. CWE у CVE-2026-42812 шире: CWE-20, CWE-284, CWE-732, CWE-863 - добавлены Improper Access Control, Incorrect Permission Assignment и Incorrect Authorization.

Два вектора - два независимых пути к одной цели:

Характеристика	CVE-2026-42809	CVE-2026-42812
Вектор входа	Stage-create с custom location	ALTER TABLE + write.metadata.path
Требуемое право	Создание таблицы в namespace	Изменение свойств существующей таблицы
Устойчивость	Credentials одноразовые (staged table)	Путь персистентно записан в table state
Расширяющее условие	Нет	allow.unstructured.table.location=true
CVSS 4.0	9.4	9.4

CVE-2026-42812 опаснее в плане persistence: отравленный write.metadata.path сохраняется в table state, credentials к нему выдаются при каждом последующем table-load. CVE-2026-42809 - про одноразовый "угон" с более низким порогом входа: не нужен доступ к существующей таблице, достаточно права на stage-create. Оба исправлены в версии 1.4.1.

На практике, если первый вектор закрыт ACL на stage-create, стоит проверить второй - через ALTER TABLE. И наоборот. Они дополняют друг друга.

Детекция и митигация Apache Polaris credential hijacking​

Что мониторить​

Ключевые сигналы в логах Polaris и облачных audit trail:

• Stage-create запросы с нестандартным location - если location в stage-create указывает на бакет или prefix, не совпадающий с default storage location namespace. Алерт на любой stage-create, где location выходит за пределы allowedLocations каталога.
• Credential vending к неожиданным storage paths - в CloudTrail (AWS) или Cloud Audit Logs (GCP) фиксируются вызовы AssumeRole / GenerateCredentials с policy scope, не соответствующим зарегистрированным таблицам каталога. Концептуальный паттерн фильтрации:

eventName = "AssumeRole"
requestParameters.policy содержит storage path,
  не совпадающий с известными table locations
sourceIPAddress = IP-адрес Polaris-инстанса

Паттерн для CloudTrail. Конкретный формат зависит от IAM-конфигурации и способа credential delegation в деплое.

• Массовые stage-create от одного пользователя - несколько staged tables за короткий период с разными location - это перебор storage scope. Тут даже сложной корреляции не нужно, достаточно счётчика.
• Изменения write.metadata.path в существующих таблицах (для детекции CVE-2026-42812) - любой ALTER TABLE, меняющий только это свойство, подозрителен.

Чеклист для администраторов Polaris​

1. Обновить org.apache.polaris:polaris-runtime-service до версии 1.4.1 или выше - закрывает CVE-2026-42809, CVE-2026-42810, CVE-2026-42811, CVE-2026-42812
2. Установить polaris.config.allow.unstructured.table.location=false - ограничить таблицы структурированными location (снижает impact CVE-2026-42812)
3. Ревизировать allowedLocations каждого каталога - убрать wildcard-пути и bucket-root, оставить конкретные prefix'ы
4. IAM-роль Polaris: principle of least privilege - ограничить доступ только бакетами, реально используемыми каталогом
5. Включить аудит stage-create операций в логах Polaris (уровень INFO или выше для API-запросов)
6. Настроить алерты в CloudTrail / Cloud Audit Logs на AssumeRole с нестандартным policy scope от Polaris-инстанса
7. Применить VPC Service Controls (GCP) или S3 bucket policies с ограничением по source VPC - vended credentials не будут работать за пределами целевой сети
8. Минимизировать количество пользователей с правом stage-create через ACL Polaris на уровне namespace
9. Провести ретроспективный анализ логов на предмет stage-create с нехарактерными location за период до обновления

Credential vending - штука, которую data-инженеры воспринимают как удобство, а пентестеры - как attack surface. Проблема CVE-2026-42809 не в конкретном баге Polaris, а в архитектурном паттерне: сервис-посредник, который одновременно каталог метаданных и IAM-брокер. Когда один компонент решает, кому какие credentials выдать, любой дефект валидации превращается в ключ от всего data lake.

На пентестах data lakehouse-инфраструктур я вижу один и тот же паттерн: команды безопасности фокусируются на сетевом периметре и IAM-политиках самого облака, но credential vending layer между каталогом и storage остаётся в слепой зоне. Никто не мониторит, к каким storage paths Polaris выдаёт временные токены - это же "внутренняя механика каталога". В результате аутентифицированный пользователь с правом создавать таблицы (а это в большинстве организаций каждый data-аналитик) получает implicit trust уровня storage.

Credential vending уязвимости будут появляться в каждом data lakehouse каталоге, который берёт на себя роль credential broker - Unity Catalog, Gravitino, любой custom REST catalog поверх Iceberg. Везде, где есть слой между пользователем и storage credentials, будет этот класс проблем. Стоит включить проверку credential vending scope в стандартный чеклист при аудите data platform. Проверьте свои деплои Polaris прямо сейчас - если stage-create с чужим location возвращает STS-токены, у вас та же проблема.