Le 27 août 2026, ServiceNow a publié un avis de sécurité couvrant quatre vulnérabilités dans sa plateforme. Trois d'entre elles atteignent le score maximal de 10.0 sur l'échelle CVSS. Pour les équipes de sécurité, c'est une alerte de premier ordre. Pour les équipes GRC, la situation est plus inconfortable encore : l'outil qu'elles utilisent pour documenter leur conformité et piloter leurs risques figure parmi les cibles.
Quatre failles, trois scores parfaits
ServiceNow a identifié et corrigé quatre CVE affectant son AI Platform. Les trois premières portent chacune un score CVSS 10.0, la note maximale de l'échelle. Le score reflète la combinaison d'une exploitabilité sans authentification, d'un impact total sur la confidentialité, l'intégrité et la disponibilité, et d'une surface d'attaque réseau accessible à distance.
CVE-2026-18885 : injection de code dans l'API GraphQL Composite Data. Un attaquant non authentifié peut exécuter du code arbitraire et accéder à l'ensemble des données de l'instance.
CVE-2026-18886 : contrôle d'accès défaillant dans le processeur d'upload de configuration. Un attaquant non authentifié peut créer ou modifier des données, ce qui lui permet d'escalader ses privilèges sur l'instance.
CVE-2026-74820 : injection SQL via la clause ORDER BY du schéma dynamique. Un attaquant non authentifié peut exécuter des requêtes SQL arbitraires contre la base de données sous-jacente.
La quatrième vulnérabilité, CVE-2026-6876, porte un score CVSS 4.0 de 8.7. Elle concerne le bac à sable de scripts de la Now Platform et permet une évasion menant à l'exécution de code.
Au 28 août 2026, ServiceNow n'avait observé aucune exploitation active de ces failles. Ce délai est bref : l'expérience des années précédentes montre que les vulnérabilités critiques sans authentification sont exploitées en production dans les jours suivant leur publication.
Pourquoi les équipes GRC sont directement concernées
ServiceNow est déployé dans plus de 85 % des entreprises du Fortune 500 (source : ServiceNow, rapport annuel 2026). Au-delà de l'ITSM, la plateforme héberge des modules de gestion des risques, d'audit interne, de conformité réglementaire, et de gestion des prestataires — précisément les périmètres que NIS2 et DORA exigent de documenter et de tenir à jour.
La conséquence pratique est directe. Un attaquant exploitant CVE-2026-18885 accède non seulement aux systèmes IT connectés, mais potentiellement à l'ensemble du registre des risques, aux preuves d'audit, aux rapports de conformité et aux accès fournisseurs stockés dans l'instance. Pour une entité soumise à NIS2, une compromission de cet outil peut déclencher simultanément une obligation de notification d'incident et une perte d'intégrité des preuves de conformité.
C'est le paradoxe des plateformes de gouvernance : centralisées pour gagner en efficacité, elles deviennent des actifs de haute valeur pour un attaquant. L'accès à une instance GRC donne une carte de l'architecture de sécurité d'une organisation, de ses lacunes documentées et de ses calendriers d'audit.
Ce que NIS2 attend de vous maintenant
L'article 21 de NIS2 impose aux entités essentielles et importantes de mettre en place des mesures techniques et organisationnelles de gestion des risques. La gestion des correctifs en fait explicitement partie. Un patch disponible pour une vulnérabilité CVSS 10.0 sur un système en production doit être appliqué sans délai, et ce délai doit être documenté.
Si votre instance ServiceNow est hébergée (cloud), les correctifs ont été déployés automatiquement par l'éditeur. Votre action se limite à vérifier que la mise à jour a bien été appliquée et à en conserver la preuve dans votre registre des risques.
Si votre instance est auto-hébergée, vous devez appliquer manuellement les correctifs pour votre version. Les versions concernées couvrent les branches Xanadu (avant Patch 11 Hot Fix 7a), Yokohama (avant Patch 12 Hot Fix 3b et Patch 13 Hot Fix 4) et Zurich. ServiceNow a mis à disposition les mises à jour le jour même de la divulgation.
Dans les deux cas, la question de la détection mérite attention. Avez-vous des journaux d'accès suffisants pour exclure une exploitation antérieure à la publication du 27 août ? Si l'instance a été exposée sur Internet sans contrôle d'accès réseau strict, une revue des logs des 30 derniers jours est prudente.
Trois actions prioritaires
Première action : déterminer immédiatement si votre instance est hébergée ou auto-hébergée, et confirmer que le correctif a été appliqué. Pour une instance auto-hébergée, appliquer le patch dans les 24 à 48 heures si ce n'est pas encore fait.
Deuxième action : évaluer si une exploitation aurait pu se produire avant le 27 août. Si votre analyse de risque conclut à une probabilité non nulle, et que des données à caractère personnel ou des informations sensibles sont hébergées dans l'instance, les obligations de notification RGPD (72 heures à la CNIL) et NIS2 (24 heures à l'ANSSI) s'appliquent. L'article RGPD et NIS2 : un incident, deux notifications détaille la coordination entre ces deux régimes.
Troisième action : tracer le correctif dans votre registre des risques. La preuve de correction est un élément d'audit. Un correctif appliqué mais non documenté ne compte pas lors d'un contrôle NIS2.
Le signal plus large
Cette divulgation illustre une tendance structurelle. Les plateformes SaaS d'entreprise — GRC, ITSM, ERP — concentrent des données critiques et deviennent des cibles de plus en plus attractives. La logique de l'attaquant est simple : compromettre une seule plateforme centrale offre plus de valeur que compromettre dix systèmes périphériques.
La réponse ne consiste pas à éviter les plateformes centralisées : leur apport en efficacité reste réel. Elle consiste à les traiter avec le même niveau de vigilance que n'importe quel système critique. Cela passe par une gestion active des mises à jour, une segmentation réseau qui limite l'exposition, et des revues régulières des accès — en particulier les comptes de service et les intégrations tierces, qui sont les vecteurs les plus souvent négligés dans ce type d'environnement.
La gestion des accès aux plateformes GRC est précisément l'un des points que les auditeurs NIS2 vérifient en priorité. L'article IAM et NIS2/DORA : le contrôle d'accès que votre audit signalera en premier détaille les exigences applicables.