ServiceNow : faille API expose des données clients sensibles

Ce qui s'est passé

ServiceNow, la plateforme de gestion des services informatiques (ITSM) utilisée par plus de 7 000 grandes entreprises et administrations à travers le monde, a officiellement reconnu le 9 juin 2026 avoir subi un incident de sécurité significatif. La divulgation, relayée en premier par BleepingComputer, révèle qu'une ressource d'API REST interne était accessible sans aucun mécanisme d'authentification, laissant les données clients exposées à quiconque connaissait l'URL de l'endpoint.

La faille est de nature architecturale : une Scripted REST Resource — un endpoint d'API personnalisé codé dans la plateforme — avait été configurée avec le paramètre requires_authentication défini sur false. Ce paramètre désactive toute vérification d'identité, ce qui signifie que l'endpoint /api/now/related_list_edit acceptait n'importe quelle requête HTTP entrante, sans jeton d'authentification, sans session active et sans aucun contrôle de credentials. Dans un contexte de sécurité zéro confiance (Zero Trust), il s'agit d'une erreur de configuration fondamentale qui ouvre la voie à une exploitation triviale.

La chronologie de l'incident est particulièrement préoccupante pour les entreprises concernées. Les premières activités malveillantes exploitant cet endpoint remontent à début avril 2026, selon les analyses post-incident de ServiceNow. Ce n'est que lors d'un pic d'activité suspecte observé les 2 et 3 juin 2026 que les équipes de sécurité de la société ont formellement identifié l'exploitation en cours. ServiceNow a déployé un correctif sur l'ensemble de ses instances hébergées le 5 juin 2026, soit trois jours après la détection du pic d'activité, mais plus de deux mois après les premières exploitations documentées.

L'adresse IP 51.159.98.241 a été formellement identifiée dans les logs de ServiceNow comme l'une des sources principales des requêtes malveillantes. La société conseille à tous ses administrateurs système d'effectuer une recherche dans les journaux d'accès pour identifier toute requête adressée à l'endpoint /api/now/related_list_edit en provenance de cette adresse ou de toute source externe non habituelle. Cet indicateur de compromission (IoC) constitue le premier élément technique publiquement communiqué dans le cadre de cet incident.

ServiceNow a précisé dans son avis de sécurité que les instances les plus susceptibles d'avoir été affectées sont celles opérant sur la version de plateforme dénommée "Australia release", ainsi que les instances sur des versions antérieures ayant fait l'objet de certaines modifications de configuration spécifiques. Pour les clients utilisant le mode SaaS entièrement hébergé et géré par ServiceNow, le correctif a été déployé automatiquement sans nécessité d'intervention. En revanche, les organisations disposant d'installations on-premise, de configurations hybrides ou d'extensions personnalisées doivent vérifier manuellement leur exposition et appliquer le patch dans les meilleurs délais.

La nature des données potentiellement exposées est d'une gravité considérable pour les entreprises victimes. Les instances ServiceNow stockent et traitent des tickets de support informatique contenant des détails précis sur les configurations des systèmes internes, des inventaires complets des assets technologiques, des enregistrements de ressources humaines incluant des données personnelles sensibles d'employés, des rapports d'incidents de sécurité internes documentant les failles et vulnérabilités connues, des workflows opérationnels décrivant les processus métier critiques, ainsi que des informations de configuration sur les systèmes tiers connectés à la plateforme. Un acteur malveillant disposant d'un accès en lecture à cet ensemble de données détient une cartographie détaillée de l'infrastructure d'une organisation — un avantage considérable pour planifier une attaque ciblée.

ServiceNow n'a pas communiqué de liste officielle des clients affectés ni divulgué le volume précis des données auxquelles des acteurs non autorisés auraient pu accéder. La société indique avoir contacté directement les clients identifiés comme potentiellement impactés. La correction technique consiste à modifier la configuration de l'endpoint API pour exiger une authentification valide sur toutes les requêtes entrantes. Selon l'analyse technique publiée par le cabinet Triskele Labs, les premières tentatives d'exploitation ont utilisé des patterns de requêtes en rafale caractéristiques d'un scraping automatisé, suggérant l'utilisation d'outils spécialisés dans la reconnaissance d'API.

