Microsoft publie une CVE Teams CVSS 10.0 sans version affectée ni correctif documenté
CVE-2026-65667 est une élévation de privilèges non authentifiée dans Microsoft Teams, classée CVSS 10.0, publiée le 6 août 2026 hors cycle Patch Tuesday. L’avis ne précise ni le composant affecté ni la build corrigée — ce que les RSSI doivent faire en attendant.
Le 6 août 2026, Microsoft a publié CVE-2026-65667 en dehors de son cycle mensuel Patch Tuesday. L’avis décrit une élévation de privilèges non authentifiée dans Microsoft Teams avec un score CVSS 10.0 — le maximum théorique. Trois jours plus tard, le 8 août, Microsoft n’a toujours pas précisé quel composant de Teams est affecté, ni quelle build corrige la vulnérabilité.
Le vecteur CVSS est sans ambiguïté : AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Traduction opérationnelle : un attaquant distant, sans authentification, sans interaction utilisateur, peut obtenir un accès en lecture et écriture à des ressources situées hors du périmètre de sécurité initial de Teams. Le changement de scope (S:C) indique que la compromission franchit une frontière d’autorité de sécurité — typiquement, un accès cross-tenant ou une escalade depuis un contexte utilisateur standard vers un contexte administratif.
Un avis de sécurité qui ne permet pas d’agir
Le problème immédiat n’est pas la vulnérabilité elle-même — c’est l’absence de données opérationnelles dans l’avis. Le Security Update Guide de Microsoft confirme la faille et sa classification, mais n’en dit pas plus. Aucune build Teams corrigée n’est listée. Aucun article de la base de connaissances (KB) n’est rattaché. Aucune indication ne permet de savoir si la correction est côté service (Microsoft 365) ou côté client.
Dans un environnement d’entreprise réel, cette absence crée une impasse. « Teams » peut désigner l’application de bureau Windows, le client macOS, les clients mobiles, le client web, un service cloud Microsoft 365, ou une interaction entre plusieurs de ces composants. Chacun a son propre modèle de déploiement et de correctif. Sans précision, un administrateur ne peut pas :
- Déterminer si son parc est exposé
- Établir une requête de conformité dans son inventaire
- Planifier un déploiement de correctif
- Documenter une exception vérifiée
Le National Vulnerability Database (NVD) et le registre public du programme CVE n’avaient pas encore indexé CVE-2026-65667 au 8 août 2026 — un délai normal après publication, mais qui fait de l’avis Microsoft la seule source publique exploitable.
Ce que le vecteur CVSS révèle (et ce qu’il cache)
Le score CVSS 10.0 place cette vulnérabilité au sommet absolu de l’échelle. Mais la granularité des métriques raconte une histoire plus nuancée.
Ce qui est établi :
- AV:N — L’attaque est réalisable depuis n’importe quel réseau accessible à Teams (Internet dans la quasi-totalité des déploiements)
- AC:L — La complexité d’attaque est faible : pas de condition préalable complexe
- PR:N — Aucun privilège n’est requis : l’attaquant n’a pas besoin de compte
- UI:N — Aucune interaction utilisateur : pas de piège à clic, pas d’ingénierie sociale
- S:C — Le scope change : l’impact franchit la frontière du composant vulnérable
- C:H / I:H — Confidentialité et intégrité à impact élevé : l’attaquant peut lire ET modifier
Ce qui n’est pas établi :
- Le composant précis : client Windows, client web, service backend ?
- L’exploitabilité réelle : Microsoft n’a pas publié l’Exploitability Index
- La criticité selon EPSS (Exploit Prediction Scoring System) : le score n’a pas encore été calculé par FIRST
- Le statut dans le catalogue CISA KEV (Known Exploited Vulnerabilities) : aucune entrée au 8 août
La combinaison PR:N + UI:N + S:C est la signature d’une vulnérabilité qui peut être exploitée à grande échelle par un acteur automatisé. C’est cette combinaison, et non la note 10.0 en elle-même, qui doit déclencher une réponse prioritaire.
Pourquoi une publication hors cycle sans détails est un signal
Microsoft publie rarement des CVE hors Patch Tuesday sans documentation complète. Quand cela arrive, deux scénarios sont plausibles :
- Divulgation externe imminente — Un chercheur ou un éditeur de sécurité a prévu de publier des détails, et Microsoft anticipe pour fournir un identifiant CVE avant la divulgation publique
- Correction en cours de déploiement — La vulnérabilité est corrigée côté service et Microsoft attend la fin du déploiement pour documenter la build client, mais publie le CVE pour permettre aux organisations de tracer le risque
Le second scénario est le plus probable pour une vulnérabilité Teams côté service. Microsoft déploie les correctifs des services cloud de manière continue, et la publication du CVE avant la documentation complète peut simplement refléter un décalage de synchronisation entre l’équipe produit et l’équipe sécurité.
Ce que les RSSI doivent faire maintenant
En l’absence de correctif documenté, la posture à adopter est celle de la collecte de preuves et de la réduction de surface, pas celle du changement d’urgence non étayé.
Inventaire immédiat :
- Recenser tous les canaux de déploiement Teams en usage : Microsoft Store, Intune, Configuration Manager, images VDI, installations classiques résiduelles
- Vérifier que le client Teams actuel peut recevoir des mises à jour dans la configuration managée de l’organisation, particulièrement si le Microsoft Store est bloqué ou si les mises à jour sont différées
Réduction de surface conservatoire :
- Auditer les rôles administratifs Teams, les paramètres d’accès invité, les politiques de collaboration externe et les comptes Microsoft 365 privilégiés
- Restreindre temporairement l’accès invité et la fédération externe si le niveau de risque de l’organisation le justifie — sans présenter cette mesure comme une mitigation validée par Microsoft
Veille active :
- Monitorer quotidiennement l’entrée du Security Update Guide de Microsoft pour CVE-2026-65667
- Surveiller l’apparition éventuelle de l’entrée dans le catalogue CISA KEV — une inscription signifierait une exploitation active confirmée
- Conserver les versions actuelles des clients Teams et les journaux de mise à jour pour établir rapidement la conformité dès qu’une build corrigée est publiée
La quatrième mesure est contre-intuitive mais essentielle : ne pas fermer le ticket. Une CVE non documentée qui disparaît du backlog parce que « Teams semble à jour sur un échantillon de postes » est une CVE qui ressurgira au pire moment.
La question que Microsoft doit trancher
L’avis actuel est un identifiant, pas un advisory. Il remplit le minimum requis par le programme CVE — un identifiant, une description, une date de publication — mais aucun des critères opérationnels qui permettent à une équipe de sécurité de transformer une alerte en action.
Microsoft doit répondre à trois questions dans les prochains jours :
- Quel composant de Teams est affecté : client, service, ou les deux ?
- Quelle build ou mise à jour corrige la vulnérabilité ?
- Une exploitation active a-t-elle été observée ?
Jusqu’à ce que ces réponses soient publiques, CVE-2026-65667 reste un risque non quantifiable dans un produit présent dans la quasi-totalité des environnements Microsoft 365. Ce n’est pas une raison de paniquer — c’est une raison d’être prêt à agir dès que l’information arrivera.