ServiceNow : faille API non authentifiée expose des données clients

Une API mal configurée ouvre la porte aux données de milliers d'entreprises

ServiceNow, l'éditeur américain de la plateforme ITSM (Information Technology Service Management) utilisée par plus de 8 000 organisations dans le monde, a divulgué début juin 2026 un incident de sécurité aux implications significatives pour ses clients entreprise. La vulnérabilité concernée réside dans un endpoint d'API interne, précisément le chemin /api/now/related_list_edit/create, qui avait été configuré avec le paramètre requires_authentication défini à false. Cette configuration erronée permettait à toute requête HTTP non authentifiée d'interroger, dans certaines circonstances, les tables de données internes d'instances ServiceNow appartenant à des clients.

D'après le rapport de BleepingComputer et l'analyse de SOCRadar, l'exploitation active de cette faille a débuté le 2 juin 2026 et s'est poursuivie jusqu'au 3 juin, date à laquelle ServiceNow a détecté une activité anormale dans ses journaux. Le correctif a été déployé le 5 juin 2026, soit trois jours après le début des attaques confirmées. L'éditeur a simultanément notifié les clients affectés via des tickets de support individuels — une approche discrète qui a suscité des critiques de la communauté de la sécurité. L'avis de sécurité lui-même n'a été rendu accessible qu'aux clients disposant d'un accès au portail de support ServiceNow, laissant de nombreux professionnels de la sécurité sans visibilité pendant quatre jours supplémentaires.

La chronologie de la divulgation soulève des questions légitimes sur les pratiques de communication de crise de ServiceNow. Un rapport de bug bounty décrivant une vulnérabilité similaire avait été soumis à l'éditeur dès le 22 avril 2026, soit plus de six semaines avant le début de l'exploitation. ServiceNow n'a pas appliqué de correctif avant que des attaques actives ne soient détectées. Ce délai de réponse, documenté par The Hacker News et Rescana, pose la question de l'efficacité des processus de triage des rapports de vulnérabilité chez un éditeur dont la plateforme héberge des données opérationnelles critiques pour des milliers d'entreprises mondiales.

Sur le plan technique, la faille est d'une nature particulièrement insidieuse. ServiceNow repose sur une architecture multi-tenant dans laquelle chaque client dispose d'une instance isolée — en théorie. La configuration incorrecte du paramètre d'authentification sur cet endpoint spécifique créait une exception à ce modèle d'isolation, permettant à un attaquant non authentifié de formuler des requêtes structurées contre des tables de données appartenant à des instances tierces. Les tables interrogeables via cette route incluent potentiellement des données d'incidents IT, de configurations de services, d'actifs matériels et logiciels, et de workflows internes — des informations sensibles pour toute organisation utilisant ServiceNow comme système nerveux de ses opérations IT.

L'impact déclaré par ServiceNow a été qualifié de « limité ». L'éditeur indique que l'incident a principalement affecté les clients sur la release de plateforme dite « Australia », ainsi que certains clients sur des releases plus anciennes ayant effectué des modifications de configuration spécifiques. Pour un sous-ensemble de ces clients, ServiceNow a confirmé avoir observé des preuves de requêtes réussies contre des tables d'instances. La société a précisé ne pas avoir observé d'exfiltration massive de données ni de déplacement latéral au-delà des requêtes API ciblées. Néanmoins, la nature exacte des données consultées n'a pas été rendue publique, et les clients affectés ont été invités à consulter leurs journaux d'accès pour évaluer l'étendue de l'exposition sur leurs propres instances.

Aucun identifiant CVE n'avait été assigné à cette vulnérabilité au moment de la publication de cet article. ServiceNow a indiqué évaluer si la divulgation publique d'un CVE est applicable selon ses politiques internes — une position qui a été critiquée par plusieurs chercheurs en sécurité. En l'absence d'identifiant standardisé, la corrélation avec des règles de détection SIEM ou des flux de threat intelligence est rendue plus difficile, ce qui allonge mécaniquement le délai de réponse pour les équipes SOC qui s'appuient sur ces outils pour prioriser les actions de remédiation.

