Certificats eMudhra : le risque persiste sur macOS
Git, curl et Python sur macOS feraient encore confiance à des certificats eMudhra compromis. Comprenez le risque et vérifiez vos outils.
Certificats eMudhra : pourquoi Git sur macOS reste exposé
Selon un signalement publié le 28 octobre 2026, onze jours après qu'Apple a été alertée d'un incident touchant l'autorité de certification eMudhra, la confiance accordée à des certificats associés à plusieurs outils de développement inclus avec macOS n'était toujours pas corrigée. Git, curl et Python 3 seraient encore susceptibles d'accepter une chaîne de certificats compromise. Et, d'après le signalement, la mise à jour macOS 27.2 (publiée le 26 octobre) aurait même annulé certaines corrections faites manuellement par des utilisateurs.
Ce n'est pas un simple bug de navigateur. Si un outil accepte un certificat frauduleux, un attaquant capable d'intercepter ou de détourner une connexion réseau peut se faire passer pour un serveur HTTPS. Concrètement, pour un développeur, cela peut aboutir à un code téléchargé depuis une source altérée, à un échange trompé lors d'un clone ou, pire, à des identifiants envoyés par erreur.
Le signalement explique ce qu'il faut surveiller, dans quels cas le risque devient réel, comment tester les outils concernés, et quelles précautions prendre sans casser votre configuration.
Ce que le signalement affirme sur macOS
Le signalement décrit un problème de confiance dans des certificats utilisés par certains outils en ligne de commande. En théorie, quand un programme se connecte à un site HTTPS, il vérifie que le certificat présenté remonte à une autorité reconnue et que la chaîne de certification est valide. Si ça ne passe pas, la connexion devrait être refusée.
Or, d'après le signalement, des certificats liés à l'incident eMudhra seraient encore acceptés via le magasin de confiance utilisé par des outils fournis avec macOS. Un serveur contrôlé par un attaquant pourrait alors présenter un certificat frauduleux dont la chaîne aboutit à une autorité que l'outil continue de considérer comme fiable.
Le problème concerne des outils précis
L'alerte vise notamment Git, curl et Python 3 dans leur configuration telle qu'elle est fournie avec macOS. Elle ne dit pas que toutes les applications Apple sont touchées de la même façon. Le signalement indique qu'Apple aurait déjà mieux protégé Safari et d'autres applications qui reposent sur son framework réseau, alors que ces outils en ligne de commande continueraient à faire confiance aux certificats en cause.
C'est un point important : macOS ne suit pas forcément un schéma unique de validation TLS pour tous les logiciels. Le fait qu'un site s'ouvre correctement dans Safari ne prouve pas que Git ou curl vérifient les certificats de la même manière.
Une mise à jour peut annuler une correction manuelle
Le signalement affirme aussi que macOS 27.2 (publié le 26 octobre 2026) n'aurait pas corrigé le problème et aurait rétabli une configuration vulnérable chez des personnes ayant appliqué un contournement manuel. Dit autrement : une « correction » faite localement peut sauter après une mise à jour.
Le signalement recommande qu'Apple retire les autorités concernées du fichier /etc/ssl/cert.pem. À ce stade, c'est une recommandation rapportée, pas une validation indépendante de l'état de chaque version ou configuration. Avant toute action, vérifiez ce qui est réellement en place sur vos outils, et suivez les consignes de sécurité les plus récentes pour votre système.
Quels risques pour Git et les outils de développement
Le risque ne vient pas uniquement du fait qu'un certificat soit compromis. Pour que l'attaque marche, l'attaquant doit aussi pouvoir se placer sur le chemin réseau, détourner le trafic, ou influencer la résolution et le routage. Selon le contexte (réseau hostile, équipement compromis, configuration interne...), c'est envisageable, mais ce n'est pas équivalent à « tout le monde peut intercepter n'importe quelle connexion » à distance sans autre condition.
Si le trafic est intercepté et que Git accepte le faux certificat, l'attaquant peut se faire passer pour le serveur distant. Selon l'opération et la configuration, il peut renvoyer un contenu différent lors d'un clone ou d'une récupération, modifier ce qui circule en transit, ou chercher à récupérer des informations sensibles envoyées par le client.
Le risque côté Git
Récupérer un dépôt via une URL HTTPS, c'est souvent un point d'entrée direct dans votre chaîne de développement. Une réponse manipulée peut vous amener à regarder ou à utiliser un code qui n'est pas celui attendu. Et le problème ne s'arrête pas au dépôt : il peut se répercuter aux dépendances, aux scripts de build et aux artefacts générés ensuite.
Les identifiants comptent aussi. Un jeton GitHub (ou d'autres infos d'authentification) ne doit jamais être exposé à un serveur de test ou à un hôte non vérifié. L'exemple publié dans l'alerte insiste d'ailleurs sur ce point avec un identifiant fictif : pour votre diagnostic, évitez de lancer un clonage qui pourrait envoyer vos identifiants vers une destination inconnue.
Le risque côté curl et Python
curl sert à récupérer des archives, appeler des API, ou télécharger des artefacts de déploiement. Si la validation TLS accepte un faux certificat, la réponse peut être altérée sans avertissement visible selon le contexte et la façon dont vos scripts gèrent les erreurs. Un script Python qui s'appuie sur les mêmes certificats (ou sur une configuration comparable) peut, lui aussi, parler à un serveur usurpé.
En entreprise, les conséquences peuvent dépasser le poste individuel. Un Mac utilisé pour le développement, l'intégration continue ou la compilation peut produire des livrables à partir d'entrées détournées. L'idée est donc de recenser les Mac impliqués dans vos pipelines, vos runners CI et vos environnements de build, puis d'évaluer quels accès et quels secrets y résident.
Que faire en attendant un correctif Apple
Commencez par identifier les machines réellement concernées par vos usages. Un Mac qui clone des dépôts, télécharge des dépendances ou publie des versions mérite une priorité plus élevée qu'un poste qui ne fait pas ce type de travail. En entreprise, incluez aussi les runners macOS et les machines de compilation : elles peuvent stocker des jetons, des certificats de signature ou des accès à des dépôts privés.
Ne modifiez pas le magasin de certificats à l'aveugle
Le signalement indique que les racines affectées peuvent être retirées manuellement de /etc/ssl/cert.pem, mais il ne fournit pas de liste complète et reproductible des entrées à supprimer ici. Modifier un bundle sans cibler précisément les certificats concernés peut casser des connexions légitimes et donner une fausse impression de sécurité.
Si vous appliquez un contournement, utilisez une procédure vérifiée, adaptée à votre version de macOS. Gardez une copie de l'état initial, documentez chaque étape, puis refaites les tests Git et curl après modification. Sur une machine gérée, évitez de contourner les outils de gestion de parc : coordonnez l'intervention avec l'équipe responsable.
Réduire l'impact sur les projets
En attendant un correctif confirmé, privilégiez des mesures qui réduisent l'exposition sans désactiver TLS :
- Évitez les réseaux non fiables pour des opérations sensibles, comme la récupération de code ou la rotation de secrets.
- Ne désactivez jamais la vérification des certificats « pour que ça ne fasse plus d'erreur ».
- Limitez les jetons disponibles sur les machines de build au strict nécessaire, et révoquez ceux qui ne servent plus.
- Surveillez les changements inattendus dans les dépôts et les artefacts récupérés pendant la période concernée.
- Pour les pipelines critiques, envisagez une configuration d'exécution qui vérifie explicitement la chaîne de certificats avec des outils approuvés par votre équipe sécurité.
Ces mesures ne remplacent pas une correction du problème de confiance. Elles limitent surtout les conséquences possibles si une connexion est détournée.
Refaire les contrôles après chaque mise à jour
Le signalement indique que macOS 27.2 aurait annulé un contournement manuel : donc, inutile de tester une fois et d'oublier. Après chaque mise à jour, vérifiez à nouveau les versions installées et relancez les tests. Si le comportement change, réévaluez votre contournement avant de reprendre les opérations sensibles.
Pour les équipes, cette vérification peut s'intégrer à une checklist de mise à jour ou à un contrôle de conformité des machines de build. L'objectif n'est pas d'ajouter un contrôle « par habitude », mais de garder visible l'état de la chaîne TLS jusqu'à un correctif Apple confirmé.
Conclusion
Le signalement eMudhra met sur la table un point concret : la validation TLS peut varier entre les applications graphiques et les outils en ligne de commande sur un même Mac. Pour les équipes de développement, Git et curl comptent beaucoup parce qu'ils récupèrent du code et des artefacts qui alimentent ensuite les builds et les déploiements.
La réponse immédiate, c'est de tester les outils réellement utilisés, de protéger les secrets et de ne pas désactiver la validation TLS. Si vous faites des modifications manuelles sur le magasin de certificats, faites-les de façon précise, documentée, et revérifiez après chaque mise à jour. Pour les organisations, incluez les Mac et les runners CI dans l'évaluation de risque de la chaîne logicielle, puis attendez les correctifs Apple avant de considérer l'incident comme clos.
Comment vérifier Git et curl sur votre Mac
Le signalement propose des tests relativement simples, sans cloner de dépôt réel et sans fournir de jeton. L'objectif est de vérifier le comportement des outils installés sur votre machine. Faites-les dans un terminal, sans ajouter d'identifiants aux commandes, et sans désactiver la validation TLS.
Tester Git avec une requête de lecture
Exécutez :
D'après le signalement, un Git correctement protégé devrait renvoyer une erreur de certificat. Si la commande affiche une référence ou un identifiant de commit, le test suggère que Git accepte le certificat présenté et qu'il est potentiellement concerné.
Ce test vérifie la validation du certificat, pas le niveau de risque global de votre installation. Le résultat peut varier selon la version de Git, la configuration TLS, un proxy d'entreprise, ou un magasin de certificats personnalisé. Notez la version de macOS et de Git, ainsi que le message complet affiché, avant de partager le résultat avec votre équipe.
N'essayez pas de reproduire l'interception avec un dépôt privé ou un compte personnel. Une démonstration avec redirection vers un serveur de test peut convenir en laboratoire contrôlé, mais elle augmente le risque de divulguer des identifiants ou de récupérer un contenu non fiable. Pour démarrer, le test de lecture ci-dessus est plus adapté.
Tester curl
Le signalement propose aussi ces deux commandes :
Une erreur de certificat signifie, dans le cadre du test, que curl refuse la chaîne présentée. Si la requête aboutit, traitez ça comme un signal d'exposition et vérifiez les consignes applicables à votre version de macOS. En revanche, ne faites pas dire au résultat plus qu'il ne peut : un test réussi veut surtout dire que l'outil n'a pas rejeté le certificat de test dans ces conditions.
Interpréter les résultats avec méthode
Pour éviter de conclure trop vite après un seul essai :
En clair : traitez le test comme un signal technique à investiguer, pas comme un audit complet « toutes connexions, tous cas ».