CVE-2026-6875 : RCE pré-authentifiée sur ServiceNow AI Platform, exploitation active

Les faits

Le 18 juillet 2026, les chercheurs de Defused ont confirmé l'exploitation active en conditions réelles de CVE-2026-6875, une vulnérabilité critique de type sandbox escape menant à une exécution de code à distance (RCE) pré-authentifiée sur la plateforme ServiceNow AI (anciennement Now Platform). La faille avait été découverte et divulguée de manière responsable le 1er avril 2026 par les équipes de Searchlight Cyber. ServiceNow avait patché ses instances cloud hébergées dès avril 2026, mais le correctif pour les déploiements self-hosted n'a été mis à disposition que le 13 juillet 2026 — soit plus de trois mois après la divulgation initiale.

Ce délai de trois mois entre le patch cloud et le patch self-hosted a créé une fenêtre d'exposition massive pour les organisations hébergeant ServiceNow dans leurs propres infrastructures. Le 20 juillet 2026, deux jours seulement après la confirmation d'exploitation active, une seconde chaîne d'exploitation alternative a été observée dans la nature. Cette chaîne contourne spécifiquement les défenses et règles de détection construites autour du PoC public original, complexifiant considérablement la détection et la réponse à incident pour les équipes SOC.

Techniquement, la vulnérabilité réside dans un endpoint pré-authentifié : /assessment_thanks.do. Un attaquant non authentifié peut envoyer une requête spécialement forgée à cet endpoint pour s'échapper du sandbox d'exécution de ServiceNow et obtenir une exécution de code arbitraire au niveau du serveur sous-jacent. Aucune interaction utilisateur n'est requise, aucun phishing n'est nécessaire — la surface d'attaque se résume à la simple accessibilité réseau de l'instance ServiceNow.

Le score CVSS de 9.5 reflète la combinaison d'une accessibilité sans authentification, d'un impact intégrité/confidentialité/disponibilité maximal et de la présence d'un PoC public fonctionnel. ServiceNow est l'une des plateformes ITSM et de gestion des workflows les plus déployées dans le monde, avec une présence significative dans les entreprises du Fortune 500, les opérateurs d'infrastructure critique et les organisations du secteur public. Le profil typique d'une instance ServiceNow inclut des intégrations profondes avec Active Directory, les systèmes RH, les outils de ticketing et de change management — ce qui en fait une cible de haute valeur pour un attaquant cherchant à pivoter dans le SI.

La chronologie complète est la suivante : divulgation coordonnée le 1er avril 2026 par Searchlight Cyber, patch des instances cloud hébergées par ServiceNow en avril 2026, publication d'un PoC public entre avril et juillet 2026, mise à disposition du patch self-hosted le 13 juillet 2026, confirmation d'exploitation active le 18 juillet 2026 par les chercheurs de Defused, découverte d'une seconde chaîne d'exploitation contournant les défenses connues le 20 juillet 2026.

À ce stade, aucun groupe de menace spécifique n'a été formellement attribué aux attaques en cours. Les victimes confirmées n'ont pas été divulguées publiquement. Compte tenu du profil des organisations utilisant ServiceNow et de l'existence d'un PoC public depuis plusieurs mois, le risque de compromission pour les instances self-hosted non patchées doit être considéré comme maximal. Les Fortune 500, les administrations publiques et les opérateurs d'infrastructures critiques constituent les cibles les plus attractives pour des acteurs malveillants cherchant des accès réseau et des données de haute valeur.

Cette situation illustre un problème récurrent dans l'industrie : la disparité de traitement entre les instances SaaS hébergées par le vendor et les déploiements on-premises. Les organisations qui choisissent l'auto-hébergement pour des raisons de contrôle, de conformité ou de souveraineté des données se retrouvent systématiquement désavantagées en matière de délais de patch. Dans ce cas précis, le délai de 90 jours entre les deux patches a constitué une opportunité d'exploitation qui a été saisie par des attaquants disposant d'un PoC public. Cette asymétrie devrait être documentée dans l'analyse de risque fournisseur de chaque organisation concernée.

En parallèle, la présence d'une seconde chaîne d'exploitation non documentée révèle que le PoC public n'était pas la seule route d'attaque exploitable. Des chercheurs en sécurité offensive ont identifié indépendamment d'autres gadgets dans le code ServiceNow permettant d'atteindre le même résultat. Ce constat rappelle que les signatures de détection construites sur un seul PoC donnent un faux sentiment de sécurité : la mise à jour du patch reste la seule protection fiable.

Impact et exposition

Sont exposées toutes les instances ServiceNow AI Platform auto-hébergées n'ayant pas appliqué le patch du 13 juillet 2026. Les instances cloud ServiceNow hébergées par le vendor sont protégées depuis avril 2026. L'exploitation ne nécessite aucune authentification — la seule condition est l'accessibilité réseau de l'interface web ServiceNow. Les instances exposées directement sur Internet constituent la priorité absolue, mais les instances accessibles uniquement depuis un réseau interne restent exposées à une exploitation post-mouvement latéral. La présence d'un VPN ou d'une authentification forte sur d'autres couches ne protège pas si le port ServiceNow est accessible depuis un segment réseau compromis.

Recommandations

• Appliquer le patch de sécurité ServiceNow du 13 juillet 2026 immédiatement sur toutes les instances self-hosted — priorité absolue sans exception
• Auditer les logs d'accès pour identifier des requêtes anormales vers l'endpoint /assessment_thanks.do et toute création de processus inattendue sur les serveurs ServiceNow
• Vérifier et mettre à jour les règles de détection : les signatures construites autour du premier PoC ne couvrent pas la seconde chaîne d'exploitation identifiée le 20 juillet 2026
• Revoir les comptes de service et tokens API ServiceNow : ils doivent être considérés comme potentiellement compromis si l'instance était accessible pendant la fenêtre d'exposition avril–juillet 2026
• En cas de suspicion de compromission : déclencher immédiatement une réponse à incident complète, isoler l'instance, auditer les connexions sortantes et les modifications de configuration récentes