Identités, agents IA, supply chain : l’attaque change de vitesse
Cette veille est produite à titre strictement personnel, dans le cadre de mes travaux indépendants de recherche, d’analyse et de réflexion. Son contenu relève exclusivement de ma responsabilité personnelle et ne reflète la position officielle d’aucune institution ou organisation.
Ces deux semaines concentrent plusieurs évolutions qui méritent d’être rapprochées.
Chez Cisco, deux systèmes placés à des endroits particulièrement sensibles de l’architecture sont activement exploités : Identity Services Engine, qui participe au contrôle des identités et des accès réseau, et Secure Email Gateway, qui reçoit précisément les messages provenant de l’extérieur.
Dans l’écosystème logiciel, CrowdStrike documente PhantomRaven, un infostealer distribué via des packages npm malveillants et que l’entreprise estime, avec un niveau de confiance élevé, avoir probablement été développé avec l’assistance d’un grand modèle de langage.
Plus significatif encore, l’autorité espagnole de protection des données annonce avoir reçu une première notification de violation de données dans laquelle un agent d’intelligence artificielle aurait enchaîné plusieurs phases d’une cyberattaque : recherche de vulnérabilités, accès au système, exploration autonome, modification de données et consultation de factures.
Microsoft corrige parallèlement deux zero-days Windows déjà exploitées, Google signale une exploitation limitée et ciblée d’une vulnérabilité affectant le modem des Pixel, tandis qu’une nouvelle vague d’avis industriels touche des systèmes liés au réseau électrique et aux automatismes.
Et le 11 septembre, une évolution réglementaire attendue depuis plusieurs mois devient enfin opérationnelle : les premières obligations de notification du Cyber Resilience Act entrent en application et la plateforme européenne de déclaration ouvre effectivement.
Le fil rouge de S37–S38 est donc moins la multiplication des vulnérabilités que l’accélération du cycle d’attaque : accéder, comprendre, exploiter, pivoter et agir peut désormais se dérouler de plus en plus vite, parfois à travers des composants auxquels l’organisation accorde justement sa confiance.
Cisco ISE : CVSS 10.0, contournement d’authentification et exploitation active
Le 16 septembre 2026, Cisco a publié CVE-2026-76460, une vulnérabilité critique affectant Cisco Identity Services Engine — ISE — et ISE-PIC, indépendamment de leur configuration.
Son score est maximal : CVSS 10.0.
Le problème se situe dans le contrôle d’authentification d’un endpoint API. Un attaquant distant non authentifié peut envoyer une requête spécialement construite et contourner l’authentification de l’interface d’administration web. Cisco confirme en outre que la vulnérabilité fait l’objet d’une exploitation active.
Pourquoi ISE n’est pas un serveur comme un autre
ISE se trouve précisément dans l’une des zones les plus sensibles d’une architecture réseau : la décision de confiance.
Selon les déploiements, la plateforme intervient notamment dans :
- l’authentification des utilisateurs et équipements ;
- l’autorisation d’accès au réseau ;
- le contrôle des politiques ;
- le profilage des terminaux ;
- les mécanismes 802.1X ;
- les politiques NAC ;
- et l’intégration avec d’autres services d’identité.
Compromettre un tel système signifie donc potentiellement atteindre non pas seulement une application, mais l’infrastructure qui décide qui a le droit d’accéder à quoi.
Cisco précise qu’après exploitation, l’attaquant peut atteindre un niveau permettant l’exécution de commandes avec des privilèges root. À ce niveau de compromission, l’acteur peut également supprimer ou masquer des éléments de preuve, raison pour laquelle Cisco recommande de ne pas limiter l’investigation aux journaux présents sur l’équipement et de croiser les données avec des logs réseau et pare-feu externes.
Corriger ne suffit pas nécessairement
Il n’existe aucun workaround permettant de corriger la vulnérabilité. Cisco recommande les versions corrigées correspondant aux branches ISE 3.1 à 3.5 ; une mitigation temporaire consiste à utiliser des infrastructure ACL afin de limiter strictement le trafic destiné aux interfaces de management et de contrôle.
Mais puisque l’exploitation est déjà confirmée, la question opérationnelle ne doit pas être uniquement :
« Avons-nous installé le patch ? »
Elle doit également être :
« L’équipement a-t-il été compromis avant l’installation du patch ? »
Cisco recommande d’ailleurs de rechercher les indicateurs dans les access.log de chaque nœud d’un déploiement distribué et, lorsque l’activité malveillante est suspectée, de réinstaller les nœuds concernés puis de restaurer la configuration depuis une sauvegarde fiable.
Lecture CyberWatch
La criticité réelle de cette vulnérabilité provient de la combinaison :
exploitation active + absence d’authentification + privilèges élevés + fonction IAM/NAC de l’actif.
C’est presque la définition d’un point de concentration de confiance.
Une règle simple devrait s’appliquer :
les systèmes qui attribuent ou valident les droits d’accès doivent bénéficier d’un niveau de protection supérieur aux systèmes auxquels ils donnent accès.
Cisco Secure Email Gateway : un simple message peut mener jusqu’au root
Deux jours auparavant, le 14 septembre, Cisco avait publié CVE-2026-76461, affectant Cisco Secure Email Gateway.
Le score est de 9.8 en CVSS 3.1 et l’exploitation active est confirmée par Cisco.
Le mécanisme est particulièrement intéressant.
La vulnérabilité se trouve dans la logique d’analyse des messages électroniques d’AsyncOS. Un attaquant distant non authentifié peut envoyer un email contenant des instructions SQL spécialement construites. Une exploitation réussie permet d’exécuter des commandes arbitraires avec les privilèges root du système sous-jacent.
Autrement dit, le vecteur normal de fonctionnement de l’équipement — recevoir des emails en provenance de l’extérieur — devient lui-même le vecteur permettant de l’attaquer.
La passerelle de sécurité devient la cible
Une Secure Email Gateway existe précisément pour filtrer :
- spam ;
- phishing ;
- malware ;
- pièces jointes ;
- URLs ;
- et autres contenus indésirables avant qu’ils n’atteignent les utilisateurs.
Sa position en bordure du SI signifie qu’elle doit nécessairement recevoir du trafic non fiable.
C’est ce qui rend cette vulnérabilité particulièrement sensible :
l’équipement conçu pour examiner le contenu hostile peut lui-même être compromis par ce contenu.
La situation rappelle pourquoi un produit de sécurité ne doit jamais être considéré comme intrinsèquement sûr simplement parce qu’il appartient à la catégorie « sécurité ».
Un pare-feu, un VPN, une gateway email, un EDR, un bastion ou une console de sécurité restent des logiciels exposés à des vulnérabilités.
Et leur compromission peut être particulièrement grave parce qu’ils disposent souvent de visibilité, privilèges et confiance élevés.
Des conséquences possibles au-delà d’un seul équipement
Cisco recommande notamment de rechercher dans les mail_logs des instructions SQL suspectes et de vérifier également les logs réseau externes, car un attaquant disposant de root peut effacer ou dissimuler des traces présentes sur l’appliance elle-même.
Dans les environnements en cluster, le problème devient encore plus sérieux : les appliances utilisent des paires de clés SSH pour s’authentifier entre elles. Cisco indique qu’une compromission peut permettre l’accès aux clés SSH privées, ouvrant potentiellement la voie à la compromission d’autres membres du cluster. Lorsqu’une appliance d’un cluster est compromise, Cisco recommande donc la restauration sécurisée de l’ensemble des membres concernés.
Il n’existe aucun workaround. Les branches corrigées sont notamment 15.5.5-014, 16.0.4-302 et 16.5.0-780, Cisco recommandant la migration vers 16.5.0-780 lorsque cela est possible.
Lecture CyberWatch
Deux vulnérabilités Cisco très différentes apparaissent donc dans la même fenêtre :
- ISE contrôle qui peut accéder ;
- Secure Email Gateway contrôle ce qui peut entrer.
Et toutes deux sont activement exploitées.
La leçon dépasse Cisco :
les infrastructures qui filtrent, authentifient ou autorisent doivent faire partie des toutes premières catégories couvertes par la veille de vulnérabilités et le patching d’urgence.
Première notification à l’AEPD d’une violation de données impliquant un agent IA
Le 14 septembre, l’Agencia Española de Protección de Datos — AEPD a publié un signal particulièrement important.
L’autorité indique avoir reçu sa première notification d’une violation de données personnelles dans laquelle l’incident aurait été exécuté à l’aide d’un agent d’intelligence artificielle utilisant un modèle de langage connu.
La prudence est indispensable.
L’AEPD précise elle-même que les informations disponibles proviennent de la notification effectuée par l’organisation victime et doivent encore être analysées. Le cas ne permet donc ni de tirer des conclusions définitives sur l’incident ni d’établir une tendance statistique.
Mais le scénario déclaré mérite une attention particulière.
Selon les informations communiquées à l’autorité, l’agent aurait commencé par rechercher des vulnérabilités, réalisé un accès valide au système, puis poursuivi de façon autonome l’exploration de l’application jusqu’à identifier des faiblesses lui permettant de modifier des données personnelles et de consulter des factures.
Ce qui change réellement avec un agent
L’IA générative classique répond à une demande.
Un agent peut aller plus loin :
- recevoir un objectif ;
- décomposer cet objectif ;
- choisir des actions intermédiaires ;
- utiliser des outils ;
- interpréter le résultat ;
- adapter sa stratégie ;
- puis poursuivre le processus.
Appliqué à la cybersécurité offensive, le changement fondamental n’est donc pas nécessairement l’apparition de techniques entièrement nouvelles.
Les techniques peuvent rester connues :
- reconnaissance ;
- recherche de vulnérabilités ;
- authentification ;
- exploration ;
- exploitation ;
- accès aux données.
Ce qui change est la capacité à enchaîner ces étapes rapidement et de manière adaptative.
L’identité devient encore plus importante
Le cas rapporté par l’AEPD comprend un point essentiel : un login valide aurait été utilisé avant la poursuite autonome de l’attaque.
Cette observation rejoint directement un enjeu IAM classique.
Une clé API, un token, un compte utilisateur ou un compte de service trop privilégié peut fournir à un agent exactement ce dont il a besoin pour opérer à travers plusieurs systèmes.
Avec l’IA agentique, le principe du moindre privilège prend donc une dimension supplémentaire :
un droit excessif n’est plus seulement exploitable par une personne ou un script ; il peut être exploité à la vitesse d’un agent capable d’enchaîner automatiquement les actions.
Une précision importante sur le modèle utilisé
L’AEPD précise que l’utilisation d’un modèle d’IA particulier ne signifie pas que le modèle ou l’infrastructure de son fournisseur ait été compromis, ni que l’outil ait été conçu à des fins malveillantes.
Le sujet est donc l’usage offensif d’une capacité généraliste, pas nécessairement une compromission du fournisseur d’IA.
Lecture CyberWatch
Ce cas ne prouve pas que les agents IA dominent désormais la cybercriminalité.
Il indique quelque chose de plus raisonnable et néanmoins important :
un scénario jusqu’ici principalement discuté comme risque émergent commence à apparaître dans les mécanismes formels de notification d’incidents.
Cela devrait pousser les organisations à revoir :
- les scénarios de risque ;
- les délais de détection ;
- la gestion des identités ;
- les clés et tokens ;
- les limitations d’API ;
- la journalisation ;
- et les capacités automatisées de confinement.
Lorsque l’attaquant peut opérer à vitesse machine, une réponse exclusivement humaine risque d’arriver trop tard.
PhantomRaven : packages npm malveillants et probable assistance d’un LLM
Le 15 septembre, CrowdStrike a publié son analyse de PhantomRaven, un infostealer JavaScript distribué à travers des packages malveillants sur npm.
CrowdStrike estime avec un haut niveau de confiance que le malware a probablement été écrit à l’aide d’un grand modèle de langage. Cette appréciation repose notamment sur le style très verbeux des commentaires, la présence de code placeholder et l’analyse statistique de certains patterns de tokens. Il s’agit donc d’une évaluation analytique de CrowdStrike, pas d’une preuve directe de la génération du code par un LLM.
La campagne elle-même n’a pas commencé pendant ces deux semaines : CrowdStrike décrit des activités remontant notamment à 2025. Ce qui est nouveau dans notre fenêtre est la publication de l’analyse technique détaillée le 15 septembre.
Un mécanisme supply chain particulièrement instructif
CrowdStrike a notamment identifié les packages npm :
transform-jsbi-to-bigint- et
sort-imports-es6-autofix.
Les packages visibles contiennent peu de code manifestement malveillant. Mais ils référencent une dépendance distante via une URL HTTP contrôlée par l’attaquant.
Lors de l’installation, npm récupère cette dépendance externe. Le package retourné contient alors le payload PhantomRaven ainsi qu’un script preinstall permettant son exécution.
Nous ne sommes donc pas face au schéma le plus simple :
« le package téléchargé contient directement le malware ».
La chaîne ressemble davantage à :
package apparemment banal → dépendance distante → infrastructure attaquante → payload → script d’installation → exécution.
Pourquoi les développeurs deviennent une cible stratégique
Un poste de développement peut contenir :
- tokens Git ;
- identifiants cloud ;
- clés SSH ;
- credentials npm ;
- secrets CI/CD ;
- accès à des dépôts privés ;
- variables d’environnement ;
- API keys ;
- et parfois des accès directs vers les environnements de test ou production.
Compromettre le développeur peut donc permettre de remonter toute la chaîne logicielle.
Après Gitea en S35 et JFrog Artifactory en S36, PhantomRaven ajoute une troisième pièce au tableau :
repository source → artefacts → dépendances.
La supply chain logicielle n’est plus un sous-sujet de la sécurité applicative.
Elle devient une infrastructure à protéger en tant que telle.
Un changement intéressant dans npm
CrowdStrike souligne qu’à partir de npm 12, les scripts preinstall présents dans certaines dépendances sont bloqués par défaut sauf autorisation explicite du développeur.
C’est un bon exemple de Secure by Default.
Plutôt que d’attendre que chaque développeur sache identifier tous les packages malveillants, l’écosystème réduit par défaut la capacité d’une dépendance à exécuter automatiquement du code.
C’est exactement le type de contrôle qu’une architecture de sécurité mature doit rechercher :
faire en sorte que le chemin dangereux demande une action explicite, plutôt que l’inverse.
Patch Tuesday : près d’un millier de vulnérabilités et deux zero-days déjà exploitées
Le 8 septembre, Microsoft a publié son cycle mensuel de mises à jour de sécurité.
Les différents décomptes publiés autour de cette édition varient légèrement selon la méthode utilisée, mais tous convergent sur un point : le volume approche le millier de vulnérabilités corrigées, un niveau exceptionnellement élevé. Le Centre canadien pour la cybersécurité confirme surtout l’information la plus importante opérationnellement : CVE-2026-81963 et CVE-2026-85880 étaient déjà exploitées, et CISA les a intégrées à son catalogue KEV le jour même.
CVE-2026-81963 — Windows Update Stack
CVE-2026-81963 affecte le Windows Update Stack.
La vulnérabilité repose notamment sur une résolution incorrecte de liens avant accès aux fichiers et permet à un attaquant déjà autorisé localement d’élever ses privilèges. Elle obtient un score CVSS de 7.8. CISA la classe comme activement exploitée.
CVE-2026-85880 — Windows ALPC
La seconde zero-day exploitée, CVE-2026-85880, concerne Windows Advanced Local Procedure Call — ALPC.
Il s’agit notamment d’un débordement de mémoire permettant à un attaquant disposant déjà d’un accès local limité d’élever ses privilèges. Son score est également de 7.8, mais CISA considère là encore l’exploitation comme active et l’impact technique potentiel comme total.
Deux 7.8 qui passent devant de nombreux 9 et 10
Ces deux vulnérabilités fournissent une nouvelle démonstration d’un principe que CyberWatch suit depuis plusieurs éditions :
CVSS ≠ priorité opérationnelle.
Un score de 7.8 assorti de preuves d’exploitation active peut justifier une action beaucoup plus rapide qu’un CVSS 10 sans exposition réelle dans l’environnement.
Avec près d’un millier de correctifs dans le même cycle, une organisation ne peut de toute façon plus simplement dire :
« patchons tout immédiatement ».
Elle doit savoir prioriser.
Un modèle de décision réaliste devrait croiser au minimum :
présence dans le parc + exploitation active + exposition + privilèges accessibles + criticité de l’actif + disponibilité d’un correctif.
Lecture CyberWatch
Le volume de vulnérabilités devient lui-même un problème de cybersécurité.
Lorsque les équipes reçoivent plusieurs centaines d’alertes, le risque n’est plus seulement de manquer une CVE.
C’est de ne plus savoir laquelle traiter d’abord.
La maturité de la gestion des vulnérabilités se mesure donc moins au nombre de bulletins suivis qu’à la capacité de transformer rapidement l’information en ordre de priorité adapté au parc réel.
Google Pixel : une vulnérabilité du modem fait l’objet d’une exploitation limitée et ciblée
Le 15 septembre, Google a publié le bulletin de sécurité de septembre pour ses appareils Pixel.
Parmi le nombre important de correctifs, une vulnérabilité se distingue : CVE-2026-58704.
Google indique disposer d'éléments montrant que la vulnérabilité pourrait faire l’objet d’une exploitation limitée et ciblée.
CVE-2026-58704 est classée comme vulnérabilité d’élévation de privilèges de sévérité élevée et concerne le modem. Les appareils Pixel supportés recevant le niveau de correctif 2026-09-05 ou ultérieur disposent de la correction.
Le modem n’est pas un simple périphérique
Dans un smartphone, le modem — ou baseband — constitue une zone particulièrement sensible.
Il gère l’interaction avec le réseau cellulaire et traite en permanence des données provenant d’une infrastructure radio extérieure au terminal.
La surface mobile doit donc être pensée comme plusieurs environnements imbriqués :
application → OS → composants privilégiés → firmware → modem → réseau radio.
Le bulletin Pixel illustre parfaitement cette profondeur : en plus de CVE-2026-58704, Google corrige plusieurs vulnérabilités critiques de type exécution de code à distance ou élévation de privilèges dans des composants liés notamment au modem, à la téléphonie, au bootloader, à l’IP Multimedia Subsystem et à l’environnement d’exécution sécurisé.
Lecture CyberWatch
Après les protections Android 17 contre les fausses stations de base étudiées dans S35, cette nouvelle alerte renforce un constat :
la sécurité mobile ne se limite pas aux applications et à Android.
Une partie importante du risque se situe en dessous de l’OS, dans des composants firmware ou radio qui disposent de privilèges élevés et restent invisibles à l’utilisateur.
Pour les environnements sensibles, un MDM ne devrait donc pas uniquement vérifier :
- mot de passe ;
- chiffrement ;
- applications autorisées.
Il devrait également contrôler le niveau de patch du terminal et empêcher progressivement les appareils trop anciens ou non maintenus d’accéder aux ressources les plus critiques.
Huit nouveaux avis ICS en une journée : réseau électrique, automates et infrastructures industrielles
Le 17 septembre, CISA a publié huit avis concernant les systèmes de contrôle industriels.
Ils couvrent notamment :
- Hitachi Energy FACTS Control Platform ;
- Schneider Electric Modicon M340 ;
- Schneider Electric NetBotz ;
- ABB Ability Edgenius ;
- Mitsubishi Electric GX Works3 ;
- ainsi que d’autres technologies industrielles.
Deux cas méritent particulièrement notre attention.
Hitachi Energy FACTS : jusqu’à CVSS 9.9 dans des systèmes de contrôle du réseau électrique
L’avis ICSA-26-260-03 concerne le FACTS Control Platform — FCP de Hitachi Energy lorsque le composant GWS est présent.
Le périmètre peut inclure des systèmes tels que :
- STATCOM ;
- compensateurs statiques de puissance réactive ;
- condensateurs série ;
- et autres équipements utilisés pour contrôler certains paramètres des réseaux électriques.
L’avis regroupe cinq vulnérabilités et les scores atteignent 9.9. Une exploitation peut affecter la confidentialité, l’intégrité et la disponibilité de la plateforme.
Pourquoi FACTS mérite une lecture particulière
Les systèmes FACTS interviennent dans la gestion de paramètres électriques tels que la tension, la puissance réactive et les flux sur le réseau de transport.
Nous revenons donc à une distinction essentielle entre IT et OT :
le système numérique ne traite pas seulement de l’information ; il participe au contrôle d’un processus physique.
Le niveau de risque ne doit donc jamais être déduit uniquement du CVSS.
Il faut ajouter :
- fonction industrielle ;
- position dans le procédé ;
- possibilités de fonctionnement en mode dégradé ;
- redondance ;
- conséquences sur la sûreté ;
- et possibilités réelles d’accès réseau.
Schneider Modicon M340 : un déni de service peut arrêter le contrôleur
Le même lot d’avis contient ICSA-26-260-04, concernant le Schneider Electric Modicon M340 et plusieurs modules de communication Ethernet.
La vulnérabilité CVE-2025-6625, évaluée à 7.5, concerne le service FTP : une commande spécialement construite peut provoquer un déni de service du contrôleur ou du module. Le vecteur est réseau, de faible complexité, sans authentification ni interaction utilisateur.
Encore une fois, 7.5 ne signifie pas nécessairement « faible priorité ».
Si le PLC contrôle :
- une pompe ;
- une chaîne de production ;
- un procédé énergétique ;
- un système de dosage ;
- ou un autre équipement essentiel,
- sa disponibilité peut avoir une valeur opérationnelle largement supérieure à celle suggérée par son score CVSS.
Lecture CyberWatch
L’OT exige une approche où la vulnérabilité technique est toujours replacée dans son contexte physique.
La question n’est pas uniquement :
« peut-on compromettre le système ? »
mais également :
« que se passe-t-il dans le procédé lorsque ce système ne répond plus ou répond incorrectement ? »
Kenya : les nouvelles règles des cybercafés entrent en vigueur
Le 7 septembre 2026, de nouvelles conditions de licence concernant les cybercafés et autres Public Communication Access Centres sont entrées en vigueur au Kenya.
Les règles avaient été publiées au Journal officiel le 7 août, avec un délai réglementaire de trente jours avant leur prise d’effet.
Les exploitants doivent notamment :
- vérifier leurs clients ;
- afficher les tarifs applicables ;
- délivrer des reçus pour les services payants ;
- et conserver certaines informations de base nécessaires au respect des conditions de licence.
L’objectif affiché est notamment de disposer d’une trace d’audit lorsqu’un accès Internet public est impliqué dans une activité illicite, dans un contexte de hausse des fraudes numériques, escroqueries en ligne et infractions liées à l’identité.
Mais pas d’historique de navigation
La Communications Authority of Kenya a pris soin de clarifier un point important : les exploitants ne sont pas tenus de conserver l’historique de navigation des utilisateurs.
Cette précision est essentielle parce qu’elle place immédiatement la réglementation au croisement de deux objectifs qui peuvent entrer en tension :
- traçabilité cyber ;
- et
- protection de la vie privée.
L’objectif d’une politique de sécurité ne devrait pas être de collecter le maximum d’informations possible « au cas où ».
Il devrait être de collecter ce qui est réellement nécessaire pour atteindre l’objectif défini, de le protéger correctement et de ne pas le conserver plus longtemps que nécessaire.
Lecture CyberWatch
Le sujet pourrait sembler modeste comparé aux vulnérabilités Cisco ou aux agents IA.
Il touche pourtant un enjeu très africain : dans de nombreux environnements, l’accès à Internet continue d’être partagé à travers des infrastructures publiques ou semi-publiques.
La cybersécurité nationale doit donc intégrer non seulement les datacenters, opérateurs et infrastructures critiques, mais également les points d’accès par lesquels les citoyens entrent réellement dans l’espace numérique.
La difficulté consiste à construire de la traçabilité sans transformer cette traçabilité en surveillance disproportionnée.
Rwanda : capacité nationale et diffusion rapide des alertes
Le 9 septembre, la National Cyber Security Authority du Rwanda a annoncé la formation du premier groupe de 24 enseignants TVET spécialisés en cybersécurité, dans le cadre d’un programme conduit avec le Rwanda TVET Board et l’Organisation internationale du Travail.
La semaine suivante, le Rw-CSIRT a parallèlement relayé rapidement plusieurs alertes opérationnelles concernant notamment les correctifs Microsoft, les vulnérabilités Cisco et cPanel.
La combinaison est intéressante :
former les compétences + exploiter une veille opérationnelle + diffuser rapidement les alertes.
Un CERT national n’est réellement utile que lorsque l’information mondiale sur les menaces est transformée en décision exploitable pour l’écosystème local.
Nigeria : ngCERT multiplie les alertes ciblées
Le 11 septembre, le Nigeria Computer Emergency Response Team a notamment publié des alertes sur une vulnérabilité critique de cPanel & WHM, sur une zero-day Chrome exploitée dans la nature, sur VMware ainsi que sur plusieurs autres sujets nécessitant une action immédiate des organisations nigérianes.
Le signal institutionnel mérite d’être relevé.
La maturité cyber nationale n’est pas uniquement visible dans les lois, stratégies ou grands centres opérationnels.
Elle est également visible dans une fonction plus quotidienne :
voir le risque international → le qualifier → le contextualiser → alerter les acteurs nationaux → recommander une action.
C’est cette continuité opérationnelle qui transforme progressivement un CERT national en véritable instrument de résilience.
Le temps disponible pour défendre se réduit
Ces deux semaines présentent des événements technologiquement très différents.
Mais leur rapprochement montre quelque chose de cohérent.
Cisco ISE peut décider qui entre sur le réseau.
Cisco Secure Email Gateway décide ce qui entre par la messagerie.
Une dépendance npm entre dans ce que le développeur considère comme du code légitime.
Un agent IA peut potentiellement enchaîner des tâches qui demandaient auparavant plusieurs actions humaines.
Une zero-day Windows peut transformer un accès initial limité en privilèges élevés.
Une vulnérabilité modem rapproche encore l’attaque du système radio.
Et dans l’OT, l’action informatique peut produire une indisponibilité physique.
Le facteur qui change progressivement n’est donc pas seulement la sophistication.
C’est la vitesse.
L’automatisation de l’attaque réduit :
- le temps entre reconnaissance et exploitation ;
- le temps entre accès initial et mouvement latéral ;
- le temps entre découverte d’un secret et son utilisation ;
- le temps entre identification d’une vulnérabilité et exploitation à grande échelle.
La réponse doit évoluer en conséquence.
Une cybersécurité fondée uniquement sur :
- revues mensuelles ;
- analyse manuelle des journaux ;
- patching trimestriel ;
- validation humaine de chaque alerte ;
- et réaction après constat,
- risque d’être structurellement trop lente.
L’objectif ne doit toutefois pas être « automatiser toute la sécurité ».
Il faut automatiser ce qui peut l’être sans perdre le contrôle :
- détection ;
- corrélation ;
- enrichissement ;
- priorisation ;
- isolement dans certains scénarios ;
- rotation de secrets ;
- révocation de sessions ;
- et collecte forensique.
L’avantage défensif de demain dépendra autant de la vitesse de décision que de la qualité des outils.
11 septembre : le Cyber Resilience Act entre dans sa première phase réellement opérationnelle
Cette fois, nous n’y sommes plus à J-19, J-12 ou J-5.
L’échéance est passée.
Le 11 septembre 2026, les obligations de notification prévues par le Cyber Resilience Act sont devenues applicables aux fabricants de produits comportant des éléments numériques concernés. Le même jour, ENISA a officiellement mis en service la première capacité opérationnelle de la CRA Single Reporting Platform — SRP.
Les fabricants doivent désormais notifier via cette plateforme :
- les vulnérabilités activement exploitées ;
- et
- les incidents graves ayant un impact sur la sécurité de leurs produits.
La plateforme permet d’effectuer une déclaration unique destinée ensuite aux autorités compétentes et CSIRT concernés, plutôt que de multiplier directement les notifications nationales.
Les délais deviennent réels
Le mécanisme de notification du CRA prévoit notamment une alerte précoce sous 24 heures après prise de connaissance de certains événements, puis une notification plus complète dans les délais prévus par le règlement.
Ce qui était jusque-là un sujet de préparation devient donc un processus opérationnel.
À partir du 11 septembre, une entreprise concernée qui découvre une vulnérabilité activement exploitée ne doit plus seulement se demander :
« comment allons-nous corriger ? »
Elle doit simultanément pouvoir répondre à :
Quand en avons-nous eu connaissance ?
Qui a qualifié l’événement ?
Est-il reportable ?
Qui effectue la notification ?
Quelles informations possédons-nous déjà ?
Quelles mesures avons-nous prises ?
Comment conservons-nous la chronologie ?
Une nuance importante
Le CRA n’est pas encore entièrement applicable.
Ses principales obligations générales de cybersécurité produit s’appliqueront à partir du 11 décembre 2027. ENISA précise également que les obligations correspondantes visant les open-source software stewards au titre de l’article 24(3) s’appliqueront à cette même date.
Depuis le 11 septembre 2026, ce sont donc spécifiquement les obligations de notification des fabricants qui franchissent leur jalon opérationnel.
Cette distinction est essentielle pour éviter de résumer incorrectement la situation par :
« le CRA est entré en vigueur ».
Le CRA était déjà en vigueur juridiquement.
Ce sont certaines de ses obligations qui deviennent progressivement applicables selon le calendrier prévu.
Lecture CyberWatch
Cette entrée en application change quelque chose de profond dans la sécurité produit.
Pendant longtemps, découvrir une vulnérabilité signifiait principalement :
- comprendre ;
- corriger ;
- publier éventuellement un advisory.
Désormais, pour les organisations concernées, il faut également savoir :
détecter → qualifier → horodater → décider → notifier → corriger → documenter.
La gestion des vulnérabilités devient donc simultanément :
- une discipline technique ;
- un processus juridique ;
- un processus de gouvernance ;
- et une capacité opérationnelle d’incident response.
| Priorité | Action | Enjeu |
|---|---|---|
| CRITIQUE | Identifier immédiatement les Cisco ISE / ISE-PIC vulnérables, appliquer les versions corrigées et rechercher des traces d’exploitation | CVSS 10.0, contournement d’authentification et exploitation active |
| CRITIQUE | Mettre à niveau les Cisco Secure Email Gateway et examiner les mail_logs, flux réseau externes et éventuels clusters |
RCE root sans authentification et exploitation active |
| CRITIQUE | Déployer les correctifs Microsoft de septembre en donnant la priorité à CVE-2026-81963 et CVE-2026-85880 | Deux vulnérabilités activement exploitées |
| ÉLEVÉE | Mettre à jour les appareils Pixel et contrôler le niveau de patch via MDM pour les terminaux sensibles | Vulnérabilité modem faisant l’objet d’une exploitation limitée et ciblée |
| ÉLEVÉE | Auditer les dépendances npm, scripts d’installation, postes développeurs et secrets CI/CD | PhantomRaven montre la valeur stratégique de la supply chain de développement |
| ÉLEVÉE | Vérifier l’exposition des environnements OT concernés par les avis du 17 septembre | Vulnérabilités touchant automates et systèmes participant directement à des procédés physiques |
| STRUCTURANTE | Ajouter les scénarios d’attaque assistée ou exécutée par agents IA aux analyses de risques | Les chaînes d’attaque peuvent désormais être automatisées et adaptées plus rapidement |
| IAM | Réduire les privilèges des comptes de service, clés API et tokens et améliorer leur rotation/révocation | Les agents et automatisations peuvent amplifier très rapidement l’effet d’un identifiant compromis |
| CRA | Vérifier que le processus de notification est opérationnel et testé | Les obligations de notification sont applicables depuis le 11 septembre |
1. L’identité devient une cible de premier rang
Cisco ISE montre qu’une faiblesse touchant l’infrastructure qui décide des accès peut avoir un rayon d’impact supérieur à celui d’un serveur applicatif ordinaire.
2. Les équipements de sécurité restent des logiciels attaquables
Secure Email Gateway peut être compromis par ce qu’il est précisément chargé d’analyser : un message venant de l’extérieur.
3. L’IA agentique commence à apparaître dans les incidents formellement déclarés
Le cas AEPD reste à analyser et ne constitue pas encore une tendance statistique, mais il matérialise un scénario jusqu’ici essentiellement prospectif.
4. La supply chain logicielle reste sous pression
Après Gitea et Artifactory, PhantomRaven montre que les dépendances elles-mêmes peuvent devenir un mécanisme de distribution de malware.
5. Exploitation active doit peser davantage que le CVSS seul
Les deux zero-days Microsoft exploitées sont évaluées à 7.8. Cela ne les empêche pas d’être prioritaires face à certaines vulnérabilités notées 9 ou 10 mais non exploitables dans le contexte réel.
6. Le risque mobile descend jusqu’au modem
Le bulletin Pixel rappelle que la surface d’attaque existe également sous l’OS, au niveau du firmware, de la téléphonie et des composants radio.
7. L’OT continue de relier cybersécurité et monde physique
Dans un réseau électrique ou un environnement industriel, disponibilité et intégrité des systèmes peuvent directement influencer le fonctionnement du processus réel.
8. En Afrique, cybersécurité et gouvernance descendent progressivement jusqu’au terrain
Le Kenya réglemente les points publics d’accès à Internet tandis que Rwanda et Nigeria renforcent la diffusion opérationnelle des alertes et le développement des capacités.
9. Le CRA n’est plus une échéance future
Depuis le 11 septembre, les premières obligations de notification sont effectivement applicables et la plateforme ENISA est opérationnelle.
10. Le facteur temps devient central
Agents IA, automatisation offensive, vulnérabilités exploitées et supply chain réduisent progressivement le délai entre découverte d’une faiblesse et impact réel.
La défense doit donc devenir non seulement plus robuste, mais également plus rapide.
Sources principales
Cisco ISE — CVE-2026-76460 — Cisco PSIRT, Identity Services Engine Authentication Bypass Vulnerability, 16 septembre 2026.
Cisco Secure Email Gateway — CVE-2026-76461 — Cisco PSIRT, avis initial du 14 septembre et mise à jour du 17 septembre 2026.
Agent IA / violation de données — Agencia Española de Protección de Datos, publication du 14 septembre 2026 ; informations corroborées par Reuters.
PhantomRaven / npm — CrowdStrike Counter Adversary Operations, analyse publiée le 15 septembre 2026.
Microsoft Patch Tuesday — Centre canadien pour la cybersécurité, bulletin du 8 septembre 2026 ; données CVE Microsoft/CISA.
Google Pixel / CVE-2026-58704 — Android Open Source Project, Pixel Update Bulletin, 15 septembre 2026.
OT / ICS — CISA, série de huit avis industriels publiée le 17 septembre 2026, dont Hitachi Energy FACTS Control Platform et Schneider Electric Modicon M340.
Kenya — Communications Authority of Kenya, nouvelles conditions applicables aux Public Communication Access Centres à compter du 7 septembre 2026.
Rwanda — National Cyber Security Authority / Rw-CSIRT, formation du premier groupe d’enseignants TVET cyber et alertes de septembre.
Nigeria — ngCERT, alertes et avis opérationnels du 11 septembre 2026.
Cyber Resilience Act — ENISA, mise en service de la Single Reporting Platform et application des premières obligations de notification le 11 septembre 2026.
CyberWatch — comprendre les signaux, mesurer les impacts, anticiper les risques.