Infrastructures critiques, supply chain, radio : les dépendances sous pression

Synthèse de la semaine

Cette semaine, le risque cyber ne se concentre pas sur une seule technologie. Il apparaît surtout dans les dépendances qui permettent aux systèmes de fonctionner.

Un fournisseur d’équipements pour les réseaux d’eau est compromis et voit des données techniques potentiellement utiles à de futures attaques exfiltrées. Une plateforme de gestion de code source passe dans la catégorie des vulnérabilités activement exploitées. Une faille ownCloud corrigée depuis plusieurs années réapparaît dans des attaques réelles. Dans les transports, un calculateur de freinage automobile et un transpondeur AIS maritime montrent à quel point les vulnérabilités des systèmes embarqués peuvent dépasser le simple monde informatique.

Du côté des télécommunications, Android 17 renforce directement la défense contre les fausses stations de base et les rétrogradations vers la 2G. Et sur les accès réseau, NetScaler rappelle une nouvelle fois que les équipements placés à la frontière du SI restent parmi les cibles les plus sensibles.

Le fil rouge de S35 est donc clair : une organisation ne doit plus seulement protéger ce qu’elle possède. Elle doit comprendre et sécuriser ce dont elle dépend.

Micro-Comm : une cyberattaque contre un fournisseur peut préparer l’attaque suivante

Le 26 août 2026, Reuters a révélé que le FBI enquêtait sur une cyberattaque ayant touché Micro-Comm, entreprise américaine fournissant des technologies d’automatisation utilisées notamment dans le secteur de l’eau et de l’assainissement.

L’entreprise produit notamment des automates programmables industriels, ou PLC, utilisés dans des installations de traitement des eaux usées.

Le groupe ransomware Barracuda a revendiqué le vol d’environ 644 Go de données représentant quelque 850 000 fichiers. Selon les éléments disponibles, l’intrusion serait à ce stade considérée par le FBI comme opportuniste et ne serait pas directement reliée aux campagnes récemment observées contre les infrastructures d’eau américaines.

Le problème ne s’arrête toutefois pas à l’entreprise compromise.

Parmi les informations potentiellement exposées figureraient notamment des noms de clients publics et des schémas de systèmes. Même si les systèmes opérationnels des exploitants ne semblent pas avoir été directement compromis, de telles informations peuvent fournir à un attaquant une connaissance précieuse de l’environnement technique d’une future cible.

Lecture CyberWatch

C’est une illustration particulièrement claire du risque fournisseur dans les environnements OT.

Un exploitant peut correctement segmenter son réseau, contrôler ses comptes et protéger ses PLC. Mais si le fournisseur qui connaît son architecture, ses équipements, ses configurations ou ses plans techniques est compromis, une partie de cette connaissance peut quitter indirectement l’organisation.

La question de sécurité devient alors :

quelles informations sensibles mes fournisseurs détiennent-ils sur mon infrastructure ?

Cela peut concerner :

• les plans réseau
• les adresses IP
• les références des automates
• les configurations
• les procédures de maintenance
• les comptes techniques
• les versions firmware

ou encore les schémas d’interconnexion.

Une chaîne d’approvisionnement cyber ne se limite donc pas au logiciel que l’on installe.

Elle comprend également la connaissance technique que l’on confie à des tiers.

Priorité opérationnelle

Les exploitants d’infrastructures critiques devraient intégrer à leurs analyses de risques fournisseurs :

• la nature des informations techniques partagées
• leur durée de conservation
• les conditions d’accès
• les mécanismes de notification en cas d’incident

et les mesures à déclencher lorsque le fournisseur lui-même est compromis.

Gitea : une faille de la forge logicielle passe en exploitation active

Le 25 août 2026, CISA a ajouté CVE-2026-60004 à son catalogue Known Exploited Vulnerabilities — KEV, confirmant ainsi son exploitation dans des attaques réelles.

La vulnérabilité affecte Gitea avant la version 1.27.1. Elle concerne la fonctionnalité diffpatch et peut permettre l’installation d’un Git hook conduisant à l’exécution de commandes sur le serveur.