La plateforme ServiceNow est utilisée par des organisations dans des secteurs hautement sensibles : gouvernements, services de santé, institutions financières, opérateurs d'infrastructures critiques. Une compromission de données au niveau ITSM représente un risque opérationnel et stratégique majeur, car ces systèmes centralisent la gestion des incidents de sécurité, des changements de configuration, des accès aux systèmes critiques et des inventaires d'actifs IT. Un attaquant ayant accès à ces données dispose d'une cartographie détaillée de l'environnement IT de sa victime, facilitant la planification d'attaques ultérieures plus ciblées et plus efficaces.

D'après Cybernews, une partie de l'activité détectée en lien avec cet incident aurait pu être attribuée à des chercheurs en sécurité effectuant des tests après avoir découvert la faille de manière indépendante — ce qui n'exclut pas la possibilité que des acteurs malveillants aient également exploité l'endpoint pendant la fenêtre d'exposition. ServiceNow n'a pas communiqué sur l'attribution de l'activité malveillante détectée ni sur l'identité des acteurs impliqués.

La sécurité des plateformes SaaS critiques : un défi de gouvernance autant que technique

L'incident ServiceNow illustre une problématique structurelle de la sécurité des plateformes SaaS d'entreprise. Lorsqu'une organisation délègue la gestion de ses données opérationnelles à un éditeur tiers, elle transfère une partie du contrôle sur la sécurité de ces données à ce tiers, tout en conservant l'entière responsabilité réglementaire et légale en cas d'incident. Ce modèle de responsabilité partagée est bien documenté dans le cloud computing, mais ses implications concrètes sont souvent mal comprises par les équipes de gouvernance IT et sécurité.

La pratique de retenir un avis de sécurité derrière un portail client pendant plusieurs jours — même si elle répond à une logique commerciale de protection des clients payants — entre en tension avec les principes de divulgation responsable qui prescrivent une information rapide et accessible de l'ensemble des parties affectées. Plusieurs éditeurs SaaS majeurs ont été confrontés à des critiques similaires ces dernières années, notamment dans le contexte d'incidents impliquant Salesforce, Atlassian et d'autres acteurs du marché des plateformes d'entreprise. La communauté de la sécurité plaide pour une évolution vers des communications de crise plus transparentes et plus rapides, indépendamment du niveau de support des clients.

Pour les équipes sécurité des organisations utilisant ServiceNow, cet incident rappelle l'importance de ne pas déléguer entièrement la surveillance de la sécurité à l'éditeur. La mise en place d'une journalisation active des accès API, la définition d'alertes sur les volumes de requêtes anormaux, et l'abonnement aux canaux de notification de sécurité de ServiceNow (notamment le portail HI et les listes de diffusion dédiées) constituent des prérequis de base. L'audit régulier des configurations d'authentification des endpoints API, en particulier après des mises à jour de plateforme, devrait être intégré aux processus de gestion des changements.

Sur le plan de la conformité réglementaire, les organisations affectées qui opèrent sous NIS2, DORA ou le RGPD doivent évaluer si cet incident déclenche des obligations de notification aux autorités compétentes. En Europe, le RGPD impose une notification à l'autorité de protection des données dans les 72 heures suivant la prise de connaissance d'une violation si celle-ci est susceptible d'engendrer un risque pour les droits et libertés des personnes concernées. La qualification précise de l'incident — données consultées versus données exfiltrées — est déterminante pour cette évaluation et doit faire l'objet d'une analyse juridique rigoureuse avant toute décision de notification.

Ce qu'il faut retenir

• Une API ServiceNow accessible sans authentification a exposé des données clients entre le 2 et le 5 juin 2026 ; le correctif est disponible, mais aucun CVE n'a encore été assigné.
• L'éditeur a retenu son avis de sécurité derrière un portail pendant 4 jours — une pratique contestée qui ralentit la réponse des équipes sécurité non abonnées au support premium.
• Les clients ServiceNow doivent vérifier leur version de plateforme, auditer leurs journaux d'accès API sur la période du 2 au 5 juin 2026, et activer des alertes sur les requêtes non authentifiées.