ServiceNow a corrigé son cloud d'abord, vous 103 jours plus tard

Le signalement est arrivé le premier avril

Le 1er avril 2026, Adam Kues, d'Assetnote, la branche recherche de Searchlight Cyber, a adressé à ServiceNow un rapport décrivant un moyen d'exécuter du code sur la ServiceNow AI Platform sans le moindre identifiant. L'éditeur a réagi vite. Dans son propre récit de la divulgation, l'équipe de recherche indique que ServiceNow a "déployé de solides mesures d'atténuation sur l'ensemble des instances cloud dans les 24 heures suivant notre signalement", puis a livré dans les semaines suivantes les correctifs des défauts sous-jacents. Tout client installé sur une instance hébergée par ServiceNow était protégé dès le début du mois d'avril, sans avoir rien à faire, ni même à en être informé.

Les clients qui font tourner leur propre copie n'ont rien appris avant le 13 juillet, date à laquelle ServiceNow a publié l'avis de sécurité KB3137947 et diffusé les mises à jour destinées aux déploiements auto-hébergés. La faille porte la référence CVE-2026-6875. ServiceNow, qui agit comme sa propre CNA, lui a attribué un score CVSS 4.0 de 9,5 sur 10. Le vecteur retient une complexité d'attaque élevée, mais aucun privilège et aucune interaction utilisateur, et c'est exactement la combinaison qui rend une instance joignable depuis internet attirante pour qui scanne à grande échelle.

Entre ces deux dates, il y a 103 jours. Pour un éditeur SaaS, c'est une divulgation coordonnée bien menée. Pour la partie de sa clientèle qui exploite elle-même la plateforme, c'est un trimestre entier passé avec une faille critique exploitable avant toute authentification, que l'éditeur avait déjà refermée sur son propre parc.

Un bac à sable qui acceptait d'évaluer du JavaScript

La vulnérabilité se loge dans le bac à sable de la ServiceNow AI Platform, la couche de confinement censée laisser le code de la plateforme s'exécuter sans atteindre ce qu'il ne devrait pas atteindre. Le point d'entrée est l'API GlideRecord, qui accepte l'évaluation de JavaScript à l'intérieur des filtres de requête. Une donnée fournie par l'utilisateur parvenait jusqu'à un appel addQuery porteur du préfixe javascript:, et la plateforme l'évaluait.

Un bac à sable secondaire devait justement intercepter ce cas et bloquer les fonctions dangereuses. Les chercheurs l'ont franchi grâce à une chaîne de gadgets construite sur Object.clone et Class.create.constructor, qui produisent ensemble l'exécution de fonctions arbitraires pendant les script includes. Le point d'entrée démontré était le point de terminaison /assessment_thanks.do, par l'intermédiaire de son paramètre sysparm_assessable_type, et rien de tout cela ne demandait d'être connecté.

Ce que cela offre à un attaquant n'est pas un simple appui dans un recoin du produit. L'analyse publiée par Searchlight décrit la lecture de données dans les tables, la création de comptes administrateur et l'exécution de commandes shell sur les relais MID Server configurés, lesquels, comme le notent les chercheurs, se trouvent le plus souvent à l'intérieur des réseaux internes des entreprises. Le MID Server est précisément l'élément qui plonge dans votre parc pour découvrir les actifs et exécuter l'automatisation. C'est le pont, et le pont est accessible depuis la faille.

Qui portait réellement le risque

Le réflexe habituel des conseils d'administration européens veut que l'auto-hébergement soit l'option prudente. Les données restent sur vos propres machines, la question de la localisation se règle en une phrase, et vous évitez de tendre à un régulateur un schéma embarrassant. Dans les secteurs régulés de l'Union, dans l'administration publique, dans la banque et parmi les grands groupes du Mittelstand, ce réflexe explique pourquoi une part significative des parcs ServiceNow ne tourne pas sur le cloud de ServiceNow.

Cet avis de sécurité renverse le raisonnement. Les clients qui ont choisi le cloud de l'éditeur ont été protégés dès les premiers jours d'avril par une mesure d'atténuation qu'ils n'ont jamais eu à réclamer. Les clients qui ont choisi de l'exploiter eux-mêmes, par souci de contrôle, ont porté une exécution de code à distance non authentifiée pendant les mois d'avril, de mai, de juin et la moitié de juillet, et n'ont été prévenus qu'au moment où le correctif était prêt à être livré. Le contrôle sur le déploiement s'est révélé être la propriété de la fenêtre d'exposition.

