Un incident de sécurité récent impliquant ServiceNow met en évidence un risque important pour les entreprises qui s'appuient sur des plateformes de gestion des flux de travail et des services informatiques dans le cloud. ServiceNow a révélé qu'une faille logicielle affectant certaines instances client permettait un accès non authentifié aux données via un point de terminaison API vulnérable. Cette faille contournait de fait les contrôles d'authentification, permettant ainsi à des tiers d'interroger les données stockées sans identifiants valides.

La vulnérabilité semble avoir été liée à un point de terminaison API (apparemment /api/now/related_list_edit/create) qui était mal configuré, l'authentification étant désactivée. En conséquence, toute partie connaissant ce point de terminaison pouvait tenter de récupérer des données à partir des instances concernées. ServiceNow a corrigé le problème le 5 juin 2026 en imposant des exigences d'authentification sur le point de terminaison. Cependant, la société a reconnu que des activités anormales avaient déjà été observées avant la correction, certaines données d'instances client ayant été interrogées avec succès.

Bien que ServiceNow ait déclaré que l'activité observée était liée à des chercheurs en sécurité et à des signalements de bogues plutôt qu'à des acteurs malveillants confirmés, cette distinction n'élimine pas l'impact sur la sécurité. Du point de vue de la défense et de la gestion des risques, le résultat reste le même : une exposition des données s'est produite via un chemin non authentifié. De plus, l'entreprise n'a pas précisé publiquement l'étendue totale des clients affectés, ni fourni de visibilité détaillée sur les types de données consultés dans chaque cas.

Cette vulnérabilité est particulièrement préoccupante en raison de la nature des données généralement stockées dans les environnements ServiceNow. Les instances d'entreprise contiennent souvent des informations opérationnelles et liées à la sécurité sensibles, notamment des tickets de service informatique, des dossiers d'employés, des données de réponse aux incidents, de la documentation interne, ainsi que des identifiants ou des jetons API potentiellement intégrés et partagés lors des workflows de dépannage. Les acteurs malveillants ciblent fréquemment les systèmes de support, car ceux-ci servent de points de convergence pour des informations contextuelles de grande valeur pouvant être exploitées pour des attaques ultérieures telles que l'escalade de privilèges, les mouvements latéraux ou la compromission de la chaîne d'approvisionnement.

Le calendrier de l'incident suscite des inquiétudes supplémentaires du point de vue du renseignement sur les menaces. ServiceNow aurait reçu en avril 2026 un rapport confidentiel de bug bounty décrivant un problème similaire, mais n'a déployé de mise à jour de sécurité qu'au début du mois de juin, alors que les activités ciblant les instances des clients avaient déjà commencé. Ce délai entre la découverte et la correction augmente la probabilité que la connaissance de la faille se soit propagée au-delà des chercheurs de confiance, que ce soit par une découverte indépendante ou une divulgation involontaire.

Un autre aspect notable est la variabilité potentielle de l'exposition. Alors que ServiceNow a indiqué que le problème affectait principalement les instances de la version « Australia » de la plateforme ou celles présentant des modifications de configuration spécifiques, les rapports de la communauté suggèrent un impact plus large sur d'autres versions. Cela soulève la possibilité que des erreurs de configuration ou des paramètres hérités entre les environnements aient pu étendre la surface d'exposition au-delà des limites initialement comprises.

Les indicateurs de compromission associés à cette activité comprennent des requêtes provenant de l'adresse IP 51.159.98.241 et des tentatives d'accès ciblant le point de terminaison API susmentionné. Bien que l'attribution reste incertaine, les défenseurs doivent considérer toute preuve d'accès API non authentifié comme suspecte, quelle que soit la source.

Du point de vue du paysage des menaces, cet incident renforce plusieurs tendances importantes. Les plateformes SaaS dans le cloud continuent de représenter des cibles centralisées de grande valeur où une seule vulnérabilité peut exposer simultanément plusieurs organisations. Les erreurs de configuration des API et les défaillances du contrôle d'accès restent une cause majeure d'exposition des données dans les environnements cloud. De plus, le recours à la sécurité gérée par le fournisseur n'élimine pas la nécessité de contrôles de visibilité, de journalisation et de validation du côté du client.

Ce que vous devez faire

Les organisations utilisant ServiceNow doivent immédiatement effectuer une analyse rétrospective des journaux couvrant au moins la période allant de début avril à mi-juin 2026, en accordant une attention particulière aux requêtes API non authentifiées ou anormales. Toute tentative d'accès impliquant le point de terminaison concerné ou provenant d'indicateurs connus tels que 51.159.98.241 doit être examinée comme un événement potentiel de fuite de données. Même si l'activité est attribuée à des chercheurs, les données consultées doivent être considérées comme potentiellement compromises.

Vous devez examiner tous les enregistrements susceptibles d'avoir été exposés via les workflows ServiceNow, en particulier les tickets d'assistance, les enregistrements d'incidents et les entrées de la base de connaissances. Tout cas où des identifiants, des clés API, des jetons d'authentification ou des détails de configuration sensibles ont été partagés doit déclencher un processus de rotation obligatoire. Cela inclut les mots de passe, les clés de compte de service, les jetons OAuth et tout secret intégré dans des pièces jointes ou des notes.

Assurez-vous que la journalisation des accès à l'API est pleinement activée et conservée pendant une durée adéquate à l'avenir. Si la journalisation était auparavant désactivée ou insuffisante, cet incident doit être traité comme une lacune dans la capacité de détection qui nécessite une correction. Envisagez d'intégrer les journaux ServiceNow dans une plateforme SIEM ou XDR centralisée afin de permettre la corrélation avec d'autres signaux de sécurité.

Il est essentiel de vérifier que toutes les instances ServiceNow exécutent la configuration corrigée et qu'aucune personnalisation ou paramètre hérité ne remplace les exigences d'authentification sur les points de terminaison API. Les dérives de configuration doivent être évaluées, en particulier dans les instances plus anciennes ou les environnements fortement personnalisés.

Si l'une des menaces décrites dans ce bulletin vous préoccupe ou si vous avez besoin d'aide pour déterminer les mesures à prendre afin de vous protéger contre les menaces les plus importantes auxquelles votre organisation est confrontée, veuillez contacter votre responsable de compte ou nous contacterpour savoir comment protéger votre organisation.