Faille Ceph - CVE-2026-54330 - sécuriser les accès S3 par URL présignée

La faille Ceph CVE-2026-54330 fait l’objet de correctifs Ubuntu publiés le 5 octobre 2026. Elle touche Ceph Object Gateway, ou RGW, la passerelle qui expose le stockage objet en S3. Un détenteur d’une URL présignée peut obtenir davantage de droits que ceux prévus lors de sa création. Bulletin Ubuntu USN-8867-1.

La vulnérabilité est publique depuis le 19 août : l’actualité est la disponibilité des correctifs Ubuntu, pas une nouvelle découverte. Historique des avis Ceph.

Pour les entreprises qui hébergent des documents, des médias ou des fichiers applicatifs sur leur propre stockage S3, l’enjeu est concret : maîtriser l’infrastructure suppose aussi de maintenir le service qui autorise les accès aux données.

Une URL présignée ne doit pas devenir un accès plus large

Une URL S3 présignée permet à une application de déléguer une opération, par exemple l’envoi d’un fichier, sans transmettre ses identifiants de stockage à l’utilisateur. La signature doit encadrer ce qui est autorisé.

Le défaut se situe dans cette vérification. RGW contrôle les en-têtes déclarés dans X-Amz-SignedHeaders, mais accepte aussi certains en-têtes x-amz-* supplémentaires, absents de la signature. Une personne disposant d’une URL présignée PUT peut ainsi modifier le comportement de la requête au-delà de l’intention du signataire.

Red Hat décrit un risque d’accès et de modification non autorisés d’objets S3, et attribue à la faille un score CVSS de 8,2/10. L’exploitation exige une URL présignée : ce n’est pas un accès anonyme universel à tous les clusters Ceph. Analyse de CVE-2026-54330 par Red Hat.

Notre lecture opérationnelle : il faut examiner ensemble la passerelle, les URL distribuées et les permissions du compte qui les signe. Une autorisation pensée pour un dépôt de fichier doit rester limitée à cette opération.

RGW, RBD, CephFS : identifier le bon périmètre

Ceph propose plusieurs interfaces au-dessus de son stockage distribué. Elles ne présentent pas toutes la même surface d’accès. Architecture officielle Ceph.

Usage	Interface	Rapport avec cette faille
Stockage objet accessible en S3	RGW	Composant visé par l’avis SigV4
Disques de machines virtuelles	RBD	Ne suffit pas à établir l’exposition RGW
Système de fichiers partagé	CephFS	Interface distincte de la passerelle S3

Un cluster Proxmox qui utilise Ceph pour les disques de ses VM n’est donc pas, à lui seul, la preuve d’une exposition à CVE-2026-54330. Il faut rechercher les passerelles RGW, leur version et les applications qui produisent ou utilisent des URL présignées.

Nous commencerions par recenser les points d’entrée S3 : accès publics ou privés, reverse proxies, équilibreurs de charge, passerelles sur plusieurs sites et services conteneurisés. Une passerelle interne mérite aussi cette vérification si ses clients peuvent lui transmettre des requêtes.

Cette démarche rejoint la cartographie des dépendances avant une reprise d’infogérance : savoir quel service donne accès à quelles données, avec quelles responsabilités.

Quels correctifs Ubuntu sont disponibles ?

Le bulletin USN-8867-1 fournit les révisions suivantes pour radosgw et librgw2 :

Version Ubuntu	Révision corrigée
26.04 LTS	20.2.0-0ubuntu2.1
22.04 LTS	17.2.9-0ubuntu0.22.04.4
20.04 LTS, avec Ubuntu Pro	15.2.17-0ubuntu0.20.04.6+esm2
18.04 LTS, avec Ubuntu Pro	12.2.13-0ubuntu0.18.04.11+esm3

Source : paquets corrigés publiés par Canonical.

Il faut comparer la révision complète du paquet, pas seulement son numéro amont. Sur une installation gérée par les dépôts Ubuntu, ces commandes permettent de relever l’existant :

dpkg-query -W -f='${Package} ${Version}\n' radosgw librgw2
apt-cache policy radosgw librgw2

Ce tableau ne s’applique pas automatiquement aux paquets Proxmox, aux dépôts Ceph tiers ou aux images de conteneurs. La documentation Ceph indique aussi des correctifs amont dans Tentacle 20.2.4 et Squid 19.2.6, puis leurs versions ultérieures. Avis de sécurité Ceph.

