Tour d'horizon de l'actualité cyber — Semaine du 17 août

Voici les principales actualités que vous avez manquées la semaine dernière.

1. GitLab : La vulnérabilité CVE-2026-19478 permet à n'importe quel attaquant non authentifié de supprimer définitivement ou de réécrire tous les projets publics d'une instance auto-hébergée

Le titre : GitLab a divulgué la CVE-2026-19478 le 17 août, a critical code injection vulnerability in GitLab Community Edition and Enterprise Edition that allows any unauthenticated attacker to remotely modify or delete publicly accessible projects and rewrite their data. The flaw, which carries a CVSS score of 9.4, is exploitable via a GraphQL directive with no credentials, no user interaction, and no special configuration required. Affected versions span GitLab CE and EE 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4. Patches shipped in versions 19.2.4, 19.1.6, 19.0.8, and 18.11.11. WatchTowr confirmed active exploitation within days of public disclosure.

Ce que nous sommes en train de regarder : Supprimer ou réécrire un projet GitLab public n'est pas l'attaque. C'est la partie visible d'une capacité plus vaste. Un attaquant capable de modifier les données d'un projet peut empoisonner des dépôts, écraser des scripts de compilation, remplacer des artéfacts de version et réécrire l'historique des commits, le tout sans jamais s'authentifier. Il ne s'agit pas d'une vulnérabilité de vol de données. C'est une vulnérabilité de la chaîne d'approvisionnement logicielle déguisée en faille d'injection de code.

La confirmation par WatchTowr d'une exploitation active quelques jours seulement après la divulgation suit le même calendrier que GeoServer la semaine dernière et TeamCity en juillet. Le délai entre la publication d'un correctif par GitLab et l'intégration de l'exploit par les attaquants dans les outils de scan se mesure désormais en jours, et non plus en semaines. Les organisations qui exécutent des instances autohébergées de GitLab CE ou EE et qui n'ont pas appliqué les correctifs de cette semaine doivent auditer l'activité récente des projets publics à la recherche de modifications non autorisées et vérifier que les artéfacts de version correspondent aux signatures attendues avant le prochain cycle de déploiement.

La question du RSSI : Pour chaque instance GitLab auto-hébergée de votre environnement, avez-vous appliqué les correctifs du 17 août, examiné les journaux d'audit récents à la recherche d'événements de modification non authentifiés dans les dépôts publics, et confirmé que les artéfacts de construction publiés depuis le 17 août correspondent aux signatures attendues et n'ont pas été produits à partir d'une base de code altérée ?

2. Microsoft : CoSnitch a transformé la mémoire persistante de Copilot en un canal d'exfiltration de données, et une RCE critique dans Entra ID a été discrètement corrigée le même jour

Le titre : Varonis Threat Labs a divulgué CoSnitch, suivi sous la référence CVE-2026-24301, le 18 août, une vulnérabilité de Copilot Personal qui combine un paramètre d'URL non documenté, la capacité intégrée de récupération d'URL de Copilot et sa fonction de mémoire persistante pour exfiltrer silencieusement des données de comptes liés, notamment Gmail et Google Drive, après un seul clic de l'utilisateur. Les données volées sont déguisées en trafic de navigation sortant habituel. Une variante à mémoire empoisonnée peut persister malgré les réinitialisations de mot de passe et la réinscription des appareils. Microsoft a corrigé la faille et n'a trouvé aucune preuve d'exploitation avant le correctif. Varonis a découvert la vulnérabilité par le biais du méta-piratage, en demandant à plusieurs reprises à Copilot pourquoi l'attaque n'était pas possible jusqu'à ce que les explications du modèle révèlent le paramètre non documenté exact nécessaire. Le même jour, Microsoft a divulgué CVE-2026-69836, une vulnérabilité critique d'exécution de code à distance d'une sévérité maximale dans Entra ID, notée 10,0, avant de corriger par la suite le statut d'exploitation en “ non exploité dans la nature ” après que The Hacker News a contacté Microsoft pour obtenir un commentaire.

Ce que nous sommes en train de regarder : CoSnitch est la deuxième technique d'exfiltration de données par assistant IA divulguée ce mois-ci, après GhostApproval la semaine du 6 juillet. Le schéma est cohérent : les outils d'IA qui détiennent des connexions OAuth aux plateformes de productivité, avec une mémoire ou un état persistant, créent des canaux d'exfiltration qui ressemblent à du trafic d'application normal. Le cas de Copilot est particulièrement notable car Varonis a extrait l'exploit en interrogeant le modèle lui-même. Les propres explications de l'IA sur les raisons pour lesquelles l'attaque ne pouvait pas fonctionner ont révélé précisément comment la faire fonctionner.

La correction du CVE-2026-69836 d'Entra ID est l'autre volet de cette affaire. Microsoft a divulgué une vulnérabilité RCE critique dans Entra ID en la qualifiant d'exploitée, avant de modifier discrètement ce statut en “ non exploitée ” après avoir été contacté par la presse. Que la divulgation initiale ait été une erreur ou que la correction ait manqué de preuves, cet incident illustre un problème auquel les équipes de sécurité sont confrontées à chaque Patch Tuesday : les évaluations de l'exploitabilité par les éditeurs ne sont fiables dans aucun des deux sens. La surveillance des canaux Telegram du dark web par CybelAngel fournit un signal indépendant indiquant si une vulnérabilité nouvellement divulguée fait l'objet de discussions actives et est exploitée, indépendamment des caractérisations des fournisseurs.

