ServiceNow AI Platform : une évasion de bac à sable permet l'exécution de code non authentifiée

De quoi s’agit-il ?

Le 13 juillet 2026, ServiceNow a publié un avis de sécurité (KB3137947) pour une vulnérabilité critique dans sa plateforme d’IA — la couche qui exécute les fonctionnalités assistées par IA et le code qu’elles génèrent ou lancent au sein des environnements ServiceNow. La faille est décrite comme une évasion de bac à sable : dans certaines conditions, un attaquant peut s’échapper de l’environnement d’exécution restreint sur lequel repose la plateforme et exécuter du code directement sur l’instance. Ce qui la rend grave, c’est que l’exploitation, selon ServiceNow, ne nécessite aucune authentification, et qu’elle touche les déploiements hébergés par ServiceNow comme les déploiements auto-hébergés.

ServiceNow indique avoir déjà corrigé ses instances hébergées et livré des correctifs aux clients auto-hébergés et aux partenaires, et n’avoir connaissance d’aucune exploitation active à la date de l’avis. L’éditeur a délibérément gardé les détails techniques hors de l’avis afin de laisser aux clients le temps de corriger avant qu’un exploit fiable ne soit développé — une posture de divulgation responsable classique pour une faille critique non encore exploitée.

Comment ça marche

ServiceNow n’a pas publié la cause technique sous-jacente ; ce qui suit décrit donc la classe de vulnérabilité, pas un exploit fonctionnel. Les plateformes d’IA exécutent couramment du contenu non fiable ou généré par le modèle — expressions, scripts, appels d’outils — à l’intérieur d’un bac à sable censé limiter ce que ce code peut atteindre. Une évasion de bac à sable est tout bug qui permet au code situé à l’intérieur de cette frontière d’en sortir : une restriction manquante sur une surface d’API, un objet accessible depuis le bac à sable qui expose des fonctionnalités privilégiées, ou un chemin d’analyse ou d’évaluation qui exécute une entrée contrôlée par l’attaquant avec plus d’autorité que prévu.

Le point structurel important tient à la combinaison de deux propriétés. D’abord, la surface vulnérable est accessible sans identifiants, ce qui transforme « un utilisateur authentifié pourrait mal se comporter » en « quiconque a un accès réseau à l’instance le peut ». Ensuite, une évasion réussie place l’attaquant dans le contexte d’exécution de la plateforme elle-même, où — sur un système utilisé pour la gestion des services informatiques, l’automatisation des workflows et les opérations de sécurité — il pourrait perturber des processus, lire ou modifier des enregistrements, ou rebondir vers d’autres systèmes accessibles depuis l’instance.

Pourquoi c’est important

Les entreprises font transiter beaucoup de processus sensibles par ServiceNow, et les instances sont souvent exposées à de larges réseaux par conception. Une primitive d’exécution de code non authentifiée contre ce type de plateforme frôle le pire des scénarios : pas de phishing, pas de jeton volé, juste un accès réseau à une instance non corrigée. L’absence d’exploitation observée est une maigre consolation, car la divulgation publique d’une faille critique non authentifiée tend à accélérer la rétro-ingénierie — la fenêtre entre « le correctif est sorti » et « l’exploit existe » est souvent courte.

Plus largement, c’est le schéma à intégrer à mesure que les fonctionnalités d’IA se diffusent dans les plateformes d’entreprise : chaque nouvelle capacité « laisse l’IA exécuter ceci » embarque un nouveau bac à sable d’exécution, et ce bac à sable fait désormais partie de votre surface d’attaque. La sécurité de la fonctionnalité ne vaut que celle de la frontière qui l’entoure, et ces frontières sont récentes, complexes et bien moins éprouvées que les plateformes sur lesquelles elles sont greffées.

Défenses

L’action immédiate concrète est de corriger, mais les leçons durables sont architecturales.

• Appliquez le correctif par famille de version. ServiceNow a traité la faille sur ses trains supportés — pour les instances auto-hébergées, installez le correctif de votre famille (l’avis liste les versions corrigées, dont les niveaux de patch récents Zurich et Yokohama) plutôt que de supposer que les correctifs côté hébergé vous couvrent.
• Confirmez le statut hébergé ou auto-hébergé. Les clients hébergés doivent vérifier que la mise à jour a bien été appliquée ; les administrateurs auto-hébergés maîtrisent leur propre calendrier de correctifs et doivent traiter cela comme urgent, même sans signe d’activité.
• Réduisez l’exposition réseau. Les failles non authentifiées sont bien moins dangereuses quand l’instance n’est pas largement accessible. Placez ServiceNow derrière des restrictions réseau (VPN, liste d’autorisation d’IP, WAF) pour que « accès réseau » ne soit pas synonyme d’« Internet ».
• Traitez les bacs à sable d’exécution d’IA comme des frontières de confiance, pas comme des commodités. Toute plateforme qui exécute du code généré par un modèle ou fourni par l’utilisateur doit supposer que le bac à sable finira par être franchi : minimisez ce qu’il peut atteindre, refusez le réseau sortant par défaut, et limitez les identifiants de la plateforme au moindre privilège.
• Surveillez les abus post-correctif. Observez l’activité administrative, les intégrations inattendues, les changements inhabituels de workflow ou d’enregistrements, et les comportements d’API anormaux — les signaux qu’une évasion réussie produirait, même si le point d’entrée est désormais fermé.

Status

Élément	Valeur
Produit	ServiceNow AI Platform (hébergé et auto-hébergé)
Nature	Évasion de bac à sable → exécution de code non authentifiée
Divulgation	13 juillet 2026 (avis KB3137947)
Référence	CVE-2026-6875
Corrigé dans	Brazil EA/GA ; Australia Patch 2 ; Zurich Patch 7b/9 ; Yokohama Patch 12 HF1b/Patch 13
Exploitation	Aucune connue à la date de divulgation
Authentification requise	Non

Dates clés : 13 juillet 2026 — avis et correctif ServiceNow ; 14 juillet 2026 — couverture presse. ServiceNow n’a pas publié le détail de la cause racine, ce qui est cohérent avec une divulgation responsable avant exploitation.