Pourquoi une forge Git est un actif critique

Une plateforme comme Gitea n’est pas uniquement un espace dans lequel sont stockés des fichiers sources.

Elle se situe potentiellement au centre du cycle de développement logiciel.

Selon l’architecture, elle peut donner accès à :

• code source
• historique des modifications
• branches de production
• jetons d’accès
• clés SSH
• secrets CI/CD
• pipelines
• artefacts

et mécanismes de déploiement.

La compromission de la forge peut donc transformer un accès initial en attaque de chaîne d’approvisionnement.

L’attaquant n’a plus nécessairement besoin d’attaquer directement chaque serveur de production.

Il peut chercher à modifier ce que l’organisation considère elle-même comme une source de confiance.

Lecture CyberWatch

Le véritable actif n’est pas seulement le dépôt Git.

C’est la chaîne de confiance entre le développeur, le dépôt, le pipeline et la production.

Une organisation qui protège fortement ses serveurs mais laisse sa forge de développement faiblement administrée crée une incohérence majeure dans son modèle de sécurité.

Priorité opérationnelle

Pour les organisations utilisant Gitea :

• mettre à jour vers une version corrigée
• identifier les instances exposées à Internet
• revoir les comptes et permissions
• contrôler les Git hooks
• vérifier les journaux d’activité

et surveiller les secrets ou clés susceptibles d’avoir été accessibles.

ownCloud : une vulnérabilité de 2023 redevient une urgence en 2026

Le 27 août 2026, CISA a ajouté CVE-2023-49105 à son catalogue KEV après confirmation de son exploitation active.

La vulnérabilité est pourtant connue depuis 2023.

Elle affecte ownCloud et peut, dans certaines configurations, permettre à un attaquant d’accéder, modifier ou supprimer des fichiers sans authentification, notamment lorsque le nom d’un utilisateur est connu et qu’aucune clé de signature appropriée n’est configurée. Son score CVSS 3.1 est de 9.8.

Des informations intégrées cette semaine au dossier CVE font également référence à des activités d’exploitation observées dans le contexte d’une organisation philippine liée à la recherche nucléaire.

Une CVE ancienne n’est pas une menace ancienne

Ce cas mérite d’être retenu pour une raison simple.

Nous avons souvent tendance à organiser la veille par date :

CVE récente = importante ;

CVE ancienne = problème probablement réglé.

La réalité opérationnelle est différente.

Une vulnérabilité reste actuelle tant qu’un actif vulnérable reste en production.

L’ancienneté du numéro CVE ne mesure ni l’exposition réelle ni l’intérêt qu’un attaquant peut encore lui porter.

Lecture CyberWatch

C’est précisément pourquoi le patch management doit être relié à un véritable inventaire des actifs.

Sans inventaire fiable, impossible de répondre rapidement à la question :

« avons-nous encore cette technologie quelque part ? »

Une organisation peut recevoir des centaines d’alertes de vulnérabilité. La valeur de sa gestion de vulnérabilités dépend surtout de sa capacité à déterminer en quelques minutes :

• si elle possède le produit
• où il se trouve
• quelle version est installée
• quelle donnée il héberge

et quelle exposition réseau il possède.

Bendix EC80 : quand une vulnérabilité informatique touche directement au freinage

Le 25 août, CISA a publié un avis concernant plusieurs vulnérabilités affectant le calculateur de freinage Bendix EC80 Brake ECU.

Les défauts identifiés comprennent notamment des problèmes de gestion mémoire.

Une exploitation réussie peut entraîner la perte de fonctions telles que :

ABS ;

assistance de direction ;

antipatinage ;

et d’autres fonctions liées au fonctionnement du véhicule.

Certaines vulnérabilités peuvent également permettre l’injection de trafic arbitraire sur le bus CAN, le réseau interne utilisé pour les communications entre calculateurs automobiles.

Cyber et sûreté commencent à se confondre

Dans un système bureautique, les objectifs traditionnels sont :

• confidentialité
• intégrité

disponibilité.

