CVE-2026-42809 : Apache Polaris credential vending RCE (9.9)

Les faits

La vulnérabilité CVE-2026-42809, publiée le 4 mai 2026, frappe Apache Polaris, le catalogue de métadonnées open source pour l'écosystème Apache Iceberg incubé puis promu au sein de la fondation Apache. Avec un score CVSS de 9.9 sur 10.0, la faille s'attaque directement à la fonction la plus sensible de Polaris : le credential vending, c'est-à-dire l'émission de credentials temporaires permettant aux clients d'accéder aux objets de stockage (S3, Google Cloud Storage, Azure Blob Storage) sans partager les clés permanentes.

Le credential vending est la pierre angulaire des architectures lakehouse modernes : au lieu de distribuer des clés AWS ou des comptes de service GCP à chaque utilisateur Spark, Trino ou DuckDB, le catalogue Polaris se charge d'émettre des STS tokens scopés à une table donnée. Cette mécanique repose sur un postulat critique : la portée géographique (le préfixe S3 ou le bucket GCS) du token doit être déterminée par Polaris, pas par le client. C'est précisément cette invariance que CVE-2026-42809 brise.

Le défaut technique se trouve dans le chemin d'exécution stage create avec credential vending activé. Lorsqu'un client demande la création d'une staged table en fournissant une location personnalisée, Polaris construit immédiatement les credentials délégués sur cette location attaquant-fournie sans valider qu'elle respecte le périmètre autorisé par le catalogue. La phase de validation des chevauchements de location et de permissions, qui devrait précéder l'émission des credentials, est court-circuitée par ce code path. Concrètement, un utilisateur ayant des droits limités sur Polaris peut demander des credentials scopés à n'importe quel chemin atteignable par le rôle IAM utilisé en backend.

L'impact sécurité est massif : si Polaris a accès à un bucket S3 contenant l'intégralité du data lake — ce qui est le déploiement par défaut chez la plupart des organisations — alors un attaquant exploitant CVE-2026-42809 peut obtenir des credentials lui permettant de lire ou modifier l'ensemble des données du bucket, indépendamment de ses droits déclaratifs sur les tables Polaris. Le modèle d'autorisation au niveau catalogue est ainsi totalement contourné, ramenant la sécurité au plus petit dénominateur commun défini dans la policy IAM.

La discussion publique sur la mailing-list dev d'Apache Polaris, ouverte plusieurs semaines avant la divulgation officielle sous le titre « S3 Credential vending without STS », avait déjà alerté la communauté sur les implications de cette architecture. Des contributeurs avaient pointé l'absence de garde-fou robuste entre la phase de stage create et la phase de credential vending, sans que cela ne déclenche immédiatement une correction. La publication du CVE et de son score CVSS 9.9 vient officialiser le risque.

D'après les éléments disponibles dans la notice CVE et les analyses indépendantes publiées, aucune authentification n'est requise au sens strict pour exploiter le défaut : il suffit d'avoir un compte utilisateur ordinaire sur le catalogue Polaris, ou d'exploiter une faille d'authentification distincte, pour déclencher la séquence vulnérable. Sur les déploiements multi-tenants — par exemple les plateformes data-as-a-service exposant Polaris à des clients externes — la situation est encore plus critique : un tenant légitime peut s'évader vers les données d'un autre tenant.

Apache Polaris est l'un des projets data les plus en vue de 2025-2026, soutenu par Snowflake, qui en a fait le composant de référence pour l'interopérabilité Iceberg. Son adoption a été rapide : Databricks, Cloudera, Dremio et plusieurs hyperscalers ont annoncé une compatibilité Polaris dans leurs distributions. La conséquence directe est que la fenêtre d'exposition est étendue à un grand nombre d'acteurs ayant déployé Polaris en production ces six derniers mois.

Plusieurs CVE additionnels ont été publiés en grappe le même 4 mai 2026 sur Polaris : CVE-2026-42810 (S3 policy bypass via wildcard table names), CVE-2026-42812 (metadata write bypass via credential vending) et un avis distinct sur le scope GCS. Cette accumulation suggère un audit de sécurité approfondi du projet, vraisemblablement piloté par Apache ou un sponsor industriel, dont les résultats sont divulgués de manière coordonnée. Les administrateurs Polaris doivent traiter l'ensemble de cette série comme un seul incident critique.

Impact et exposition

Sont exposées toutes les organisations utilisant Apache Polaris en production avec credential vending activé, ce qui constitue le mode de déploiement standard. Les versions antérieures à la mise à jour de sécurité publiée par Apache (à vérifier sur la advisory officielle Apache Security) sont vulnérables. Les déploiements particulièrement à risque sont ceux où Polaris est exposé à des utilisateurs internes nombreux ou à des partenaires externes via une API gateway.

L'exploitation ne nécessite ni outillage sophistiqué ni vulnérabilité supplémentaire : un simple appel API REST forgé contre l'endpoint de stage create, avec un payload location pointant vers un préfixe S3 cible, suffit à obtenir les credentials. Tout client capable d'invoquer l'API Polaris est donc un vecteur potentiel. L'absence de PoC public au moment de la publication ne doit pas rassurer : la simplicité du défaut garantit qu'un exploit fonctionnel apparaîtra rapidement.

L'impact business est sévère : exfiltration totale des données du data lake, modification ou suppression d'objets, contournement des dispositifs DLP basés sur les permissions IAM. Pour les organisations soumises au RGPD, à HIPAA ou à PCI-DSS, une exploitation réussie constitue de facto une violation de données à notifier, avec des conséquences réglementaires importantes. Les data lakes hébergeant des PII de grande échelle sont des cibles prioritaires pour les groupes de ransomware double-extorsion.

Au moment de la publication, aucune exploitation in-the-wild confirmée n'est documentée. Néanmoins, plusieurs équipes de threat intelligence (Wiz, Datadog Security Labs, Snyk) suivent activement le sujet, et la nature attractive de la cible — accès direct aux entrepôts de données analytiques — laisse présager une exploitation rapide par les acteurs spécialisés dans le vol de données.

Recommandations immédiates

• Vérifier la version d'Apache Polaris déployée et planifier l'application du correctif officiel publié par Apache Software Foundation Security dès disponibilité.
• En attendant le correctif, désactiver le credential vending si l'architecture le permet, ou restreindre l'API stage create aux utilisateurs administrateurs uniquement.
• Réviser les permissions IAM du rôle backend utilisé par Polaris : appliquer le principe du moindre privilège en cantonnant le rôle à un préfixe S3 strictement délimité par tenant.
• Activer la journalisation détaillée des appels API Polaris (audit log) et exporter vers SIEM pour détection rétroactive.
• Auditer les CloudTrail logs AWS / Cloud Logging GCP pour identifier toute requête STS:AssumeRole inhabituelle issue du rôle Polaris dans les 30 derniers jours.
• Traiter en parallèle les CVE-2026-42810, CVE-2026-42812 et l'avis sur le scope GCS publiés simultanément, qui forment un même incident.