La question du RSSI : Pour chaque assistant IA que votre organisation a déployé avec des connexions OAuth aux plateformes de productivité, considérez-vous ces outils comme des utilisateurs privilégiés nécessitant des audits d'accès, et disposez-vous d'une surveillance capable de détecter lorsque le trafic sortant médié par l'IA transporte des données exfiltrées à partir de comptes connectés plutôt que de remplir sa fonction prévue ?

3. VMware : Un groupe APT lié à la Chine a déployé le ransomware Babuk via CVE-2026-59310 dans vCenter alors que les équipes de défense lisaient encore les notes de correctif

Le titre : Broadcom and Palo Alto Networks Unit 42 confirmed on August 17 that a suspected China-nexus advanced persistent threat actor exploited CVE-2026-59310, a CVSS 9.8 directory traversal vulnerability in VMware vCenter Server that enables unauthenticated arbitrary code execution, to deploy a Babuk-derived ransomware variant across victim environments. Broadcom patched CVE-2026-59310 in late July. Active exploitation targeting specifically vCenter Server infrastructure began within weeks of the patch, with Unit 42 attributing the campaign to a cluster they track as UNC5325 based on tooling and infrastructure overlaps with prior Chinese state-sponsored intrusions. Shadowserver tracks more than 4,200 internet-exposed vCenter Server instances globally.

Ce que nous sommes en train de regarder : Un acteur de la menace lié à la Chine déployant des rançongiciels par le biais d'une vulnérabilité vCenter n'est pas un comportement typique parrainé par un État. Les acteurs étatiques attribués à la Chine ont historiquement privilégié l'espionnage et la persistance à long terme plutôt que les attaques destructrices ou motivées par des intérêts financiers. L'utilisation d'un rançongiciel dérivé de Babuk suggère soit un objectif de perturbation délibérée, soit une opération sous fausse bannière, soit l'implication de cybercriminels affiliés opérant aux côtés de l'infrastructure étatique, le même modèle hybride documenté lors de la collaboration du groupe Lazarus avec le rançongiciel Play en 2024.

La surface d'attaque de vCenter présente un danger disproportionné car vCenter gère l'infrastructure de virtualisation plutôt que des systèmes individuels. Une seule instance compromise de vCenter offre un contrôle administratif sur chaque machine virtuelle s'exécutant sur chaque hôte qu'elle gère. Les organisations qui considèrent vCenter comme un outil de gestion interne à exposition limitée ont fréquemment tort : 4 200 instances sont accessibles via Internet selon Shadowserver, et beaucoup d'autres sont accessibles par le biais d'un VPN compromis ou de positions adjacentes au réseau, que l'historique des intrusions antérieures de UNC5325 montre qu'elles ciblent systématiquement.

La question du RSSI : Pour chaque déploiement de vCenter Server dans votre environnement, avez-vous appliqué les correctifs de fin juillet pour la vulnérabilité CVE-2026-59310, confirmé que votre interface de gestion vCenter n'est pas accessible depuis Internet, et examiné les journaux d'activité de création, de suppression et de prise de clichés (snapshots) de machines virtuelles à la recherche de signes d'accès non autorisé avant ou après l'application du correctif ?

4. Unisoc : Une chaîne d'exploitation en deux étapes obtient un accès complet au noyau Android via un appel vidéo VoLTE, sans correctif disponible de la part du fabricant de la puce

Le titre : SSD Secure Disclosure a publié le 17 août la deuxième étape d'une chaîne d'exploitation complète du noyau Android ciblant les appareils exécutant un micrologiciel de modem Unisoc. La chaîne en deux étapes, dont la première a été divulguée en mars 2026, permet d'obtenir un accès complet au noyau sur les appareils Android concernés par le biais d'un appel vidéo VoLTE, ce qui signifie que l'attaque nécessite uniquement que le numéro de téléphone de la cible soit connu et que l'appareil accepte les appels vidéo sur LTE. Aucune interaction de l'utilisateur n'est requise en dehors de la réception de l'appel. Unisoc n'a pas publié de correctif. La vulnérabilité affecte les appareils équipés de puces Unisoc, qui sont largement déployés sur les combinés Android d'entrée de gamme dans les marchés émergents et sur certains appareils de milieu de gamme vendus dans le monde entier sous plusieurs marques de fabricants d'équipements d'origine (OEM).

Ce que nous sommes en train de regarder : Une exploitation complète du noyau en zéro clic transmise par un appel téléphonique est la classe de vulnérabilité mobile de plus haute gravité. Elle n'exige rien de la part de la cible, si ce n'est un numéro de téléphone actif. L'absence de correctif de la part du fabricant de puces est structurellement le même problème que le micrologiciel de routeur en fin de vie : le fournisseur n'a ni mécanisme ni incitation pour corriger, les équipementiers manquent de ressources en ingénierie pour développer des correctifs indépendants, et les utilisateurs finaux n'ont aucun moyen de remédier au problème, si ce n'est de remplacer leur appareil.

