Le 10 juin 2026, l'éditeur américain ServiceNow a envoyé un courriel à ses clients enterprise pour leur annoncer une nouvelle inquiétante : un bug de configuration a laissé leurs données exposées sur Internet pendant plusieurs semaines. Le correctif, appliqué le 5 juin, intervient après une période de flou où des utilisateurs Reddit affirmaient avoir signalé la faille dès le mois d'avril. Avec plus de 1 133 entreprises françaises utilisatrices, dont le ministère des Armées et des dizaines de sociétés du CAC 40, l'incident touche directement la vie privée de millions de personnes en France.
ServiceNow reconnaît le bug : « des données clients exposées sur Internet »
10 juin 2026 : l’exclusivité TechCrunch brise le silence
C'est le journaliste Zack Whittaker de TechCrunch qui a révélé l'information en exclusivité. ServiceNow a envoyé une notification à ses clients enterprise pour les informer qu'un bug avait exposé leurs données hébergées sur la plateforme. Le correctif a été appliqué le 5 juin, soit cinq jours avant la divulgation publique. Dans son article, Whittaker précise que le problème concernait d'abord des instances australiennes, mais que des utilisateurs Reddit d'autres régions ont également rapporté des signes d'accès non autorisé.
L'éditeur a partagé un indicateur de compromission (IOC) avec ses clients : l'adresse IP 51.159.98.241. Cette IP est désormais à surveiller par toutes les équipes de sécurité informatique, car elle a été utilisée pour sonder les instances vulnérables.
« Un utilisateur non authentifié pouvait accéder aux instances » – la déclaration officielle
Cybernews a obtenu une déclaration officielle de ServiceNow. Le texte est prudent : « The update concerned a security issue that could allow an unauthenticated user, in certain circumstances, to gain greater access to ServiceNow instances than intended. » Traduit : « La mise à jour concernait un problème de sécurité qui pouvait permettre à un utilisateur non authentifié, dans certaines circonstances, d'obtenir un accès plus large aux instances ServiceNow que prévu. »
Le choix des mots est remarquable. ServiceNow ne parle pas de « violation de données » mais de « problème de sécurité ». La formule vague laisse planer le doute sur la nature exacte des informations consultées et sur l'identité des personnes qui ont pu en profiter.
Un correctif tardif, des questions qui restent sans réponse
Le patch date du 5 juin, mais des rumeurs persistantes sur Reddit affirment que ServiceNow était au courant de la faille dès le 7 avril 2026. Un utilisateur a même affirmé qu'après avoir signalé le problème, le support de ServiceNow lui a d'abord suggéré de clore le ticket. Si ces allégations sont vraies, cela signifie qu'un mois complet s'est écoulé entre la première alerte et l'application du correctif.
Pendant ce mois, des attaquants ont eu le temps d'exploiter la faille. ServiceNow a confirmé avoir détecté une « activité anormale » sur des instances entre le 2 et le 3 juin. Mais qui a eu accès aux données ? Qu'ont-ils consulté ? L'éditeur reste silencieux sur ces questions.
La mécanique du bug : une API laissée grande ouverte
L’URL qui ne devrait pas exister : /api/now/related_list_edit/create
Pour comprendre ce qui s'est passé, il faut regarder du côté d'une API bien spécifique. L'endpoint vulnérable était /api/now/related_list_edit/create. En termes simples, une URL comme celle-ci permet à un programme de dialoguer avec la base de données de ServiceNow. Normalement, ces accès sont protégés par une authentification.
Sauf que dans ce cas, la protection n'existait pas. N'importe qui, sans identifiant ni mot de passe, pouvait envoyer une simple requête HTTP à cette URL et obtenir en retour des données stockées dans les instances des clients. C'est comme si une porte de bureau restait grande ouverte parce que le constructeur avait oublié d'installer la serrure.
Le paramètre oublié : requires_authentication=false
Les enquêtes techniques menées par BleepingComputer et les discussions sur Reddit ont rapidement identifié la cause racine. Dans la configuration de l'API, un paramètre booléen nommé requires_authentication était réglé sur false. Une erreur de développement, probablement due à un oubli lors de la création de l'endpoint.
La correction a été simple : passer ce paramètre à true. Mais cette simplicité même soulève des questions. Comment un endpoint critique, capable d'interroger les tables de données des clients, a-t-il pu être déployé sans cette vérification de base ? La fragilité de la sécurité d'une plateforme utilisée par 85 % des entreprises du Fortune 500 interpelle.
D’avril à juin : la longue attente avant le correctif
Reconstituons la chronologie précise :
- 7 avril 2026 : un utilisateur Reddit affirme que ServiceNow est au courant de la vulnérabilité. Selon son témoignage, le support de l'éditeur aurait minimisé le problème.
- 2-3 juin 2026 : ServiceNow détecte une activité suspecte sur plusieurs instances clients. Des requêtes non authentifiées sont observées.
- 5 juin 2026 : le correctif est finalement appliqué. Le paramètre
requires_authenticationpasse àtrue. - 8 juin 2026 : des discussions Reddit évoquent un « incident de sécurité majeur » chez ServiceNow.
- 10 juin 2026 : TechCrunch publie l'exclusivité, confirmant les rumeurs.
Le trou de près d'un mois entre l'alerte d'avril et l'action de juin reste inexpliqué. ServiceNow n'a pas commenté cette période.
1 133 clients français dans le viseur : du ministère des Armées à votre campus
1 133 sociétés utilisatrices en France : l’ampleur du parc installé
Selon les données de TheirStack, 1 133 entreprises et organisations françaises utilisent ServiceNow. Ce chiffre place la France parmi les marchés les plus importants de l'éditeur en Europe. ServiceNow revendique que « plus de 85 % des entreprises du Fortune 500 » travaillent avec sa plateforme.
En France, le réseau de partenaires est dense : Capgemini, Devoteam, Accenture, DXC, Inetum, Deloitte, EY et KPMG accompagnent les déploiements. ServiceNow France SAS, créée en 2011, réalise plusieurs centaines de millions d'euros de chiffre d'affaires annuel.
Des données sensibles : du ministère des Armées aux services RH de votre école
LeMagIT révélait dès 2024 que ServiceNow France comptait parmi ses clients le ministère des Armées, des entreprises du CAC 40, des universités et des administrations centrales. Les données traitées sont particulièrement sensibles : fiches de paie, dossiers de carrière, habilitations de sécurité, informations médicales, descriptions de problèmes personnels.
Pour le ministère des Armées, les enjeux dépassent la simple protection des données personnelles. Les informations contenues dans les tickets IT peuvent révéler des faiblesses dans les systèmes de défense, des adresses de sites sensibles ou des noms d'agents. Une fuite de ce type représenterait un risque pour la sécurité nationale.
ServiceNow dans le quotidien des jeunes Français (RH, IT, Helpdesk)
Vous utilisez probablement ServiceNow sans le savoir. Quand vous ouvrez le portail étudiant de votre université pour demander un certificat de scolarité, quand vous soumettez un ticket au service informatique de votre entreprise pour un problème de connexion, ou quand vous faites une demande de congés via l'intranet de votre boîte, il y a de fortes chances que ServiceNow soit derrière.
L'interface est partout : helpdesk, gestion des ressources humaines, suivi des incidents, bases de connaissances. Vos données de connexion, votre adresse email, votre numéro de téléphone, vos problèmes personnels décrits dans les tickets – tout cela se retrouve dans les bases de données exposées.
Emails, mots de passe, tickets : le trésor de données exposé par le bug
L’IP 51.159.98.241 : l’indicateur de compromission à surveiller
TechCrunch a partagé un indicateur de compromission (IOC) concret : l'adresse IP 51.159.98.241. Cette IP a été utilisée pour sonder les instances ServiceNow vulnérables. Si vous travaillez dans une équipe IT, c'est l'adresse à bloquer immédiatement dans vos firewalls.
Pour les utilisateurs lambda, des outils comme Have I Been Pwned ou VirusTotal permettent de vérifier si vos identifiants ont fuité. Tapez votre adresse email sur ces plateformes pour savoir si elle est apparue dans des fuites récentes.
Tickets IT et conversations RH : le trésor des hackers
Les tickets de support technique sont une mine d'or pour les cybercriminels. BleepingComputer rapporte que les instances ServiceNow contiennent typiquement :
- Des mots de passe temporaires en clair, envoyés par email aux utilisateurs
- Des identifiants de connexion à des applications internes
- Des adresses postales et numéros de téléphone
- Des descriptions détaillées de problèmes personnels ou professionnels
- Des captures d'écran contenant des informations sensibles
- Des configurations de systèmes et des adresses IP internes
Avec ces éléments, un attaquant peut monter des attaques de social engineering extrêmement convaincantes. Connaître le nom de votre entreprise, le type de problème que vous avez rencontré et votre adresse email lui donne tous les éléments pour se faire passer pour un collègue ou un technicien.
Le risque numéro 1 : le phishing ultra‑personnalisé
C'est le danger immédiat pour les jeunes utilisateurs. Imaginez recevoir un email qui commence par « Bonjour [votre nom], suite à votre ticket du 15 mai concernant [problème précis], merci de cliquer ici pour réinitialiser votre mot de passe. » L'email semble légitime car il contient des détails que seul le service IT était censé connaître.
C'est ce qu'on appelle le spear-phishing : du phishing ciblé, personnalisé, beaucoup plus difficile à détecter que les arnaques génériques. Les jeunes, habitués à recevoir des communications automatisées de leur école ou de leur entreprise, sont particulièrement vulnérables.
Transparence et confiance : les zones d’ombre du correctif ServiceNow
Un bug majeur sans numéro CVE : l’opacité de ServiceNow
Interrogé par Cybernews, ServiceNow a déclaré : « We are still evaluating whether to publish a CVE. » Traduit : « Nous évaluons encore s'il faut publier un CVE. » Un CVE (Common Vulnerabilities and Exposures) est le numéro d'identification standard pour une faille de sécurité. Ne pas en publier un, c'est priver la communauté de sécurité d'une référence claire.
Cette opacité est problématique. Sans CVE, les équipes de sécurité des clients ne peuvent pas référencer facilement l'incident dans leurs outils. Les chercheurs indépendants ne peuvent pas vérifier si le correctif est complet. C'est un choix qui dessert la transparence.
70 % des instances déjà vulnérables : un précédent qui alerte
Le chercheur en sécurité Aaron Costello avait déjà démontré que près de 70 % des instances ServiceNow étaient affectées par des problèmes de configuration similaires. Des widgets comme le Simple List, vulnérables depuis 2015, avaient déjà exposé des données. Le bug de juin 2026 n'est donc pas un accident isolé.
C'est un pattern : la complexité de la plateforme ServiceNow, avec ses multiples API, widgets et options de configuration, crée un terrain fertile pour les erreurs. Chaque mise à jour, chaque nouveau module peut introduire une faille si les paramètres de sécurité ne sont pas vérifiés systématiquement.
CNIL et RGPD : ServiceNow a‑t‑il respecté ses obligations ?
Le Règlement Général sur la Protection des Données (RGPD) impose aux entreprises de notifier toute violation de données personnelles à l'autorité de contrôle compétente (la CNIL en France) dans les 72 heures suivant la découverte de l'incident.
ServiceNow a-t-il respecté ce délai ? La détection de l'activité anormale date du 2-3 juin, le correctif du 5 juin. Si la notification à la CNIL n'a pas été faite dans les 72 heures suivant la découverte, l'éditeur s'expose à des sanctions pouvant aller jusqu'à 4 % de son chiffre d'affaires annuel mondial.
Pour les clients français, la question est aussi de savoir si ServiceNow les a informés dans des délais raisonnables. Les premiers courriels aux clients enterprise sont arrivés juste avant la divulgation publique du 10 juin. Les clients plus petits, notamment les universités et les PME, ont-ils été prévenus ?
Actions concrètes : les 5 gestes à faire ce soir pour sécuriser vos comptes
➡️ 1. Vérifiez si votre école ou votre entreprise utilise ServiceNow
Regardez dans la barre d'adresse de votre navigateur quand vous ouvrez le portail étudiant ou l'intranet de votre boîte. Si vous voyez .service-now.com dans l'URL, c'est que ServiceNow est utilisé. Vous pouvez aussi demander directement au service IT.
Si la réponse est oui, considérez que vos données ont potentiellement été exposées. Pas de panique, mais agissez.
➡️ 2. Changez immédiatement vos mots de passe (et uniques pour chaque site)
Priorité numéro un : changez le mot de passe du compte que vous utilisez pour vous connecter à ce portail. Puis changez tous les mots de passe qui sont identiques à celui-ci.
La règle d'or : un mot de passe unique par site. Utilisez un gestionnaire de mots de passe comme Bitwarden ou Dashlane pour ne pas avoir à les mémoriser. Un bon mot de passe fait au moins 12 caractères, mélange lettres, chiffres et symboles.
➡️ 3. Activez la double authentification (2FA) partout
La double authentification ajoute une couche de sécurité : même si votre mot de passe est volé, l'attaquant ne peut pas se connecter sans le code envoyé sur votre téléphone.
Activez-la sur tous les comptes qui le permettent : Google, Microsoft, réseaux sociaux, et surtout le portail professionnel ou étudiant si l'option est disponible. Sur la plupart des plateformes, cela se trouve dans les paramètres de sécurité du compte.
➡️ 4. Soyez parano avec vos emails : les signes du phishing
Dans les semaines à venir, soyez particulièrement vigilant avec les emails qui mentionnent ServiceNow, votre entreprise ou votre école. Les cybercriminels vont exploiter cette fuite pour envoyer des emails très crédibles.
Les signes qui doivent vous alerter : une adresse email d'expéditeur légèrement différente de l'habitude, des fautes d'orthographe, une demande urgente de cliquer sur un lien ou d'ouvrir une pièce jointe. En cas de doute, ne cliquez pas. Ouvrez votre navigateur et tapez l'URL vous-même.
➡️ 5. Surveillez vos comptes : activité suspecte et alertes de connexion
Vérifiez les sessions actives sur vos comptes principaux (email, réseaux sociaux, banque). Regardez s'il y a des connexions depuis des appareils ou des lieux que vous ne reconnaissez pas.
Activez les notifications de connexion : la plupart des services vous envoient un email ou une notification push quand un nouvel appareil se connecte à votre compte. C'est le meilleur moyen de détecter une intrusion rapidement.
Conclusion : la leçon d’un bug, quand le cloud fragilise notre vie privée
L'incident ServiceNow de juin 2026 n'est pas un cas isolé. Il s'inscrit dans une tendance lourde : la centralisation massive des données personnelles chez quelques éditeurs de cloud. ServiceNow, Salesforce, Microsoft, Google – ces plateformes hébergent des quantités colossales d'informations sur nos vies professionnelles et personnelles.
Quand un bug survient chez l'un d'eux, ce sont des millions de personnes qui se retrouvent exposées. Le problème n'est pas seulement technique : c'est un problème de confiance et de responsabilité. ServiceNow doit expliquer clairement ce qui s'est passé, pourquoi le correctif a tant tardé, et quelles mesures sont prises pour éviter que cela ne se reproduise.
Pour les utilisateurs, la leçon est simple mais cruciale : vous ne pouvez pas empêcher la prochaine faille, mais vous pouvez limiter les dégâts. Des mots de passe uniques pour chaque service, la double authentification activée partout, et une vigilance accrue face aux emails suspects – ces trois réflexes font la différence entre une fuite de données qui reste sans conséquence et une usurpation d'identité qui peut gâcher des années de vie numérique.
Le prochain bug viendra. Il peut être chez un autre éditeur, demain, sur une autre plateforme que vous utilisez quotidiennement. La résilience numérique ne consiste pas à éviter les failles – c'est impossible – mais à être prêt quand elles arrivent.