Dans un système embarqué contrôlant un véhicule, une quatrième dimension apparaît immédiatement :

la sûreté physique.

Altérer les données reçues ou envoyées par un calculateur de freinage ne représente plus seulement une perte d’intégrité informatique.

Cela peut modifier directement le comportement de la machine.

C’est exactement ce qui distingue progressivement la cybersécurité des systèmes embarqués de la sécurité IT classique.

Maritime — Furuno FA-50 : une vulnérabilité dans un transpondeur AIS en fin de vie

Toujours le 25 août, Furuno a confirmé une vulnérabilité affectant toutes les versions du transpondeur AIS Class B FA-50.

Un attaquant disposant d’un accès au réseau interne du navire peut manipuler l’interface de configuration et modifier notamment le numéro d’identification de l’équipement et d’autres informations.

Le point le plus intéressant est toutefois ailleurs.

La production du FA-50 a cessé en octobre 2020 et Furuno indique qu’aucune mise à jour logicielle ne sera fournie.

Le constructeur recommande de remplacer l’équipement par son successeur, le FA-70, ou, lorsque cela n’est pas possible, d’empêcher son exposition directe à Internet et de renforcer la maîtrise des accès au réseau interne du navire.

Lecture CyberWatch — le problème de l’équipement qui fonctionne encore

Ce cas résume parfaitement une difficulté majeure des infrastructures embarquées et industrielles.

Un équipement peut être :

• fonctionnel
• stable
• indispensable

et pourtant ne plus être maintenable du point de vue cyber.

Le fait qu’un matériel fonctionne encore n’implique donc pas qu’il soit raisonnable de continuer à l’exploiter.

C’est la notion de cyber-obsolescence.

Dans les environnements radio, maritime, industriel, IoT ou télécom, le cycle de vie de sécurité doit devenir un critère d’investissement au même titre que la disponibilité des pièces ou les performances techniques.

Android 17 : Google renforce directement la défense contre les fausses stations de base

Le 27 août 2026, Google a présenté quatre nouvelles protections réseau intégrées à Android 17.

Parmi elles figure une évolution particulièrement intéressante pour la sécurité des communications mobiles : les opérateurs participants pourront désormais configurer Android afin que la 2G soit désactivée par défaut pour leurs abonnés.

Pourquoi la 2G reste une surface d’attaque

Les réseaux mobiles récents disposent de mécanismes de sécurité beaucoup plus robustes que les générations précédentes.

Mais un attaquant disposant d’un dispositif radio adapté peut chercher à provoquer une rétrogradation de la connexion, en poussant le terminal à quitter LTE ou 5G pour utiliser la 2G.

Google cite notamment les SMS blasters : de fausses stations de base capables d’émettre avec suffisamment de puissance pour pousser des smartphones voisins à rejoindre un réseau 2G contrôlé par l’attaquant.

Une fois la rétrogradation obtenue, certaines protections modernes ne sont plus disponibles, facilitant notamment l’envoi de SMS frauduleux ou des attaques de type phishing.

Android permettait déjà depuis Android 12 de désactiver manuellement la 2G.

Android 17 va plus loin en permettant à l’opérateur de transformer cette défense en protection par défaut, sans action de l’utilisateur.

ECH : réduire également la fuite de métadonnées

Android 17 introduit aussi un support étendu de Encrypted Client Hello — ECH.

Même lorsque HTTPS chiffre le contenu d’une communication, certaines informations, comme le nom du domaine demandé, peuvent rester observables par un acteur présent sur le chemin réseau.

ECH vise précisément à réduire cette visibilité en chiffrant davantage les informations utilisées lors de l’établissement initial de la connexion HTTPS.

Android 17 renforce également le contrôle des applications cherchant à explorer le réseau local.

Lecture CyberWatch

Cette évolution illustre quelque chose d’important :

la cybersécurité télécom ne se limite pas au cœur de réseau de l’opérateur.

Elle dépend aussi du comportement du terminal radio.

La défense doit donc être pensée sur toute la chaîne :

réseau opérateur ↔ interface radio ↔ OS mobile ↔ application ↔ utilisateur.

