Spring for GraphQL : RCE et CSWSH dans l'avis CERTFR-2026-AVI-0759

Le CERT-FR a publié le 16 juin 2026 l'avis CERTFR-2026-AVI-0759 qui amplifie les bulletins de sécurité de l'équipe Spring du 10 juin. Quatre identifiants sont concernés : CVE-2026-41001 côté Spring Boot, CVE-2026-41699, CVE-2026-41700 et CVE-2026-41856 côté Spring for GraphQL. La combinaison va de l'exécution de code à distance par désérialisation de curseur de pagination jusqu'au contournement silencieux d'annotations de sécurité — sur deux composants présents par défaut dans une grande partie du parc Spring francophone.

Ce que les failles permettent

CVE-2026-41699 — RCE par désérialisation de curseur GraphQL. Les applications Spring for GraphQL qui exposent un champ paginé de type Connection désérialisent les curseurs de pagination reçus dans la requête sans contrainte sur le type cible. Si le classpath de l'application contient une classe qui exécute du code lors de l'instanciation ou de la désérialisation (le motif classique « gadget » Java), une requête GraphQL forgée déclenche l'exécution de code arbitraire dans le processus.

CVE-2026-41700 — Cross-Site WebSocket Hijacking. Le handshake du transport WebSocket GraphQL ne valide pas l'en-tête Origin. Une application qui active le transport WebSocket, authentifie via cookie de session et n'a pas posé de contrôle d'Origin au niveau Spring Security WebSocket est exploitable : un attaquant qui amène un utilisateur authentifié sur une page malveillante exécute n'importe quelle opération GraphQL avec ses cookies.

CVE-2026-41856 — annotations de sécurité ignorées. Le mécanisme de détection des annotations sur les méthodes de @Controller data fetchers ne résout pas correctement les annotations héritées au travers des hiérarchies de types. Conséquence directe : une décision d'autorisation portée par une annotation héritée peut être ignorée silencieusement à l'exécution, laissant passer des appels qui auraient dû être bloqués.

CVE-2026-41001 — répertoire temporaire Artemis prédictible (Spring Boot). L'auto-configuration ArtemisEmbeddedConfigurationFactory dérive le répertoire de données du broker embarqué d'Artemis à partir du répertoire temporaire système concaténé à un sous-dossier fixe artemis-data. Le chemin est entièrement prévisible. Un attaquant local sur le même hôte pré-crée ce répertoire (ou y dépose un lien symbolique vers un emplacement sensible) avant le démarrage de l'application. Quand le broker démarre, il écrit son journal et ses bindings dans la cible contrôlée par l'attaquant — d'où injection ou altération de messages, et chaînage possible avec des vulnérabilités de désérialisation déjà connues côté Artemis.

Produits et versions affectés

Périmètre exact côté éditeur, repris par le CERT-FR :

• Spring Boot OSS : 2.7.x < 2.7.34, 3.3.x < 3.3.20, 3.4.x < 3.4.17, 3.5.x à patcher selon la note Spring, 4.0.x < 4.0.7. Versions Enterprise correspondantes incluses.
• Spring for GraphQL : 1.0.x à 2.0.x. Corrigé dans 1.4.6 et 2.0.4, livrés par le billet de l'équipe Spring du 10 juin 2026.

Statut d'exploitation

• Pas d'exploitation observée dans la nature au moment de la publication des bulletins éditeur. CERT-FR ne signale pas non plus d'activité opportuniste.
• CVE-2026-41699 et CVE-2026-41700 sont les deux primitives qui se mass-scanneront en premier : la première donne une RCE pré-authentification dès qu'un gadget de désérialisation existe dans le classpath, la seconde se vérifie par une simple requête Origin: evil.example sur l'endpoint WebSocket. Aucune des deux ne nécessite d'authentification valide pour le déclenchement initial.
• Conditions d'exploitation pour CVE-2026-41001 : accès local au même hôte que le processus Spring Boot avant son démarrage. Cas typique : conteneur partagé avec un service tiers ou hôte multi-tenant.

Que faire

1. Inventorier les services Spring exposés en interne et en externe. Tout backend qui sert du GraphQL via Spring (spring-graphql ou spring-boot-starter-graphql) est dans le périmètre des trois CVE GraphQL ; toute application Spring Boot qui s'appuie sur l'auto-configuration d'Artemis embarqué est dans le périmètre de CVE-2026-41001.
2. Mettre à jour Spring for GraphQL en 1.4.6 ou 2.0.4 sur tous les services exposant un champ paginé Connection ou un transport WebSocket. C'est la seule remédiation pour CVE-2026-41699 et CVE-2026-41700.
3. Mettre à jour Spring Boot sur la branche maintenue de votre application (2.7.34, 3.3.20, 3.4.17, ou 4.0.7 selon la trajectoire). Le correctif Artemis est intégré dans ces versions.
4. À défaut de patch immédiat sur GraphQL : désactiver le transport WebSocket s'il n'est pas utilisé, et imposer un contrôle d'Origin au niveau Spring Security WebSocket. Pour la désérialisation de curseur, restreindre les champs Connection exposés et auditer le classpath à la recherche de gadgets connus (commons-collections etc.).
5. Auditer les annotations de sécurité héritées sur vos data fetchers @Controller. Tant que le patch n'est pas appliqué, considérer comme non protégés les fetchers qui s'appuient uniquement sur une annotation déclarée sur une classe parente ou une interface.
6. Sur les hôtes mutualisés, vérifier les permissions et la propriété de ${java.io.tmpdir}/artemis-data avant chaque démarrage d'une application Spring Boot avec Artemis embarqué — ou imposer un chemin explicite via spring.artemis.embedded.data-directory.

Contexte

L'écosystème Spring concentre une part importante des backends Java en production en France — banques, opérateurs, ministères, éditeurs SaaS. Un avis CERT-FR qui touche simultanément Spring Boot et Spring for GraphQL avec une RCE et un CSWSH dans le même paquet est donc plus large qu'il n'y paraît : il s'agit de deux dépendances qu'on rencontre dans le même service sur plusieurs équipes à la fois. La fenêtre entre la publication des bulletins éditeur le 10 juin et l'amplification CERT-FR le 16 a déjà laissé six jours de visibilité publique aux primitives — assez pour qu'une recherche de gadgets ait commencé côté offensif.

Les équipes qui n'ont pas de chaîne de mise à jour automatisée sur leurs starters Spring sont dans la situation classique : la RCE arrive avec la version mineure, et la dette technique sur la version cible décide du délai de patch. Le travail de cette semaine n'est pas l'analyse de la faille — c'est la cartographie : où tourne Spring for GraphQL chez vous, et qui en porte la mise à jour.