Un avis récent assorti d’une liste précise de versions

Le 25 septembre 2026, le Centre canadien pour la cybersécurité a publié l’avis AV26-963 au sujet de vulnérabilités dans ServiceNow AI Platform. Sa portée pratique est claire : les administrateurs et les équipes de sécurité doivent identifier la version de leur instance et la comparer aux niveaux corrigés indiqués par le fournisseur. L’avis de l’organisme canadien porte sur les informations disponibles au 24 septembre. À lui seul, il ne confirme pas qu’une instance particulière est exposée ou a été compromise.

L’alerte est utile parce qu’elle distingue le nom commercial de la plateforme des branches de versions concernées. Il ne suffit pas de savoir qu’une organisation utilise ServiceNow, ni que son environnement appartient à une famille récente : il faut vérifier la branche et le correctif appliqué. La décision opérationnelle dépend de cette comparaison, et les organisations qui utilisent des environnements hébergés, autogérés ou administrés par un tiers devraient confirmer qui applique la mise à jour et comment son installation est attestée. Des libellés de version proches peuvent correspondre à des chemins de maintenance différents ; la comparaison doit donc porter sur la branche et le hot fix exacts de l’instance. Il faut également tenir compte de la date de l’avis : celui-ci décrit les informations alors connues, pas nécessairement toutes les évolutions ultérieures.

Branches à comparer aux correctifs

L’avis indique les versions antérieures à trois niveaux Australia : Patch 2 Hot Fix 4b W32, Patch 4 Hot Fix 3 et Patch 5. Pour Yokohama, le seuil est Yokohama Patch 13 Hot Fix 5a. Pour Zurich, il mentionne trois références distinctes : Patch 10 Hot Fix 3b, Patch 10 Hot Fix 4a W32 et Patch 11 Hot Fix 3. La formule « antérieures à » signifie que les administrateurs doivent comparer la version exacte au seuil correspondant, sans supposer que toute installation de la même famille est corrigée.

Une réserve importante s’impose : l’avis ne donne pas un numéro de correctif unique applicable à toutes les branches. Zurich comporte également plusieurs chemins de mise à jour ; il faut donc éviter de simplifier la liste en une règle du type « installer le correctif le plus élevé ». La version de départ, le calendrier de maintenance et le modèle de service peuvent déterminer le chemin approprié. Si l’inventaire interne ne permet pas d’établir la branche et le hot fix avec certitude, demandez confirmation à l’administrateur responsable ou au support du fournisseur. Notez le seuil applicable à chaque environnement et les éléments qui justifient cette conclusion : une désignation générale de famille de produits ne remplace pas cette vérification.

Cinq identifiants CVE, mais pas cinq descriptions techniques complètes

L’alerte du CSIRT italien de Toscane, qui renvoie au bulletin de ServiceNow, énumère cinq identifiants : CVE-2026-86857, CVE-2026-86858, CVE-2026-86859, CVE-2026-86860 et CVE-2026-13016. Elle décrit également l’ensemble comme comprenant deux failles critiques et trois de gravité élevée. Cette indication aide à comprendre que la liste des versions correspond à plusieurs vulnérabilités, mais elle ne remplace pas la lecture de l’avis technique associé à chaque CVE et ne permet pas, à elle seule, de déterminer l’exposition d’une configuration particulière.

Parmi les fiches accessibles lors de cette vérification, CVE-2026-86857 est décrite comme un problème d’autorisation susceptible de permettre à une personne authentifiée d’accéder à des données d’AI Platform qu’elle n’est pas autorisée à consulter. CVE-2026-86859 est décrite comme un problème d’autorisation pouvant permettre un accès non authentifié à des données. Ces exemples montrent pourquoi le contrôle des accès et l’exposition d’informations sont importants ; ils ne justifient pas d’attribuer les mêmes détails aux trois autres identifiants. Ne déduisez pas de techniques, de conditions ou de conséquences précises pour chaque CVE à partir de la liste agrégée de l’avis. La synthèse des sévérités et les identifiants donnent des repères, sans remplacer les descriptions techniques et les critères d’applicabilité propres à chaque vulnérabilité.

