eMudhra Intermediate CA Compromise
Description et impact de la vulnérabilité
Summary of Findings (Article de support)
- What happened: Le 20 octobre 2026, il a été révélé publiquement que les clés privées de huit autorités de certification intermédiaires eMudhra avaient été générées de manière incorrecte et pouvaient être récupérées à partir de leurs certificats publics. Les intermédiaires TLS concernés sont liés à deux autorités de certification racines : emSign ECC Root CA – G3 et AAA Certificate Services. Toute personne détenant ces clés peut potentiellement créer des certificats qui usurpent l’identité de n’importe quel site web ou service.
- Who is at risk: Les principaux navigateurs et systèmes d'exploitation (dont Mozilla, Google Chrome, Apple et Microsoft) bloquent déjà ces intermédiaires, et eMudhra les a révoqués. Le risque continu concerne les logiciels qui font encore confiance aux deux autorités de certification racine. Une exploitation potentielle nécessiterait qu’un attaquant soit positionné sur le chemin réseau d’une connexion affectée.
- No compromise detected: Notre enquête à ce jour n'a identifié aucun accès non autorisé, compromission ou exploitation liés à ce problème dans l'environnement Cloud Exchange ou dans le système d'entreprise interne.
Versions concernées
- CE v6.1.0, v6.0.1, v6.0.0, v5.1.2, v5.1.1, v5.1.0, v5.0.1, v5.0.0, v4.x, v3.x: Devrait être affecté de la même manière. L'action recommandée est également de mettre à niveau vers la version 7.0.
Versions corrigées
- CE v7.0: contient le correctif.
- Étant donné que les composants concernés par cette vulnérabilité sont des paquets au niveau de l’OS et de Python qui ne peuvent pas être mis à jour sur l’exécution de conteneur Docker existante, le changement ne peut pas être rétrocédé aux versions antérieures de CE.
Impact sur Cloud Exchange
Le composant principal de CE établit des connexions HTTPS sortantes vers les locataires Netskope et vers les systèmes tiers que les clients configurent via des plugins, tels que SIEM, ITSM et les services cloud. Il valide les certificats de serveur de ces connexions par rapport aux listes de confiance décrites ci-dessus. Une attaque réussie permettrait à un attaquant d'usurper l'identité de l'un de ces points de terminaison, de capturer des identifiants ou des jetons API, et de lire ou modifier les données en transit. La communication entre les propres composants de CE (IU, cœur, MongoDB et RabbitMQ) utilise des certificats générés par Cloud Exchange et n'est pas affectée.
Déploiement autonome
Le conteneur principal effectue ses connexions sortantes à partir d’un seul hôte. Un attaquant devrait se trouver sur le chemin réseau entre cet hôte et le point de terminaison.
Déploiement de la haute disponibilité (HA)
Chaque nœud effectue les mêmes connexions sortantes, de sorte que chaque nœud est exposé. Le trafic entre les nœuds s'effectue sur un réseau privé avec des certificats générés par Cloud Exchange et n'est pas affecté.
Cloud Exchange en tant que VM (OVA, VHDX, AWS, Azure, KVM, Hyper-V)
Les images de l’appliance contiennent le même composant central. L’exposition est la même que pour un déploiement autonome ou HA, selon la façon dont la VM est déployée.
Les contrôles réseau réduisent les risques, mais ne les éliminent pas. La remédiation permanente est constituée par les listes de confiance corrigées fournies dans CE v7.0.
Atténuation jusqu'à la mise à niveau
Conseils généraux pour les clients qui n'ont ni mis à niveau ni escaladé. Ces contrôles réduisent l'exposition. Ils ne remplacent pas la mise à niveau ou le correctif.
- Maintenez le chemin réseau entre Cloud Exchange et ses points de terminaison sous le contrôle du client, et limitez la sortie Cloud Exchange aux destinations requises (locataires Netskope et points de terminaison de plugin configurés).
- Lorsque Cloud Exchange accède à Internet via un proxy, assurez-vous que celui-ci valide les certificats en amont à l’aide de listes de confiance à jour.
- Appliquez le paquet d’AC mis à jour par le fournisseur du système d’exploitation sur l’hôte Cloud Exchange (sur Ubuntu 22.04, ca-certificates 20260816ubuntu0.22.04.1 ou version ultérieure). Cela protège les opérations au niveau de l’hôte telles que les tirages d’images. Cela ne modifie pas les listes de confiance à l’intérieur des conteneurs Cloud Exchange.
- Planifiez la mise à niveau vers la v7.0.
Options de mise à niveau/migration pour différentes versions de CE
| Version actuelle de CE | Voie de mise à niveau |
|---|---|
| v6.1.0 | v7.0.0 |
| v6.0.1 | v7.0.0 |
| v6.0.0 | v7.0.0 |
| v5.1.2 | v7.0.0 |
| v5.1.1 | v7.0.0 |
- Documentation sur la mise à niveau de Cloud Exchange pour la version 7.0 (containerized et VM).
- Si vous utilisez Cloud Exchange v5.1.0, v5.0.1 ou v5.0.0 dans un déploiement containerized, veuillez vous référer aux Étapes de mise à jour de Cloud Exchange v5.0.1 ou v5.1.0 conteneurisé vers Cloud Exchange v5.1.1 conteneurisé dans les articles de la base de connaissances de Cloud Exchange.
- Si vous exécutez Cloud Exchange v5.1.0, v5.0.1 or v5.0.0 en tant que VM, reportez-vous à Étapes de mise à jour du déploiement autonome de machine virtuelle Cloud Exchange v5.0.1 ou v5.1.0 vers le déploiement autonome de machine virtuelle Cloud Exchange v5.1.1 dans les articles de la base de connaissances Cloud Exchange.
- Si vous mettez à jour Cloud Exchange en tant que VM à partir de v5.1.0, v5.0.1 or v5.0.0, mettez d'abord à niveau le système d'exploitation Ubuntu sous-jacent vers la version 22.04 (voir Articles de la base de connaissances Cloud Exchange 20.04 à 22.04), puis mettez à niveau le système d'exploitation Ubuntu vers la version 24.04 (voir Articles de la base de connaissances Cloud Exchange 22.04 à 24.04). Pour un déploiement containerized, utilisez les versions de système d'exploitation listées dans les Configuration système requise pour Cloud Exchange.
- Si vous utilisez Cloud Exchange v3.x ou v4.x, reportez-vous à la section Étapes de mise à niveau de Cloud Exchange v3.x ou v4.x conteneurisé vers Cloud Exchange v5.0.1 conteneurisé dans les articles de la base de connaissances Cloud Exchange.
MongoDB incorrect length handling in Zlib-compressed Protocol Headers
Description et impact de la vulnérabilité
MongoDB a identifié une faille de sécurité liée à une mauvaise gestion de la longueur des en-têtes de protocole compressés par Zlib. Dans des conditions spécifiques, ce problème peut amener le serveur MongoDB à lire une mémoire de tas non initialisée.
La vulnérabilité peut être déclenchée par un client non authentifié, mais nécessite un accès au réseau interne. L'exploitation de l'internet public n'est pas possible dans les configurations par défaut.
La vulnérabilité affecte les versions suivantes de MongoDB :
- MongoDB Server 7.0 avant 7.0.28
- MongoDB Server 8.0 avant 8.0.17
- MongoDB Server 8.2 avant 8.2.3
- MongoDB Server 6.0 avant 6.0.27
- MongoDB Server 5.0 avant 5.0.32
- MongoDB Server 4.4 avant 4.4.30
- MongoDB Server 4.2, 4.0 et 3.6 (versions prises en charge)
Déploiement autonome
- Définition :
- MongoDB fonctionne dans un Docker internal network.
- Le port du service MongoDB est not exposed pour la VM ou les réseaux externes.
- Exigence relative à la méthode d'exploitation :
- L'exploitation n'est possible que si un attaquant obtient privileged access to the Docker network within the VM.
Déploiement de la haute disponibilité (HA)
- Définition :
- Les déploiements HA basés sur le cloud utilisent un site private IP network, comme recommandé.
- Les déploiements HA sur site fonctionnent également exclusivement sur un private network.
- Exigence relative à la méthode d'exploitation :
- Une exploitation réussie nécessiterait qu'un attaquant obtienne access to the private network utilisé pour la communication avec MongoDB.
L'architecture de déploiement et les contrôles d'isolation du réseau dans Cloud Exchange réduisent considérablement le risque global. La vulnérabilité de MongoDB n'entraîne pas d'exposition directe aux réseaux publics et nécessite un accès préalable au réseau pour être exploitée.
Cloud Exchange will upgrade MongoDB to version 8.0.17, which includes the security fix.
Pour les versions 5.x à 6.0.0 de Cloud Exchange, Les équipes de Netskope recommandent plusieurs options pour éviter cette vulnérabilité dans un réseau docker en Standalone, et dans un réseau privé en HA.
Déploiement autonome pour la v5.0.1 (dépréciée), v5.1.0, v5.1.1, v5.1.2, v6.0.0, v6.0.1 et v6.1.0
- Accédez au répertoire d'installation de Cloud Exchange (pour CE en tant que VM, accédez à /opt/cloudexchange/cloudexchange).
- Arrêtez Cloud Exchange en utilisant cette commande : sudo ./stop
- Mettez à jour le fichier docker-compose . yml (Ubuntu et déploiement basé sur Docker) ou podman-compose.yml (RHEL et déploiement basé sur Podman) avec ces instructions dans les sections mongodb-primary du fichier yml, puis enregistrez le fichier.
v6.0.0 Standalone
Before the yml file v6.0.0 update
Add this argument after the mongod keyword in the entrypoint section of the mongodb-primary.
--networkMessageCompressors snappy,zstd
After the yml file v6.0.0 update
v5.1.2, v5.1.1 Autonome
Before the yml file v5.1.2, v5.1.1 update
Add this argument after the mongod keyword in entrypoint section of the mongodb-primary.
--networkMessageCompressors snappy,zstd
After the yml file v5.1.2, v5.1.1 update
v5.0.1 (déprécié), v5.1.0 Autonome
Before the yml file v5.0.1, v5.1.0 update
Add this argument after the mongod keyword in entrypoint section of the mongodb-primary.
--networkMessageCompressors snappy,zstd
After the yml file v5.0.1, v5.1.0 update
Démarrez Cloud Exchange à l'aide de cette commande :
sudo ./start
Déploiement HA pour la v5.0.1 (dépréciée), v5.1.0, v5.1.1, v5.1.2, v6.0.0, v6.0.1 et v6.1.0
- Va dans le répertoire d’installation Cloud Exchange des nœuds secondaires (pour CE en tant que VM, va sur /opt/cloudexchange/cloudexchange).
- Arrêtez Cloud Exchange en utilisant cette commande pour tous les nœuds secondaires un par un : sudo ./stop
- Accédez au répertoire Cloud Exchange du nœud principal (Pour CE en tant que VM, accédez à /opt/cloudexchange/cloudexchange).
- Arrêtez Cloud Exchange en utilisant cette commande pour le nœud principal. sudo ./stop
- Mettez à jour le fichier docker-compose-ha.yml (Ubuntu et déploiement basé sur Docker) ou podman-compose-ha.yml (RHEL et déploiement basé sur Podman) avec ces instructions dans les sections mongodb-primary du fichier yml, et enregistrez le fichier dans tous les nœuds HA un par un.
v6.0.0 HA
Before the yml file v6.0.0 update
Add this argument after the mongod keyword in the entrypoint section of the mongodb-primary.
--networkMessageCompressors snappy,zstd
After the yml file v6.0.0 update
v5.1.2, v5.1.1 HA
Before the yml file v5.1.1, v5.1.2 update
Add this argument after the mongod keyword in the command section of the mongodb-primary.
--networkMessageCompressors snappy,zstd
After the yml file v5.1.1, v5.1.2 update
v5.0.1 (déprécié), v5.1.0 HA
Before the yml file v5.0.1, v5.1.0 update
Add this argument after the mongod keyword in the command section of the mongodb-primary.
--networkMessageCompressors snappy,zstd
After the yml file v5.0.1, v5.1.0 update
- Démarrez le nœud principal de Cloud Exchange à l'aide de cette commande : sudo ./start
- Démarrez les nœuds Cloud Exchange secondaires à l'aide de cette commande : sudo ./start