Pour les pays dans lesquels la 2G reste encore fortement utilisée, la question devient toutefois plus complexe : désactiver une technologie vulnérable suppose d’avoir suffisamment modernisé la couverture et les terminaux pour ne pas créer un problème de disponibilité.

NetScaler : CVE-2026-8452 rejoint les vulnérabilités activement exploitées

Le 26 août 2026, CISA a ajouté CVE-2026-8452 au catalogue KEV.

La vulnérabilité affecte NetScaler ADC et NetScaler Gateway et repose sur un défaut de gestion mémoire pouvant provoquer un comportement imprévisible ou un déni de service. Elle obtient un score CVSS v4.0 de 8.8.

Sont particulièrement concernés les équipements configurés comme :

SSL VPN ;

ICA Proxy ;

CVPN ;

RDP Proxy ;

ou serveur virtuel AAA.

Le Centre canadien pour la cybersécurité a mis à jour son avis le 26 août après l’intégration de la CVE au KEV et recommande l’application des versions corrigées.

Pourquoi les gateways restent des cibles privilégiées

Une appliance VPN ou une gateway présente trois caractéristiques particulièrement attractives :

• elle est souvent accessible depuis Internet
• elle sert de point d’entrée vers le SI

et elle concentre des mécanismes d’authentification et de routage vers des ressources internes.

Sa fonction même en fait donc un actif prioritaire.

Le raisonnement doit être le même pour :

• VPN
• reverse proxies
• WAF
• passerelles d’administration
• portails d’accès distant

et équipements de bordure.

Une vulnérabilité activement exploitée sur un équipement exposé ne doit pas attendre le cycle mensuel normal de patching.

Rwanda : le CSIRT national relaie rapidement les vulnérabilités activement exploitées

Cette semaine, le Rwanda National Cyber Security Authority / Rw-CSIRT a publié plusieurs alertes opérationnelles intéressantes.

Le 25 août, l’autorité a notamment alerté sur CVE-2026-73570, vulnérabilité affectant Zimbra Collaboration Suite et faisant l’objet d’une exploitation active.

Le 26 août, elle a également publié une alerte sur CVE-2026-21962, vulnérabilité critique affectant Oracle HTTP Server et WebLogic Server Proxy Plug-in, également signalée comme activement exploitée.

Dans le cas de Zimbra, la vulnérabilité permet une injection de commandes sans authentification lorsque le composant SNMP optionnel concerné est installé et configuré. CISA l’avait ajoutée à son KEV le 21 août.

Lecture Afrique

Le signal est moins spectaculaire qu’une nouvelle loi ou une stratégie nationale, mais il est institutionnellement important.

Une capacité nationale cyber ne se mesure pas seulement au nombre de textes adoptés.

Elle se mesure aussi à la capacité d’un CSIRT national à transformer rapidement l’information internationale sur les menaces en alerte opérationnelle pour son propre écosystème.

Cela implique :

• veille
• qualification
• diffusion
• recommandation

et capacité de réponse.

C’est précisément ce passage de la connaissance à l’action que les dispositifs nationaux africains doivent progressivement renforcer.

La dépendance devient une surface d’attaque

Les événements de cette semaine paraissent différents.

Pourtant, ils posent presque tous la même question :

de quoi dépend notre système pour continuer à fonctionner et rester digne de confiance ?

L’exploitant d’une station d’eau dépend de son fournisseur OT.

Le développeur dépend de sa forge Git.

L’entreprise dépend de sa plateforme de fichiers.

Le véhicule dépend de ses calculateurs embarqués.

Le navire dépend de ses équipements radio et de navigation.

L’utilisateur mobile dépend du réseau radio et du système d’exploitation de son terminal.

L’entreprise distante dépend de sa passerelle VPN.

La cybersécurité moderne doit donc dépasser l’inventaire des seuls actifs possédés par l’organisation.

Il faut également construire une cartographie des dépendances :

• technologiques
• logicielles
• fournisseurs
• cloud
• télécoms
• radio
• énergétiques

et humaines.

