ServiceNow-RCE : six vérifications avant le ticket

Une plateforme de tickets qui gère les processus d’incidents, de changements et RH constitue une surface d’attaque de haute valeur. CVE-2026-6875 est une faille de type Pre-Auth Sandbox-Escape au sein de la plateforme IA de ServiceNow. Les instances auto-hébergées ont une obligation immédiate de patch, tandis que les instances hébergées par ServiceNow doivent procéder à une vérification.

À consulter également : Modèles OpenAI et pipeline Hugging Face : les points à vérifier · Qu’est-ce que le SOAR ? Définition et limites

ServiceNow est profondément ancré dans les flux de travail d’incidents, de changements et RH de nombreuses entreprises. Une faille RCE non authentifiée représente bien plus qu’une simple vulnérabilité applicative : elle touche des données critiques et des systèmes connectés, y compris l’Active Directory et les API cloud. Cette analyse distingue les actions urgentes pour les instances auto-hébergées de celles à vérifier pour les clients hébergés.

Qu’est-ce que CVE-2026-6875 ? Il s’agit d’une faille de type Pre-Auth Sandbox-Escape au sein de la plateforme IA de ServiceNow. Searchlight Cyber a identifié la faille via l’endpoint assessment_thanks.do. Defused a ensuite signalé des charges utiles actives en conditions réelles. ServiceNow fournit des correctifs tout en minimisant l’impact potentiel sur ses instances hébergées.

1. Maintenir les correctifs et versions à jour par rapport à la KB3137947

ServiceNow a colmaté la faille pour les instances hébergées dès avril. Pour les versions auto-hébergées, le correctif de sécurité correspondant à la KB3137947 a été publié en juillet, avec des rapports indiquant son déploiement le 13.07.2026. Le premier contrôle strict consiste à comparer la version de l’instance avec celle de la KB.

Répondre simplement « Nous sommes dans le cloud » ne suffit pas. Les clients en hébergement externalisé exigent une preuve de l’état de santé du fournisseur ou de l’instance. Les utilisateurs en auto-hébergement doivent documenter la build après l’application de la KB.

2. Vérifier les vulnérabilités de pré-authentification et l’exposition Internet

Les équipes de recherche et de veille sur les menaces identifient le chemin de pré-authentification via l’endpoint assessment_thanks.do. Si l’URL est accessible depuis des réseaux non fiables, il est recommandé de prioriser les règles WAF, les journaux d’audit et, le cas échéant, une restriction temporaire jusqu’à l’application du correctif.

Une approche basée uniquement sur des signatures ne suffit pas. Defused a observé un autre gadget d’évasion de sandbox que celui décrit dans le PoC public. La télémétrie des endpoints et la détection d’anomalies sur le point d’entrée (sink) comptent davantage qu’un filtre statique.

3. Comptes d’accès et d’intégration comme vecteur d’attaque

Le code exécuté dans le contexte d’une plateforme hérite souvent des droits des utilisateurs d’intégration, des comptes proches des identités machines (MID) et des applications OAuth. L’inventaire de toutes les intégrations à privilèges élevés détermine ce qui serait accessible après une exécution de code à distance (RCE) réussie : annuaires Active Directory, contrôleurs cloud, systèmes RH ou pipelines CI/CD.

Cet inventaire ne prévient pas l’exploit. Il permet de déterminer quelles clés secrètes et relations de confiance sont considérées comme compromises en cas d’incident.

4. Journaux : Hits pré-authentification et activité script anormale

L’analyse commence par les requêtes inhabituelles sur les points d’accès d’évaluation et de pré-authentification. S’y ajoutent les chemins de scripts ayant abouti ou échoué. Les actions d’administration en dehors des fenêtres de changement connues doivent également être incluses dans le filtre.

La période couverte doit au minimum inclure la première fenêtre publique de recherche et de correctifs. L’absence de journaux d’application constitue en soi une découverte. Restent ensuite les journaux de la WAF, du reverse proxy et de l’identité, incomplets mais mieux que rien.

5. Fenêtre de changement et gel des tickets pour les instances auto-hébergées non corrigées