Ce que l’on sait de l’exploitation et de la portée

Dans la description de la fiche CVE-2026-86857, ServiceNow indique avoir déployé une mise à jour sur les instances hébergées et l’avoir fournie aux partenaires et aux clients autogérés. Le même texte précise que l’entreprise n’avait pas connaissance d’une exploitation malveillante visant des instances ServiceNow au moment de la publication de la fiche. Cette formulation doit conserver sa limite temporelle : elle décrit ce que le fournisseur savait alors, ne prouve pas qu’aucune exploitation n’a jamais eu lieu et ne garantit pas qu’aucune information ultérieure ne sera publiée.

L’avis canadien énumère le produit et les versions, mais ne signale aucun incident précis chez des organisations utilisatrices et ne permet pas d’évaluer combien d’instances pourraient être concernées. Il ne faut pas confondre « vulnérabilité publiée » et « intrusion confirmée ». L’évaluation d’un cas particulier exige des informations sur l’instance elle-même, des journaux et une confirmation du fournisseur ; les sources examinées ne permettent pas d’affirmer que ces failles font l’objet d’une exploitation active. Les organisations ne doivent donc considérer ni l’absence d’incident signalé ni un avis général sur le produit comme une évaluation concluante de leur propre environnement.

Liste de contrôle pour les équipes des opérations et de la sécurité

Commencez par identifier le modèle de service et la personne chargée de sa maintenance. Si l’instance est hébergée par ServiceNow, demandez confirmation que la mise à jour correspondante a été appliquée à cet environnement, puis consignez la réponse et sa date. Si l’installation est autogérée ou maintenue par un partenaire, comparez la branche et le niveau de correctif exacts à la liste de l’avis et coordonnez la mise à jour selon les consignes de ServiceNow. L’avis public recommande de consulter les liens indiqués et d’appliquer les mises à jour nécessaires ; il ne fournit pas de procédure universelle dans la console qui puisse être considérée comme valable pour tous les déploiements.

Ensuite, consignez les éléments prouvant la clôture : branche, correctif ou hot fix, date d’application et responsable de la validation. Si l’organisation dispose de plusieurs environnements — production, test ou instances séparées par unité, par exemple — vérifiez-les tous, au lieu d’extrapoler l’état d’une installation aux autres. Considérez toute version qui semble antérieure aux seuils concernés comme un point en attente, jusqu’à confirmation du chemin de correction par le support. Si la version atteint déjà le niveau indiqué, conservez la preuve de cette comparaison ; ne l’interprétez pas automatiquement comme une évaluation complète des autres risques ou configurations. Une trace datée facilitera aussi les contrôles ultérieurs si la responsabilité de maintenance ou le mode d’hébergement change.

La donnée essentielle est la version exacte, pas une supposition

La conclusion vérifiable au 26 septembre 2026 est limitée : le Centre canadien pour la cybersécurité a publié une alerte concernant ServiceNow AI Platform, avec des branches et des niveaux de correctif précis ; une synthèse du CSIRT recense cinq CVE ; et les fiches consultées décrivent deux d’entre elles comme des problèmes d’autorisation et d’accès aux données. Pour un administrateur, la conduite raisonnable consiste à comparer le niveau exact de chaque instance à la liste, à confirmer la couverture auprès de ServiceNow lorsque nécessaire et à appliquer les mises à jour pertinentes conformément au bulletin du fournisseur.

L’information comporte des limites. À lui seul, l’avis ne détaille ni les composants techniques des cinq CVE, ni l’effet de chacune séparément, ni l’état de l’exploitation observé dans toutes les instances. L’absence de ces précisions dans l’avis public ne prouve pas qu’elles n’existent pas ; elle empêche simplement de les affirmer ici. Dans l’attente d’informations complémentaires du fournisseur ou des fiches techniques, la priorité n’est pas de spéculer sur des incidents, mais de vérifier l’état des correctifs de chaque déploiement et de consigner la confirmation. Distinguez toute précision publiée ultérieurement des faits établis par cet avis et réévaluez les environnements concernés si les seuils ou les consignes de maintenance évoluent.