Le chipset Unisoc ne se trouve pas dans les appareils d'entreprise haut de gamme, mais il apparaît fréquemment sur les téléphones personnels des employés dans les régions où les combinés Android économiques constituent la catégorie d'appareils principale. Les organisations dotées de politiques BYOD qui ne restreignent pas le chipset de l'appareil ou la version du micrologiciel n'ont aucune visibilité pour savoir si les appareils personnels de leurs employés utilisent des modems Unisoc, et aucune voie de remédiation le cas échéant. Le modèle de menace ici n'est pas l'exploitation de masse. Il s'agit d'une attaque ciblée contre des individus spécifiques dont les numéros de téléphone sont connus et dont les appareils exécutent par hasard le micrologiciel concerné.

La question du RSSI : Pour les employés de votre organisation qui utilisent des appareils Android personnels dans le cadre d'une politique BYOD pour accéder à la messagerie professionnelle, aux applications de messagerie ou au VPN, avez-vous une visibilité sur le jeu de puces et le micrologiciel de l'appareil, et vos politiques de gestion des appareils mobiles tiennent-elles compte des exploits du noyau « zéro-clic » qui ne peuvent pas être corrigés par une mise à jour logicielle ?

5. Microsoft Power Pages : Une campagne mondiale de mauvaise configuration a exposé des millions d'enregistrements par le biais d'une fonctionnalité de la plateforme qui est configurée par défaut avec un accès public

Le titre : Les chercheurs d'AppOmni résultats publiés cette semaine documentant une exposition généralisée de données dans les déploiements Microsoft Power Pages, avec des millions de registres exposés à l'échelle mondiale en raison de permissions de tables mal configurées qui autorisent par défaut l'accès public anonyme. Les données exposées comprennent des noms, des adresses e-mail, des numéros de téléphone, des adresses domiciliaires et, dans certains cas, des informations financières partielles provenant d'organisations des secteurs de la santé, du gouvernement, de l'éducation et des services financiers. Il ne s'agit pas d'un CVE. Il n'y a aucune vulnérabilité dans Power Pages lui-même. L'exposition résulte du fait que des organisations déployant Power Pages utilisent les paramètres par défaut de Microsoft sans comprendre que ces paramètres par défaut rendent les tables de base de données accessibles au public pour tout utilisateur non authentifié qui interroge l'API de la plateforme.

Ce que nous sommes en train de regarder : Les configurations SaaS ouvertes par défaut génèrent une catégorie d'exposition qui se situe en dehors du cadre traditionnel de la gestion des vulnérabilités. Il n'y a pas de CVE à corriger. Il n'y a pas d'avis de l'éditeur à appliquer. La plateforme fonctionne exactement comme elle a été conçue. Les organisations dont les données sont exposées fonctionnent exactement comme leurs administrateurs les ont configurées. La mauvaise configuration est invisible pour l'analyse standard des vulnérabilités parce que le logiciel n'a aucun dysfonctionnement.

Power Pages est la plateforme low-code de Microsoft permettant de créer des portails web externes. Elle est fréquemment déployée par des équipes non chargées de la sécurité, notamment des départements marketing, des services RH et des agences gouvernementales, pour créer des formulaires et des portails destinés aux clients qui se connectent directement aux bases de données Dataverse. Les personnes qui déplorent ces portails n'ont généralement pas de formation en sécurité et ne comprennent pas que les paramètres d'autorisation de table par défaut de Microsoft autorisent un accès API public à chaque enregistrement dans les tables connectées. AppOmni a identifié ce schéma dans des organisations au Royaume-Uni, aux États-Unis et dans plusieurs autres régions, l'exposition du gouvernement britannique ayant fait l'objet d'une attention particulière de la part du NCSC.

La question du RSSI : Votre organisation utilise-t-elle Microsoft Power Pages et, le cas échéant, avez-vous audité les autorisations de table sur chaque portail déployé afin de confirmer que les tables Dataverse contenant des données personnelles ou sensibles ne sont pas accessibles aux utilisateurs anonymes via l'API par défaut de la plateforme, et disposez-vous d'un processus pour examiner les déploiements de plateformes SaaS effectués par des équipes non chargées de la sécurité avant leur mise en service ?

Le schéma commun aux cinq histoires

Tous les incidents de cette semaine ont atteint des systèmes que les organisations n'avaient pas pensé à surveiller.

GitLab’s public repositories were reachable by anyone on the internet and audited by nobody. Copilot’s persistent memory held OAuth connections to productivity platforms and was treated as a feature, not an attack surface. vCenter sat above thousands of virtual machines and was reachable from the public internet on 4,200 instances. Unisoc modem firmware ran on employees’ personal phones under BYOD policies that never asked which chipset was inside. Power Pages portals were deployed by non-security teams against databases that defaulted to public access.

CybelAngel finds what is exposed across your external attack surface before someone with worse intentions finds it first.