Les instances auto-hébergées non corrigées exposées à Internet doivent être placées en mode urgence. Les correctifs de sécurité (patchs) priment sur les déploiements de nouvelles fonctionnalités. Les mises à jour de plugins à risque ne sont pas déployées en parallèle. Une communication claire avec le responsable du service garantit le bon déroulement du processus.

Un gel sans plan de correctif est inefficace. Le changement nécessite un retour arrière (rollback), une mention sur l’instance de test ainsi que la preuve de l’application du correctif (KB).

6. Acteurs périphériques : serveurs MID, applications personnalisées et exportations de données

La plateforme n’est que rarement isolée. Les serveurs MID, les spokes du hub d’intégration et les applications personnalisées étendent les chemins d’exécution et de transfert des données. En cas de compromission confirmée ou suspectée, ces nœuds doivent être inclus dans le même périmètre d’incident que l’instance centrale.

Tous les scripts personnalisés ne constituent pas une voie d’exécution de code à distance (RCE) pour la CVE-2026-6875. Ce point aborde les compromissions en cascade et les fuites de données, et non la cause racine de la faille de la sandbox.

Priorités immédiates et actions différées

À faire immédiatement : Mettre à jour l’instance auto-hébergée vers la version KB3137947, clarifier l’exposition des *pre-auth sinks*, et lister les intégrations à privilèges élevés. En parallèle (hébergé par un tiers) : Vérifier le statut du correctif du fournisseur ainsi que la télémétrie de l’instance. Le fabricant n’a relevé aucune preuve d’activité observée sur les instances hébergées, mais recommande à tous ses clients d’appliquer le niveau de correctif actuel. Ensuite : Examiner les logs, procéder à la rotation des secrets sur les comptes d’intégration en cas de suspicion, et fournir une documentation justificative au RSSI. Si nécessaire, déclarer l’incident conformément à la directive NIS2.

Foire aux questions

Chaque question est verrouillée. Un clic déverrouille la réponse.

Le CVE-2026-6875 ne concerne-t-il que les solutions auto-hébergées ?

Les solutions auto-hébergées (self-hosted) présentent un risque opérationnel plus élevé, car c’est à l’exploitant qu’incombe la responsabilité de la mise à jour des correctifs. La version hébergée (hosted) a reçu les correctifs dès avril. Le fabricant recommande néanmoins à tous ses clients de se mettre à jour. Les clients en version hébergée doivent vérifier leur statut, tandis que ceux en auto-hébergement doivent appliquer les correctifs et mesurer leur exposition.

Que signifie exactement le terme « pré-authentification » dans ce contexte ?

Les attaquants n’ont pas besoin d’une session valide dans ServiceNow sur le système vulnérable. La complexité du gadget d’échappement peut être élevée. L’absence de nécessité de se connecter reste la différence décisive par rapport aux vulnérabilités administratives post-authentification.

Des règles WAF suffisent-elles à la place d’un correctif ?

Les WAF et les restrictions au niveau des terminaux sont des mesures immédiates judicieuses. Le correctif du fournisseur reste la solution définitive. Defused décrit un autre gadget que celui du PoC public ; une simple signature basée sur ce PoC est insuffisante.

ServiceNow a-t-il confirmé une exploitation active ?

Defused signale une activité in-the-wild. ServiceNow a indiqué à BleepingComputer n’avoir détecté aucune preuve de cette activité sur les instances hébergées par ses soins. Le fabricant rappelle en outre la disponibilité de mises à jour. Ces deux déclarations doivent être considérées conjointement.

Quel rôle jouent les intégrations après une exécution de code à distance (RCE) ?

Vous déterminez l’étendue de l’impact : provisionnement AD, API cloud, données RH et CMDB. En cas d’exploitation confirmée ou hautement probable, les comptes de service et les applications OAuth doivent être traités dans le même incident que la plateforme elle-même.

Les choix de la rédaction

À lireModèles OpenAI piratés sur Hugging Face : ce qui doit êtreÀ lireQu’est-ce que le SOAR ? Définition, playbooks et différenciationÀ lirePlugins CoreDNS : Cluster-DNS vulnérable sans authentification

Plus du réseau MBF Media

Digital ChiefsPourquoi la facture cloud ne diminue jamaiscloudmagazinAmende du DMA contre Google : 890 millions d’euros