Ne pas trouver son système dans ce bulletin Ubuntu ne permet pas de conclure qu’il est protégé. Il faut consulter l’avis correspondant à la source réelle du logiciel.

Maintenir les passerelles sans oublier les applications

Notre procédure commencerait par un inventaire des instances RGW et des versions effectivement exécutées. Mettre à jour l’hôte ne corrige pas une image de conteneur qui embarque encore l’ancien composant.

Nous préparerions ensuite la maintenance autour de quatre points :

1. L’état du service. Contrôler la santé du stockage et, le cas échéant, la réplication entre sites avant d’intervenir.
2. La continuité d’accès. Vérifier le routage vers les passerelles disponibles et les conditions d’une intervention successive. Plusieurs instances ne garantissent pas, à elles seules, une bascule transparente.
3. Le déploiement du correctif. Utiliser la procédure adaptée aux paquets ou à l’orchestrateur, puis renouveler les processus qui exécutent l’ancien code.
4. La recette applicative. Tester les opérations réellement utilisées, dont les URL présignées, et confirmer le maintien des restrictions d’accès.

En multisite, la compatibilité pendant la transition compte

Ceph signale que le durcissement SigV4 affecte aussi des requêtes générées par son client multisite. Son avis prévoit une transition avec l’option rgw_sigv4_insecure, puis sa désactivation une fois tous les clusters mis à jour. Consignes multisite de l’avis Ceph.

Cette option n’est pas un correctif de sécurité ni un réglage à conserver. Pour les versions et déploiements concernés, nous intégrerions cette transition à une procédure précise, avec une vérification finale du retour à la validation stricte. Elle ne doit pas être appliquée mécaniquement à un paquet disposant de rétroportages différents.

L’objectif est de traiter la faille sans découvrir pendant l’intervention qu’une dépendance de réplication a été oubliée.

Un stockage disponible n’est pas forcément un accès maîtrisé

Après la maintenance, nous vérifierions les parcours applicatifs avec des droits représentatifs : envoi et lecture de fichiers, refus des opérations non autorisées, comportement des clients S3 et stabilité des échanges entre sites.

Le suivi doit associer erreurs de signature, réponses HTTP, latence et état de la réplication. C’est le même principe que pour la supervision d’une infrastructure saine : contrôler le service rendu, pas seulement la présence d’un processus.

Le correctif ferme le défaut ; il ne prouve pas qu’aucun accès abusif n’a eu lieu auparavant. Selon l’exposition identifiée, nous examinerions les journaux disponibles, les changements de permissions et les opérations sur les objets sensibles. Une absence de trace n’est pas une preuve si la journalisation ne couvrait pas ces événements.

L’infogérance relie le bulletin de sécurité au stockage réel

La redondance protège contre certaines pannes. Elle ne remplace ni le contrôle des autorisations ni la maintenance des services qui donnent accès aux données.

Chez Forget About IT, notre approche de l’infogérance de serveurs Linux relie la veille de sécurité à l’inventaire, à la préparation des changements et aux contrôles après intervention. Sur Ceph, cela implique de connaître les usages du cluster, ses passerelles et ses dépendances applicatives.

Le bon résultat n’est pas seulement un paquet installé : c’est un accès aux données corrigé, testé et documenté. Vous souhaitez faire le point sur la maintenance de votre environnement Ceph ? Échangeons sur votre infrastructure.

FAQ - faille Ceph et accès S3

Que permet la faille Ceph CVE-2026-54330 ?

Elle concerne la vérification des signatures SigV4 dans Ceph Object Gateway. Un détenteur d’une URL présignée PUT peut ajouter des en-têtes non signés et dépasser les autorisations prévues par le signataire.

Tous les clusters Proxmox utilisant Ceph sont-ils concernés ?

Le bulletin vise la passerelle objet RGW et les requêtes S3, pas les accès bloc RBD des machines virtuelles. Un cluster utilisant Ceph pour ses VM ne suffit donc pas à établir l’exposition à cette faille.

Une version Ceph amont ancienne peut-elle être corrigée sur Ubuntu ?

Oui. Les distributions peuvent intégrer un correctif sans changer de version majeure. Il faut comparer la révision complète du paquet au bulletin applicable et vérifier l’origine des paquets réellement déployés.