Rien de tout cela ne rend la gestion de ServiceNow critiquable. Déployer des mesures d'atténuation sur un parc que l'on exploite soi-même est tout simplement plus rapide que d'acheminer des correctifs vers un parc que l'on n'exploite pas, et garder le détail d'un avis de sécurité jusqu'à ce que les clients puissent agir relève de la pratique courante et non de la dissimulation. La leçon pour l'exploitant est plus étroite et plus utile : "l'éditeur a corrigé" et "nous sommes corrigés" sont deux affirmations différentes, et cette fois cent jours les séparaient.

Les deux affirmations sont vraies en même temps

Pendant le week-end des 18 et 19 juillet, le groupe de renseignement sur les menaces Defused a signalé une exploitation active, dont les premières tentatives ont été observées le vendredi 17 juillet. L'avis de sécurité de ServiceNow, lundi matin, affirme toujours que l'éditeur n'a "pas connaissance à ce jour d'une exploitation visant des instances ServiceNow". Mises côte à côte, les deux phrases donnent l'image d'un éditeur qui tarde à admettre l'évidence.

La réalité est plus intéressante, et c'est cette réconciliation qui fait le fond de l'affaire. Les deux parties mesurent des populations différentes. ServiceNow dispose d'une télémétrie directe sur le parc qu'il héberge, et ce parc bénéficie d'une mesure d'atténuation depuis le début d'avril, si bien que rien n'y est réellement exploité. Defused observe le trafic à l'échelle d'internet, c'est-à-dire là où vivent les instances auto-hébergées. La population que l'éditeur ne peut pas voir est exactement celle qui n'est toujours pas corrigée.

La phrase de l'éditeur est donc exacte et, en même temps, inutilisable comme donnée d'entrée pour votre analyse de risque. "Aucune exploitation confirmée" dans la bouche d'un fournisseur SaaS est une affirmation sur le parc du fournisseur lui-même, sauf s'il précise expressément le contraire. Si vous exploitez le logiciel vous-même, le seul état d'exploitation qui décrive votre situation est celui que vous tirez de vos propres journaux.

L'exploit n'a pas attendu la preuve de concept

Defused a été précis sur ce qu'il a observé. Les charges utiles, rapporte le groupe, "atteignent le même point d'aboutissement pré-authentification documenté par @SLCyberSec (/assessment_thanks.do), mais le gadget d'évasion du bac à sable atteint la même primitive d'exécution de code par une voie différente de leur PoC publiée". Les attaquants ne rejouaient pas l'exploit des chercheurs. Ils avaient atteint la même primitive de façon indépendante, en menant leur propre travail à partir du même point de départ.

Ce détail démonte une habitude de planification répandue dans les organisations soumises à la gestion du changement : considérer l'apparition d'une preuve de concept publique comme le moment où le compte à rebours démarre, puis corriger à la fenêtre de maintenance suivante. Ici, la capacité indépendante est arrivée en même temps que l'analyse publique et non après, et l'avis de sécurité lui-même, le 13 juillet, a constitué le dernier avertissement fiable que quiconque allait recevoir.

Ce qu'il faut vérifier avant mardi

Commencez par la famille de versions, car les noms des correctifs ne sont pas intuitifs. Les versions corrigées sont Brazil EA et Brazil GA, Australia Patch 2, Zurich Patch 7b ou Zurich Patch 9, et Yokohama Patch 12 Hot Fix 1b ou Yokohama Patch 13. Tout ce qui se situe en dessous de la ligne correspondante est vulnérable : mettez à niveau vers la version corrigée de votre famille, car une instance auto-hébergée qui n'a pas connu de fenêtre de maintenance depuis le 13 juillet n'a été corrigée par personne à votre place.

Partez ensuite du principe que cette fenêtre a compté. Sortez les journaux d'accès de /assessment_thanks.do et examinez précisément le paramètre sysparm_assessable_type. Passez en revue les créations de comptes administrateur sur toute la période, et non sur les quinze derniers jours, parce que la faille permet à un attaquant d'en créer un. Allez ensuite sur les MID Servers, cherchez les exécutions de processus inattendues, et gardez en tête que ces machines se trouvent à l'intérieur du réseau interne et non devant lui, ce qui transforme un défaut de plateforme en problème de déplacement latéral.

Si vous trouvez quelque chose, l'horloge est autant réglementaire que technique. Pour les entités essentielles et importantes de l'Union, NIS2 impose une alerte précoce auprès de votre CSIRT national dans les 24 heures suivant la prise de connaissance d'un incident important, puis une notification plus complète sous 72 heures. Au Royaume-Uni, où NIS2 ne s'applique pas, le NCSC reste la voie de signalement, et c'est le même travail de collecte de preuves qui donne sa valeur à la déclaration.

À lire ensuite: Une requête pouvait détourner votre site WordPress  |  Corriger SharePoint ne ferme plus la porte