Du côté des indicateurs techniques, les équipes de réponse aux incidents doivent examiner les patterns d'accès inhabituels dans les logs d'API. Des requêtes en rafale depuis une IP unique vers /api/now/related_list_edit, des accès effectués en dehors des heures ouvrées habituelles, ou des volumes anormalement élevés de données en réponse constituent des signaux d'alerte à investiguer en priorité. Les outils SIEM correctement configurés pour monitorer les accès aux API ServiceNow auraient dû générer des alertes sur ces patterns dès les premières heures d'exploitation. L'incident intervient dans un contexte tendu pour les plateformes ITSM, qui constituent des cibles de choix pour les attaquants depuis plusieurs années.

Pourquoi c'est important

L'incident ServiceNow illustre de manière frappante un problème structurel récurrent dans le développement et la maintenance des plateformes SaaS d'entreprise : la gestion de la surface d'attaque exposée par les APIs. Les APIs REST sont aujourd'hui le premier vecteur d'entrée des attaquants sur les applications cloud, devant les injections SQL et le phishing selon plusieurs rapports sectoriels récents. Lorsqu'un endpoint est publié avec l'authentification désactivée par défaut, le risque n'est pas théorique : il est immédiat et peut être exploité par tout acteur disposant d'informations basiques sur la structure de l'API.

Ce qui amplifie l'impact potentiel de cet incident est la position stratégique qu'occupe ServiceNow dans l'architecture IT des entreprises. Une plateforme ITSM n'est pas un outil isolé en périphérie du système d'information : elle est le hub central qui connecte les équipes IT, les équipes de sécurité, les RH, la direction opérationnelle et les outils d'automatisation. Elle est reliée à l'Active Directory pour la gestion des identités, aux outils de monitoring pour les alertes d'infrastructure, aux systèmes de ticketing des fournisseurs tiers et aux solutions de gestion des assets. Compromettre l'accès en lecture à une instance ServiceNow, c'est obtenir une vue consolidée de l'ensemble de l'écosystème technologique d'une entreprise — un avantage considérable pour préparer une attaque de type ransomware, une opération d'espionnage industriel ou une intrusion ciblée.

La fenêtre d'exposition de plusieurs mois — d'avril à début juin 2026 — soulève également des questions profondes sur la maturité des processus de détection dans les organisations concernées. Des requêtes non authentifiées récurrentes vers un endpoint sensible d'une plateforme ITSM devraient figurer dans les règles de détection de base de tout SIEM. Si ces alertes n'ont pas fonctionné, c'est soit que les organisations ne monitoraient pas les accès à leur instance ServiceNow via une solution SIEM, soit que les règles de détection n'avaient pas été configurées pour ce cas d'usage. Cette lacune, répandue dans de nombreuses organisations de taille intermédiaire, représente un angle mort considérable dans leur posture de sécurité.

Du point de vue réglementaire, cet incident engage potentiellement la responsabilité des entreprises affectées au titre du RGPD. Si des données personnelles d'employés ou de clients ont été exposées, les organisations victimes ont l'obligation de notifier leur autorité de contrôle compétente dans un délai de 72 heures à compter de la prise de connaissance de la violation, conformément à l'article 33 du RGPD. La CNIL en France, l'ICO au Royaume-Uni et les autorités équivalentes dans les autres États membres de l'Union européenne doivent être notifiées dans ce délai. Les entreprises qui découvrent une compromission de leur instance ServiceNow doivent donc mener de front les investigations techniques et le processus de notification réglementaire, en documentant précisément le périmètre des données potentiellement exposées.

Ce qu'il faut retenir

• Vérifier immédiatement la version de votre instance ServiceNow et appliquer le patch de sécurité si votre déploiement est on-premise ou utilise des configurations personnalisées héritées.
• Analyser les logs d'accès API pour toute requête vers /api/now/related_list_edit depuis des sources externes, en particulier depuis l'adresse 51.159.98.241, sur la période d'avril à début juin 2026.
• En cas de compromission avérée ou suspectée impliquant des données personnelles, notifier la CNIL dans les 72 heures et activer votre plan de réponse aux incidents RGPD.