Car une dépendance critique mal maîtrisée peut devenir un point de défaillance unique.

Cyber Resilience Act — J-12 avant les premières obligations de notification

À la clôture de cette édition, le 30 août 2026, il reste 12 jours avant le 11 septembre.

À cette date, les fabricants soumis au Cyber Resilience Act devront commencer à notifier les vulnérabilités activement exploitées ainsi que les incidents graves affectant la sécurité de leurs produits comportant des éléments numériques.

Le mécanisme prévoit notamment :

une alerte initiale dans les 24 heures ;

une notification complète dans les 72 heures ;

puis un rapport final selon la nature de l’événement.

Les notifications passeront par la CRA Single Reporting Platform exploitée par ENISA et annoncée opérationnelle pour le 11 septembre.

Le 30 août : un jalon de normalisation, mais prudence sur son statut

Le Rolling Plan européen 2026 prévoyait également pour le 30 août 2026 les premiers livrables relatifs au cadre horizontal du CRA et à la gestion des vulnérabilités.

À la clôture de cette édition, je ne considère toutefois pas cette échéance comme la preuve que des normes harmonisées définitives et immédiatement utilisables pour la présomption de conformité ont déjà été publiées.

La Commission indique plus largement que les premiers livrables de normalisation sont attendus au troisième trimestre 2026, dans le cadre de la demande M/606 portant sur 41 standards.

Cette distinction est importante.

Une date de livraison de travaux de normalisation n’est pas automatiquement synonyme de norme harmonisée déjà opposable ou publiée au Journal officiel.

1. La supply chain OT est aussi une supply chain d’information

La compromission d’un fournisseur peut révéler des architectures et données techniques utiles à de futures attaques, même lorsque le système industriel lui-même n’a pas été pénétré.

2. Le développement logiciel est devenu une infrastructure critique

Une forge Git compromise peut contaminer toute la chaîne qui lui fait confiance, du code jusqu’au déploiement.

3. Une vieille CVE peut redevenir l’urgence du jour

ownCloud rappelle qu’une vulnérabilité n’expire pas avec le temps. Elle disparaît lorsque le dernier actif vulnérable a été corrigé ou retiré.

4. L’embarqué rapproche cybersécurité et sûreté physique

Freinage automobile et AIS maritime montrent que l’impact cyber peut directement atteindre le comportement d’une machine ou la confiance accordée à ses informations.

5. La sécurité radio revient jusque dans le terminal

Avec Android 17, la lutte contre les fausses stations de base et les rétrogradations 2G devient progressivement une fonction de sécurité native.

6. Un équipement fonctionnel peut être cyber-obsolète

Le cas Furuno rappelle que la fin du support logiciel doit entrer dans la décision de renouvellement des équipements radio, IoT et industriels.

7. La résilience dépend aussi de ce que l’on ne contrôle pas directement

Fournisseurs, logiciels tiers, infrastructures cloud, réseaux, gateways et composants embarqués doivent apparaître dans la cartographie des risques au même titre que les actifs internes.

Sources principales

Infrastructures critiques / eau — Reuters, enquête sur la compromission de Micro-Comm, 26 août 2026.

Gitea — Centre canadien pour la cybersécurité / CISA KEV, CVE-2026-60004, 25 août 2026.

ownCloud — CISA KEV / CVE-2023-49105, ajout du 27 août 2026.

Transport / Bendix EC80 — CISA ICS advisory ICSA-26-237-05, 25 août 2026.

Maritime / Furuno — Furuno, avis de sécurité FA-50 Class B AIS Transponder, 25 août 2026.

Android 17 — Google Security Blog, protections réseau Android 17, 27 août 2026.

NetScaler — Centre canadien pour la cybersécurité / CISA KEV, CVE-2026-8452, mise à jour du 26 août 2026.

Afrique / Rwanda — National Cyber Security Authority / Rw-CSIRT, alertes des 25 et 26 août 2026.

Cyber Resilience Act — Commission européenne, obligations de notification et normalisation.

CyberWatch — comprendre les signaux, mesurer les impacts, anticiper les risques.