CVE-2026-42354 : prise de compte Sentry via SAML SSO (9.1)

Les faits

Sentry, plateforme open-source de monitoring d'erreurs et de performance utilisée par plus de 100 000 organisations dont une grande partie du Fortune 500, a publié le 8 mai 2026 une advisory critique référencée GHSA-ggmg-cqg6-j45g et indexée comme CVE-2026-42354. Le score CVSS v3.1 atteint 9.1 (Critical), avec un vecteur AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Le périmètre couvre toutes les versions self-hosted depuis 21.12.0 jusqu'à 26.4.1 exclu, soit plus de quatre ans de releases.

La faille réside dans le processus d'authentification SAML SSO de Sentry, plus précisément dans la logique de liaison entre une assertion SAML reçue et un compte utilisateur interne. Sentry identifie l'utilisateur cible via l'adresse e-mail transmise dans l'assertion, sans vérifier que l'Identity Provider (IdP) émetteur est bien celui légitimement associé à l'organisation propriétaire du compte. Sur une instance hébergeant plusieurs organisations, configuration standard pour une grande entreprise multi-BU ou un fournisseur SaaS qui mutualise Sentry, un attaquant disposant du contrôle de sa propre organisation peut configurer un IdP SAML malveillant, forger une assertion contenant l'adresse e-mail d'un utilisateur cible appartenant à une autre organisation, et se voir reconnecté automatiquement comme cet utilisateur.

La chronologie révèle que la classe de bugs n'est pas inédite : CVE-2025-22146 (publiée en janvier 2025) et CVE-2026-27197 (février 2026) avaient déjà touché la même surface et avaient toutes deux été corrigées. CVE-2026-42354 marque la troisième itération du même motif d'erreur architecturale dans la liaison identité SAML, ce qui interroge sur la robustesse du correctif initial. Selon l'advisory du Centre pour la Cybersécurité Belgique (CCB) et le bulletin TheHackerWire publiés le 8 mai 2026, le pattern de défaut serait lié à un raccourci de matching e-mail réintroduit lors d'une refactorisation interne du module SSO en début 2026.

L'exploitation requiert deux préconditions raisonnables côté attaquant : disposer d'une organisation valide sur l'instance Sentry cible (gratuit pour Sentry SaaS, accessible via simple inscription self-service sur la majorité des déploiements self-hosted ouverts à des partenaires), et connaître l'adresse e-mail de la victime, typiquement une adresse professionnelle exposée publiquement (LinkedIn, GitHub commits, signatures e-mail, base data brokers). Aucune compromission préalable du poste de la victime, aucun phishing, aucune interaction n'est nécessaire.

Une fois l'attaque réussie, l'attaquant obtient l'intégralité des privilèges du compte cible. Pour un compte développeur lambda, cela signifie un accès en lecture aux exceptions et stack traces capturées par Sentry, qui contiennent fréquemment des données sensibles : tokens API leakés en environnement, fragments de payloads utilisateurs, identifiants de session, noms de fichiers internes, voire credentials hardcodés. Pour un compte administrateur d'organisation, l'attaquant peut modifier les intégrations (GitHub, Slack, Jira, PagerDuty), exfiltrer les DSN, ou pivoter vers le code source via les intégrations CI/CD configurées.

Sentry SaaS a été patché côté serveur sans action requise des clients, conformément à la pratique habituelle de l'éditeur. Pour le self-hosted, qui représente une part significative des déploiements en environnements régulés (santé, défense, finance, secteur public européen pour souveraineté des données), la version corrective est 26.4.1, publiée simultanément à l'advisory. Les versions intermédiaires de la branche 26 antérieures à 26.4.1, ainsi que toutes les versions des branches 21 à 25, doivent être mises à jour.

D'un point de vue détection, l'exploitation laisse des traces dans les logs d'authentification Sentry : une assertion SAML reçue depuis un IdP non associé à l'organisation propriétaire du compte cible est un signal fort. La table sentry_authprovider et les événements audit_log de type sso.identity_link méritent une revue rétroactive sur la fenêtre 21.12.0 vers patch, soit potentiellement plusieurs années pour les déploiements anciens.

Aucune exploitation in-the-wild n'a été confirmée publiquement à ce jour selon Sentry et le CCB belge, mais la simplicité d'exploitation, la valeur des données exposées (Sentry capte par essence des erreurs applicatives qui révèlent souvent l'architecture interne et des secrets), et la longévité de la fenêtre de vulnérabilité (4+ ans) en font une cible évidente pour les acteurs ciblant le supply chain logiciel et le cyber-espionnage.

Impact et exposition

Sont exposées toutes les instances Sentry self-hosted multi-organisations en versions 21.12.0 à 26.4.0 inclus. Une instance mono-organisation est techniquement non exploitable par un attaquant externe puisque la précondition contrôler une organisation sur la même instance n'est pas satisfaite ; toutefois, un utilisateur interne malveillant disposant d'un compte sur l'unique organisation reste un vecteur insider. Sentry SaaS (sentry.io) ne nécessite aucune action utilisateur, le correctif a été déployé côté plateforme.

L'industrie SaaS B2B et les ESN qui mutualisent une instance Sentry pour servir plusieurs clients sont particulièrement exposées : la frontière entre tenants repose justement sur le mécanisme défaillant. Les programmes bug bounty hébergés sur Sentry, les plateformes de développement open-source proposant Sentry à leurs contributeurs et les déploiements k8s avec self-service signup constituent des surfaces à risque élevé.

L'impact post-compromission est aggravé par la nature même de Sentry : un attaquant ayant pris le compte d'un développeur d'une organisation sensible accède à l'historique complet des erreurs production, ce qui revient à une visibilité indirecte sur le code, l'infrastructure, et fréquemment des secrets exfiltrés via des stack traces. Les organisations soumises à RGPD, SecNumCloud, ou HDS doivent considérer une telle compromission comme un incident à signaler à la CNIL ou à l'ANSSI dans les 72 heures.

Recommandations immédiates

• Mettre à jour Sentry self-hosted vers 26.4.1 ou supérieur (advisory : GitHub Security Advisory GHSA-ggmg-cqg6-j45g du 8 mai 2026).
• Aucune action requise pour Sentry SaaS, le patch a été déployé côté plateforme.
• Mitigation immédiate si patch impossible sous 24 h : forcer le 2FA TOTP/WebAuthn pour tous les comptes administrateurs (l'attaque ne contourne pas le 2FA local).
• Désactiver temporairement les inscriptions self-service d'organisations sur les instances multi-tenant exposées à internet.
• Audit rétroactif des logs : extraire les événements audit_log de type sso.identity_link et user.identity sur la fenêtre 21.12.0 vers version actuelle, croiser avec la table sentry_authprovider pour identifier les liaisons SAML provenant d'IdP non associés à l'organisation du compte lié.
• Roter l'ensemble des secrets, tokens API et DSN potentiellement visibles depuis les comptes administrateurs si une compromission est suspectée.
• Pour les déploiements régulés (HDS, SecNumCloud, RGPD-sensitive) : déclencher la procédure d'évaluation d'incident et notifier la CNIL/ANSSI sous 72 h en cas de doute raisonnable sur une exploitation.