if ( !emtpy($headline_subheadline ) ) : ?>
Les vulnérabilités peuvent être exploitées à distance sans interaction de l’utilisateur ; Les équipes de sécurité doivent également regarder au-delà de ServiceNow vers les informations d’identification, les API et les flux de travail auxquels la plateforme peut accéder.
endif; ?>
Les attaques par injection de code et par injection SQL existent depuis des décennies et restent des moyens éprouvés pour les attaquants de compromettre les systèmes.
Le dernier trio de failles de gravité maximale de ServiceNow montre que même les plates-formes de l’ère de l’IA restent vulnérables à ces techniques : le fournisseur de logiciels a publié des correctifs pour trois bogues dans sa plate-forme ServiceNow AI qui pourraient être exploités via des attaques par injection de code de faible complexité, par injection SQL et par élévation de privilèges, sans aucune interaction de l’utilisateur requise.
Bien que ses instances basées sur le cloud aient déjà été mises à jour, ServiceNow conseille aux clients auto-hébergés de mettre à niveau ou de mettre à jour immédiatement.
« Vous ne voulez jamais voir un 10/10 critique », a déclaré David Shipley de Beauceron Security. « Et vous ne voulez vraiment pas en voir trois d’affilée, à moins qu’il ne s’agisse d’un jury olympique. »
Donne aux attaquants la possibilité d’accéder, de modifier et de créer des données
La ServiceNow AI Platform, anciennement Now Platform, combine l’IA et les agents autonomes, les données, ainsi que les contrôles de sécurité et de gouvernance dans les workflows informatiques de l’entreprise, de gestion des employés et de la relation client (CRM).
Cela en fait une cible juteuse pour les attaquants.
Les trois vulnérabilités critiques actuellement corrigées sont suivies sous les noms CVE-2026-18885, CVE-2026-18886 et CVE-2026-74820. CVE-2026-18885 permettrait aux utilisateurs non authentifiés d’exécuter du code arbitraire et d’accéder et/ou de modifier les données d’instance. CVE-2026-18886 pourrait donner aux acteurs malveillants la possibilité de créer ou de modifier des données d’instance et d’augmenter les privilèges, et la vulnérabilité CVE-2026-74820 pourrait permettre aux attaquants d’exécuter des instructions SQL arbitraires sur la base de données sous-jacente d’une instance pour modifier les données.
Parallèlement à cela, ServiceNow a également corrigé la vulnérabilité de haute gravité CVE-2026-6876, une vulnérabilité d’évasion de bac à sable affectant ServiceNow AI. Cette vulnérabilité pourrait permettre à des attaquants disposant de privilèges de base d’effectuer l’exécution de code à distance (RCE).
ServiceNow a déclaré dans son avis qu’il n’était « actuellement au courant d’aucune exploitation » de l’une des failles. La société a publié des correctifs pour les quatre, pour les versions Xanadu, Yokohama et Zurich de la plate-forme concernées.
Récemment, ServiceNow a également publié des correctifs pour plusieurs autres vulnérabilités critiques, notamment le problème d’API de juin et le CVE-2026-6875 du mois dernier, une évasion de bac à sable de pré-authentification dans sa plateforme AI. Comme les vulnérabilités révélées cette semaine, cela pourrait permettre à des utilisateurs non authentifiés d’exécuter du code. Et plus tôt ce mois-ci, des recherches indépendantes ont également identifié des attaques exposant les données des entreprises.
Concernant la gravité et l’accessibilité
Ce qui rend les vulnérabilités actuelles particulièrement graves est la combinaison de la gravité et de l’accessibilité, a noté Ensar Seker, RSSI chez SOCRadar ; l’exploitation peut potentiellement se produire sans authentification.
« Cela signifie qu’un attaquant n’a peut-être pas besoin de voler les informations d’identification ou de compromettre un employé avant de tenter d’exploiter la plate-forme », a déclaré Seker, notant que CVE-2026-18885 est particulièrement préoccupant car il pourrait prendre en charge l’exécution de code arbitraire via l’API de données composites GraphQL. Cela signifie que, en cas d’attaque réussie, « l’injection de code peut effectivement transformer une application d’entreprise fiable en un environnement d’exécution contrôlé par l’attaquant », a-t-il souligné.
CVE-2026-74820 présente un risque différent, mais tout aussi grave, a-t-il déclaré. Avec l’injection SQL, un attaquant peut interagir avec une base de données sous-jacente de manière involontaire, potentiellement en lisant, en manipulant ou en détruisant des données.
En général, les attaques par injection de code et par injection SQL sont dangereuses car elles brisent les frontières de sécurité fondamentales entre les données fournies par un utilisateur et les instructions exécutées par un système, a expliqué Seker. Une fois que l’entrée contrôlée par l’attaquant est interprétée comme du code ou une commande de base de données, les contrôles d’accès au niveau de l’application peuvent ne plus être adéquats.
Ensuite, a-t-il noté, il y a le rôle que joue ServiceNow au sein des entreprises qui l’utilisent dans leurs opérations, leurs actifs, leurs approbations et leurs intégrations. Les attaquants qui réussissent peuvent non seulement accéder à des données opérationnelles sensibles, mais aussi se déplacer latéralement et abuser des flux de travail et des intégrations fiables des clients et partenaires.
« Compromettre ce type de plate-forme peut donc être bien plus grave que compromettre une application autonome », a-t-il déclaré. Les attaquants ciblant les plates-formes dotées d’intégrations étendues peuvent être plus intéressés par les informations d’identification, les jetons et les systèmes qui y sont connectés, plutôt que par la plate-forme elle-même.
Patcher, mais aussi vérifier les intégrations externes
La priorité immédiate des entreprises est de déterminer quelles instances et versions de ServiceNow elles exploitent, et de confirmer qu’elles ont été corrigées, a conseillé Seker. Les équipes de sécurité doivent également inventorier les intégrations ServiceNow, les API et les comptes de service hautement privilégiés.
En outre, a-t-il déclaré, les équipes devraient examiner la télémétrie historique pour rechercher des indicateurs de tentative d’exploitation, comme des demandes inhabituelles impliquant les API affectées et les fonctionnalités de téléchargement. Ils doivent également rechercher les changements inattendus d’administration ou de privilèges, la création ou la modification inexpliquée d’enregistrements, le comportement anormal du compte de service et l’accès inhabituel aux données sensibles de ServiceNow. Si une activité suspecte est signalée, recherchez les systèmes en aval connectés à ServiceNow plutôt que de les traiter comme une application isolée.
Dans l’ensemble, a noté Seker, l’IA modifie davantage l’économie de l’exploitation des vulnérabilités que la vulnérabilité sous-jacente. Les attaquants utilisent l’IA pour analyser les divulgations, générer et modifier des tentatives d’exploitation, énumérer les services exposés, adapter les charges utiles à différents environnements et automatiser les activités post-exploitation.
Travailler à réduire les délais de remédiation
« La période entre la divulgation publique et l’exploitation à grande échelle peut donc devenir de plus en plus courte », a déclaré Seker. Cela signifie que les organisations doivent s’efforcer de réduire le délai entre la divulgation, l’évaluation de l’exposition et la remédiation.
Cela nécessite une authentification et une autorisation API fortes, une validation stricte des entrées, des requêtes de base de données paramétrées, un accès au moindre privilège, une segmentation de l’intégration, une surveillance des applications et des couches API, ainsi que des contrôles qui détectent les comportements anormaux, a-t-il souligné. Les interfaces Internet doivent également être réduites au minimum.
Mais les vulnérabilités liées aux injections ne sont pas nouvelles, a-t-il observé. Des contrôles établis tels que le codage sécurisé, les API statiques et dynamiques et les tests contradictoires avant la production peuvent aider à éliminer les faiblesses.
Supposons également que l’IA continue d’automatiser la découverte et l’exploitation des vulnérabilités des acteurs malveillants, a-t-il ajouté. De ce fait, les défenseurs devraient mettre en œuvre une automatisation similaire autour de la découverte des actifs, de la validation de l’exposition et de la remédiation.
En outre, les équipes de sécurité ne doivent pas évaluer les plateformes SaaS et d’entreprise uniquement sur la base de leurs processus traditionnels de gestion des vulnérabilités. Le risque doit être évalué en fonction de leur rayon d’action : les données qu’ils contiennent, les systèmes, les informations d’identification et les API auxquels ils accèdent, et ce qu’un attaquant pourrait faire, a déclaré Seker.
Accessibilité, aucune interaction requise
Shipley de Beauceron a souligné que, même si ces divulgations de vulnérabilités sont essentielles pour les constructeurs, elles présentent un dilemme : les attaquants les connaissent désormais également. Dans les 15 minutes suivant la publication de ServiceNow, voire plus tôt, ils exploitaient probablement les failles.
Bien qu’il n’y ait aucune preuve antérieure de tentatives d’exploitation, « vous pouvez faire savoir à la banque que celles-ci sont en train d’être exploitées maintenant », a-t-il déclaré. L’accès non authentifié et l’accessibilité au réseau peuvent créer une « chaîne d’exploits douce » et les exploits de faible complexité sans aucune interaction requise « glacent le sang des professionnels de la sécurité ».
« L’injection SQL fait partie du groupe OG de vulnérabilités Web qui ne cessent de fonctionner », a-t-il souligné. Des milliards de lignes de code contiennent encore des défauts fondamentaux comme ceux-ci, révélant un manque d’incitation de la part des éditeurs de logiciels à fournir du code sécurisé. « Jusqu’à ce que nous changeons cela », a-t-il déclaré, « la soi-disant Vulnpocalypse est là pour rester. »
