macOS Tahoe 26.6.1 : la faille de Screen Sharing et ce qu'il faut faire

Apple a publié macOS Tahoe 26.6.1 le jeudi 6 août 2026, dix jours après 26.6. Il n'y a eu aucune bêta développeur. Aucune bêta publique. Aucune nouvelle fonctionnalité, aucune mise à jour de Safari, aucun changement de firmware. Les notes de version décrivent un unique correctif de sécurité, et le document de sécurité liste exactement une CVE.

C'est cette combinaison qui fait l'histoire. Apple diffuse normalement une mise à jour mineure aux développeurs pendant au moins quelques jours avant de la publier, et une version x.x.1 embarque généralement une poignée de corrections de bugs en plus du travail de sécurité qu'elle contient. Celle-ci a totalement sauté l'étape de diffusion préalable et ne porte qu'un seul élément : CVE-2026-65400, dans le composant Screen Sharing. Apple a rétroporté le même correctif vers macOS Sequoia 15.7.9 et macOS Sonoma 14.8.9 le même jour, ce que fait un éditeur lorsqu'il veut un correctif partout d'un coup plutôt que sur la seule version courante.

La vulnérabilité Screen Sharing de macOS Tahoe 26.6.1 mérite d'être comprise correctement, car la version honnête de cette histoire comporte un grand vide là où devrait se trouver le détail intéressant. La ligne d'impact d'Apple tient en une phrase. Elle ne dit pas si le service concerné devait être activé. Elle ne décrit pas le mécanisme. Plusieurs médias ont comblé ce vide avec des précisions que personne n'a corroborées. Ce guide couvre ce qui est réellement confirmé, ce qui est véritablement inconnu, qui était réalistement exposé, et la partie pratique qui compte quel que soit le fonctionnement de la faille : auditer la surface d'accès à distance de votre propre Mac.

Points clés à retenir

• macOS Tahoe 26.6.1 correspond au build 25G76, publié le 6 août 2026, avec un seul correctif de sécurité et rien d'autre. Safari reste en 26.6, le firmware système est inchangé en 18000.161.9, et il n'y a aucune nouvelle fonctionnalité. D'après l'analyse des paquets de mise à jour réalisée par Mr. Macintosh, la mise à jour delta pèse environ 2,1 Go sur Apple silicon et environ 898,9 Mo sur Intel.
• CVE-2026-65400 est un contournement d'authentification dans Screen Sharing. La formulation d'impact d'Apple est la suivante : « Un attaquant sur le réseau peut être en mesure de s'authentifier auprès de Screen Sharing sans identifiants valides. » Le correctif, selon les mots d'Apple, tient à ce qu'« un problème d'authentification a été résolu par une meilleure gestion des états ». Apple crédite Alfredo Pesoli (@__rev) en collaboration avec Bynario Atlas, que le média allemand heise décrit comme un système de détection de vulnérabilités basé sur l'IA.
• Le périmètre est le réseau local, pas l'internet ouvert. heise note que si un Mac se trouve sur un réseau local et que les ports concernés ne sont pas redirigés au niveau du routeur, le partage d'écran à distance depuis internet n'est pas possible. Le modèle de menace réaliste est celui d'un réseau Wi-Fi partagé : un bureau, une résidence universitaire, un espace de coworking, un hôtel, un café.
• Apple n'a pas indiqué si Screen Sharing devait être activé pour que l'attaque fonctionne, et c'est l'argument le plus fort en faveur de la mise à jour. heise affirme clairement qu'il n'est pas établi à ce jour si Screen Sharing ou Apple Remote Desktop doivent être actifs, ou si une attaque est possible même avec le partage d'écran globalement désactivé. Screen Sharing est désactivé par défaut sur un Mac neuf, et beaucoup de gens aimeraient donc en conclure qu'ils n'ont jamais été exposés. Rien de ce qu'Apple a publié n'étaye cette conclusion.
• Le même correctif est arrivé sur macOS Sequoia 15.7.9 (build 24G830) et macOS Sonoma 14.8.9 (build 23J631). Le fait qu'Apple rétroporte vers deux versions majeures plus anciennes le même jour est un signal raisonnable qu'elle a traité le sujet comme sérieux. Apple ne signale aucune exploitation active connue. Rester sur un macOS plus ancien ne pose pas de problème ici, tant que vous appliquez le correctif correspondant.

Ce qu'est réellement macOS Tahoe 26.6.1

Tahoe 26.6 est sorti le 27 juillet 2026 sous le build 25G72, et c'était le plus gros lot de sécurité de tout le cycle Tahoe, avec bien plus de 140 problèmes corrigés. Notre analyse complète de macOS Tahoe 26.6 détaille son contenu, y compris le travail de réindexation de Spotlight qu'Apple a présenté comme une préparation à macOS 27.

macOS Tahoe 26.6.1 est le type de version exactement opposé. Il s'agit du build 25G76, daté du 6 août 2026, et il existe pour combler une seule brèche.

Voici ce qui est confirmé au sujet du paquet lui-même :

• Build : 25G76
• Date de publication : 6 août 2026, environ dix jours après 26.6
• Diffusion en bêta : aucune. Ni bêta développeur, ni bêta publique
• Nouvelles fonctionnalités : aucune
• Safari : reste en version 26.6, non mis à jour
• Firmware système : inchangé en 18000.161.9
• Contenu de sécurité : une CVE, CVE-2026-65400, dans Screen Sharing
• Document de sécurité d'Apple : support.apple.com/en-us/148170

Les tailles de téléchargement proviennent de Mr. Macintosh, qui publie régulièrement les détails des paquets pour les versions d'Apple. La mise à jour delta pèse environ 2,1 Go sur Apple silicon et environ 898,9 Mo sur Intel. Si vous récupérez un installateur complet plutôt qu'un delta, attendez-vous à nettement plus. Le fait que le delta Intel reste sous le gigaoctet alors que celui d'Apple silicon dépasse les deux est normal sur Tahoe, car la voie Apple silicon embarque une charge utile de volume système signé qui est reconstruite différemment.

Pourquoi l'absence de bêta a son importance

La cadence habituelle d'Apple pour une mise à jour mineure implique au moins une diffusion développeur, en général une release candidate, et souvent une bêta publique un ou deux jours plus tard. Ce processus existe pour détecter les régressions avant que des millions de machines n'installent la mise à jour.

Le sauter n'est pas inédit, mais c'est assez inhabituel pour être révélateur. Quand Apple passe directement en version finale sans diffusion préalable et sans charge fonctionnelle, la lecture raisonnable est que le correctif était petit, bien compris, et qu'Apple voulait le publier plus vite que ne le permettait le calendrier de diffusion. Ce n'est pas la même chose que de dire que la faille était exploitée. Apple indique explicitement qu'aucune exploitation active n'est connue. Cela signifie en revanche qu'Apple ne voulait pas attendre une semaine.

Le rétroportage est le second signal. Apple maintient des mises à jour de sécurité pour les deux versions de macOS antérieures à la version courante, mais elle ne pousse pas toujours le même correctif vers les trois le même jour. Le faire ici, vers Sequoia 15.7.9 et Sonoma 14.8.9, suggère qu'Apple a estimé qu'il ne fallait pas laisser cela non corrigé sur la moindre machine prise en charge.

La chronologie des versions à ce jour

Si vous voulez vérifier où vous en êtes, les versions de Tahoe qui comptent récemment sont :

• 26.5 le 11 mai 2026, traitée dans notre guide de mise à jour macOS Tahoe 26.5
• 26.5.1 le 1er juin 2026
• 26.5.2 le 29 juin 2026
• 26.6 le 27 juillet 2026, build 25G72
• 26.6.1 le 6 août 2026, build 25G76

Pour confirmer ce que votre propre Mac exécute, ouvrez Terminal et lancez :

sw_vers

Cela affiche le nom du produit, le numéro de version et le build. Si la version indique 26.6.1 et le build 25G76, vous avez le correctif. Vous pouvez aussi vérifier via le menu Pomme, puis À propos de ce Mac, en cliquant sur le numéro de version pour révéler le build.

Ce que permettait CVE-2026-65400, en clair

Les documents de sécurité d'Apple sont réputés laconiques. Pour celui-ci, la description entière tient en deux phrases.

L'impact :

Un attaquant sur le réseau peut être en mesure de s'authentifier auprès de Screen Sharing sans identifiants valides.

Le correctif :

Un problème d'authentification a été résolu par une meilleure gestion des états.

Les deux phrases méritent une lecture attentive.

« S'authentifier auprès de Screen Sharing »

Screen Sharing sur un Mac est un service qui cède le contrôle en direct de la session graphique. Une personne qui s'y connecte voit ce qui est affiché à l'écran et peut déplacer le pointeur, taper, ouvrir des applications et lire tout ce que l'utilisateur connecté pourrait lire. Ce n'est pas un canal de transfert de fichiers ni une vue en lecture seule. C'est le bureau lui-même.

Normalement, atteindre ce service exige des identifiants. Selon la configuration, cela signifie le mot de passe du compte d'un utilisateur autorisé à se connecter, ou un mot de passe VNC distinct si l'option VNC héritée a été activée. Le service vérifie ces identifiants avant d'accorder une session.

« S'authentifier sans identifiants valides » signifie que cette vérification pouvait être amenée à réussir sans le bon secret. L'attaquant n'apprend pas votre mot de passe. Il n'en a pas besoin. Il parvient à un état dans lequel le service croit que l'authentification a réussi.

Ce que cela lui offre, c'est le niveau de privilège correspondant à ce pour quoi la connexion était autorisée. Sur un Mac où le compte connecté est administrateur, il s'agit d'une session avec des droits d'administration, ce qui revient en pratique à un contrôle quasi total de la machine. Sur un Mac où le compte de partage est un utilisateur standard, il s'agit des accès de cet utilisateur, ce qui suffit encore à lire des documents, à consulter la messagerie et à voir tout ce qui est à l'écran.

« Meilleure gestion des états »

Apple utilise un vocabulaire restreint pour décrire ses correctifs, et chaque formule correspond grossièrement à une classe de bug. « Meilleure gestion des états » pointe généralement vers un service qui suivait incorrectement sa propre progression dans un processus en plusieurs étapes. Quelque part, le code entretenait une notion de « cette connexion s'est-elle authentifiée », et cette notion pouvait finir par être erronée.

C'est aussi loin que va le domaine public. Apple n'a pas publié le mécanisme, et aucun avis d'éditeur autre que celui d'Apple ne l'a décrit.

À propos du crédit au chercheur

Apple crédite Alfredo Pesoli (@__rev) en collaboration avec Bynario Atlas (bynar.io). heise décrit Bynario Atlas comme un système de détection de vulnérabilités basé sur l'IA, ce qui fait de ce cas l'un des exemples les plus visibles d'une chaîne de découverte automatisée aboutissant à une CVE Apple créditée. Les articles diffèrent légèrement sur l'orthographe du nom du chercheur selon les médias ; le crédit lui-même n'est pas contesté.

Le modèle de menace réaliste : réseau local uniquement

L'expression « un attaquant sur le réseau » porte beaucoup de poids dans la déclaration d'impact d'Apple, et c'est l'élément de contexte le plus utile pour décider du niveau d'inquiétude approprié.

La couverture de heise explicite la limite : si le Mac est sur un réseau local et que les ports concernés ne sont pas redirigés dans le routeur, le partage d'écran à distance depuis internet n'est pas possible. Screen Sharing écoute sur le port TCP 5900, et Apple Remote Desktop utilise le 3283 en complément. Les routeurs grand public ne redirigent pas ces ports à moins que quelqu'un ne le configure, et la traduction d'adresses réseau fait qu'un attaquant sur l'internet public ne peut pas simplement joindre l'adresse privée de votre Mac.

L'attaquant doit donc déjà se trouver sur le même segment réseau que votre Mac.

Ce que « sur le même réseau » veut dire en pratique

C'est moins exotique qu'il n'y paraît. Les réseaux où vous partagez un domaine de diffusion avec des personnes que vous ne contrôlez pas incluent :

• Le Wi-Fi d'entreprise, y compris les réseaux invités qui ne sont pas correctement isolés du réseau principal
• Les espaces de coworking, dont tout l'intérêt est justement que des inconnus partagent l'infrastructure
• Les résidences universitaires et les réseaux de campus, souvent plats et gigantesques
• Le Wi-Fi d'hôtel, fréquemment un sous-réseau unique couvrant toutes les chambres
• Le Wi-Fi des cafés et des aéroports
• Les réseaux de conférences et d'événements
• Les immeubles d'habitation avec internet partagé

Les réseaux où le risque est bien plus faible :

• Un réseau domestique avec un petit nombre d'appareils connus, en supposant que le mot de passe Wi-Fi n'est pas largement partagé et qu'aucun appareil non fiable ne s'y trouve
• Une machine connectée uniquement via le partage de connexion cellulaire d'un téléphone que vous contrôlez

Il y a une nuance qui mérite d'être nommée. « Attaquant sur le réseau » n'implique pas nécessairement une personne installée dans le bâtiment avec un portable. Un appareil compromis déjà présent sur le réseau fait tout aussi bien l'affaire. Cela inclut une machine Windows infectée, un objet connecté mal entretenu, ou un routeur affecté d'une faille connue. Le périmètre limité au réseau local réduit considérablement le risque ; il ne le ramène pas à zéro.

Pourquoi c'est un bug sérieux mais pas une raison de paniquer

Trois faits réunis fixent la température ici. D'abord, Apple ne signale aucune exploitation active connue. Ensuite, l'attaque exige une adjacence réseau, il n'y a donc pas de scénario de balayage massif à l'échelle d'internet. Enfin, Apple n'a pas publié le mécanisme, ce qui signifie qu'un attaquant potentiel doit le trouver par lui-même plutôt que de lire une analyse toute faite.

En face de cela, le correctif était assez urgent pour sauter la diffusion en bêta et assez important pour être rétroporté deux fois. La bonne réponse est d'installer la mise à jour cette semaine et d'en profiter pour auditer vos réglages de partage. Ce n'est pas de débrancher votre Mac d'internet.

Qui était réellement exposé de façon significative

Tous les Mac n'avaient pas la même exposition ici, et il vaut mieux être précis plutôt que de lancer une alerte générale.

Risque plus élevé

Les Mac mini et Mac Studio toujours allumés utilisés comme serveurs. Ce sont les machines sur lesquelles Screen Sharing a le plus de chances d'être activé en permanence, parce qu'il n'y a souvent ni clavier ni écran connectés. Elles restent sous tension, restent sur le réseau, et personne ne surveille leur écran. Un Mac mini dans un placard faisant tourner un serveur multimédia, un agent de build ou un hub domotique correspond exactement à ce profil.

Les Mac dans les bureaux partagés et les espaces de coworking. La combinaison d'un réseau non fiable et d'une machine sur laquelle Screen Sharing peut être activé par confort pour l'informatique est le pire cas ici.

Les parcs gérés par un service informatique. Les organisations qui utilisent Apple Remote Desktop ou un MDM activant l'observation à distance disposent d'une infrastructure de partage d'écran activée par politique sur de nombreuses machines à la fois. Si vous administrez un parc, cette mise à jour est un déploiement prioritaire, et les étapes d'audit ci-dessous s'appliquent à l'échelle plutôt que machine par machine.

Toute personne ayant activé Screen Sharing une fois et l'ayant oublié. C'est plus fréquent que les gens ne l'admettent. Vous l'avez activé pour dépanner un proche, ou pour joindre votre ordinateur de bureau depuis un portable, et il est resté actif depuis.

Les Mac avec le port 5900 redirigé au niveau du routeur. Si quelqu'un a délibérément exposé Screen Sharing à internet, la limitation au réseau local ne le protège pas. Cette configuration était une mauvaise idée avant l'existence de cette CVE et l'est encore davantage aujourd'hui.

Risque plus faible

Un portable qui vit sur un réseau domestique avec les réglages par défaut. Screen Sharing est désactivé par défaut sur un Mac neuf. Si vous ne l'avez jamais activé et que votre réseau domestique est petit et connu, votre exposition était faible.

Les Mac qui passent l'essentiel de leur temps en veille ou éteints. Un service qui ne tourne pas n'est pas joignable.

Les machines derrière un réseau invité correctement segmenté. L'isolation des clients sur un SSID invité empêche les appareils de ce réseau de se joindre entre eux, ce qui supprime l'adjacence dont l'attaque a besoin.

La raison pour laquelle tout cela s'accompagne d'une réserve fait l'objet de la section suivante.

Ce qu'Apple ne nous a pas dit

C'est la partie que la plupart des articles passent sous silence, et c'est celle qui devrait façonner votre façon de considérer cette mise à jour.

La question activé-ou-désactivé reste sans réponse

L'avis d'Apple ne dit pas si Screen Sharing doit être activé pour que CVE-2026-65400 soit exploitable. heise énonce le vide directement : il n'est pas établi à ce jour si Screen Sharing ou Apple Remote Desktop doivent être actifs pour permettre l'accès, ou si une attaque peut survenir même lorsque le partage d'écran est globalement désactivé.

Cela compte énormément pour l'évaluation du risque personnel, car Screen Sharing est désactivé par défaut. Si le service doit tourner, la population concernée est réduite et auto-sélectionnée. Si un composant de la pile de partage écoute ou répond même quand l'interrupteur est sur off, la population concernée correspond à tous les Mac sur les versions prises en charge.

Il existe un argument raisonnable dans chaque direction. Les services désactivés dans Réglages Système n'ont réellement pas leurs sockets d'écoute ouverts sur macOS, ce qui plaide pour la lecture restrictive. À l'inverse, macOS utilise l'activation par socket de launchd pour plusieurs services système, si bien qu'un launch daemon peut être dormant alors que le système conserve un socket qui le démarre à la demande, ce qui plaide pour la lecture large. Le choix d'Apple de rétroporter deux fois et de sauter la diffusion en bêta est au moins faiblement cohérent avec la lecture large, sans pour autant en constituer une preuve.

La réponse honnête est que personne en dehors d'Apple ne le sait, et je ne vais pas prétendre le contraire.

Comment raisonner dans cette incertitude : traitez l'inconnu comme l'argument en faveur de la mise à jour, et non comme une invitation à déterminer si vous étiez exposé. Le coût de l'installation de 26.6.1, c'est un redémarrage. Le coût d'une mauvaise supposition sur la protection offerte par un interrupteur désactivé, c'est un inconnu devant votre écran. Cette asymétrie tranche la question sans avoir besoin du détail manquant.

Le mécanisme n'est pas divulgué, et certains détails publiés ne sont pas corroborés

Des affirmations techniques plus détaillées circulent au sujet de cette faille, y compris des descriptions précises du daemon fautif, de ce qui déclenchait l'état défectueux, et de la rapidité avec laquelle un attaquant pouvait obtenir un shell privilégié. Ces affirmations apparaissent dans un petit nombre de médias de second rang, reposent sur une source unique, et ne sont corroborées ni par Apple, ni par heise, ni par la couverture de 9to5Mac, qui n'en contient aucun élément. Traitez-les avec prudence et ne bâtissez pas votre réaction dessus.

Ce n'est pas une préoccupation théorique. Des analyses de vulnérabilité trop précises influencent les comportements. Si vous lisez qu'une faille ne fonctionne que contre une machine ayant un réglage particulier, vous pourriez sauter la mise à jour. Et si ce détail s'avère inventé, vous avez sauté la mise à jour pour rien.

Ce que cela signifie concrètement pour vous

• Installez 26.6.1, ou 15.7.9, ou 14.8.9, selon le macOS que vous utilisez
• Ne vous appuyez pas sur « Screen Sharing était désactivé, donc j'étais tranquille » pour justifier un report
• Auditez quand même vos réglages de partage, car l'audit vaut la peine d'être fait pour lui-même
• Ignorez les affirmations sur le mécanisme de l'exploit tant qu'une analyse technique crédible n'est pas parue

Comment auditer la surface d'accès à distance de votre Mac

C'est le cœur pratique de l'article, et il est utile que vous ayez été exposé ou non à cette CVE précise. La plupart des gens n'ont jamais vraiment regardé ce que leur Mac expose au réseau.

Ouvrez Réglages Système, puis Général, puis Partage. Vous verrez une liste de services avec des interrupteurs individuels. Trois d'entre eux régissent l'accès à distance à votre machine, et les gens les confondent en permanence.

Screen Sharing

C'est le service concerné par CVE-2026-65400. Lorsqu'il est activé, d'autres machines peuvent se connecter et prendre le contrôle de votre session graphique via VNC, sur le port TCP 5900.

Comment le vérifier : dans le panneau Partage, regardez la ligne Screen Sharing. Si l'interrupteur est sur off, le service n'est pas activé. S'il est sur on, cliquez sur le petit bouton d'information à côté pour voir la liste d'accès.

Ce que signifie la liste d'accès : par défaut, les options sont « Tous les utilisateurs » ou une liste spécifique. « Tous les utilisateurs » désigne ici chaque compte utilisateur du Mac, y compris tout compte que vous avez créé et oublié. Restreindre à une liste nommée est strictement préférable. Cliquez sur le bouton d'information, choisissez l'option n'autorisant l'accès qu'à ces utilisateurs, et ajoutez les comptes précis qui en ont besoin.

Les Réglages de l'ordinateur à l'intérieur de ce panneau contiennent deux options supplémentaires. L'une permet à n'importe qui de demander l'autorisation de contrôler l'écran, ce qui affiche une invite à l'utilisateur connecté. L'autre active un mot de passe VNC, qui permet à des clients non-Apple de se connecter à l'aide d'un mot de passe partagé plutôt que d'un identifiant de compte. L'option de mot de passe VNC est la plus faible des deux voies d'authentification et est plafonnée à huit caractères par le protocole. Si vous n'en avez pas spécifiquement besoin pour un client tiers, laissez-la désactivée.

Désactivez-le si vous n'en avez pas besoin. C'est le changement le plus rentable que la plupart des gens puissent faire dans ce panneau.

Remote Login (SSH)

C'est un service complètement distinct, sur le port TCP 22. Il donne un accès en ligne de commande, pas un accès graphique. Il n'est pas affecté par CVE-2026-65400, et désactiver Screen Sharing ne change rien pour lui.

Les gens confondent les deux parce que tous deux relèvent de l'« accès à distance », et parce qu'en désactiver un donne l'impression d'avoir fermé la porte. Ce n'est pas le cas.

Vérifiez depuis Terminal :

sudo systemsetup -getremotelogin

Cela indique si Remote Login est activé ou non. Pour le désactiver :

sudo systemsetup -setremotelogin off

Vous pouvez faire la même chose dans le panneau Partage en basculant Remote Login sur off. Comme pour Screen Sharing, le bouton d'information permet de restreindre l'accès à des utilisateurs précis plutôt qu'à tous, et vous devriez le faire.

Si vous utilisez SSH régulièrement, l'étape de durcissement qui compte vraiment est de désactiver totalement l'authentification par mot de passe et d'utiliser des clés, ce qui supprime toute la classe des attaques par devinette.

Remote Management (Apple Remote Desktop)

C'est le troisième interrupteur, et celui qui génère le plus de confusion.

Remote Management est l'agent Apple Remote Desktop. Il fournit l'observation et le contrôle de l'écran, ainsi que la distribution de logiciels, la génération de rapports et l'exécution de commandes à distance. C'est ce que les services informatiques utilisent pour gérer les parcs. Il utilise le port 3283 en plus du 5900.

Le détail critique : Screen Sharing et Remote Management s'excluent mutuellement dans l'interface de macOS. Vous ne pouvez pas avoir les deux activés. Activer Remote Management désactive automatiquement Screen Sharing, et macOS vous le signalera. La conséquence est ce que les gens ratent : si vous allez dans Partage, constatez que Screen Sharing est désactivé et en concluez que rien ne peut voir votre écran, vous vous trompez peut-être. Remote Management peut être activé à la place, offrant la même capacité via un service différent.

Vérifiez donc les deux lignes, à chaque fois. Screen Sharing désactivé plus Remote Management activé n'est pas une configuration durcie. C'est la même porte avec une autre poignée.

Remote Management dispose également d'une liste de permissions granulaires derrière son bouton d'information, couvrant la possibilité pour un utilisateur distant d'observer, de contrôler, de copier des fichiers, de supprimer des éléments, de redémarrer la machine, et plus encore. Si Remote Management est activé parce que votre employeur gère le Mac, ne le désactivez pas simplement. Parlez-en d'abord à la personne qui administre le parc, car le désactiver peut casser leur gestion et enfreindre la politique de votre organisation.

Vérifiez si votre Mac est inscrit dans un MDM

Si vous n'êtes pas sûr qu'une organisation gère votre Mac, voici la commande qui vous le dira :

sudo profiles status -type enrollment

Elle indique si le Mac est inscrit via l'inscription automatisée d'appareils d'Apple et s'il dispose actuellement d'une inscription MDM active. Un Mac personnel acheté dans le commerce et configuré par vos soins indiquera qu'il n'est pas inscrit. Une machine fournie par un employeur ou une école signalera généralement une inscription active.

Cela compte pour deux raisons. D'abord, si le Mac est géré, les réglages d'accès à distance peuvent être imposés par profil et se réinitialiser après vos modifications. Ensuite, s'il est géré, la mise à jour elle-même peut être contrôlée par la politique de mise à jour logicielle de votre organisation plutôt que par vous, ce qui change la façon dont vous obtiendrez 26.6.1.

Vous pouvez aussi lister les profils de configuration installés :

sudo profiles list

Cela montre ce qui est installé. Si vous voyez des profils que vous ne reconnaissez pas sur une machine que vous pensez personnelle, cela mérite une investigation.

Vérifiez le pare-feu

macOS embarque un pare-feu applicatif qui n'est pas activé par défaut sur toutes les configurations. Il vaut la peine de l'activer indépendamment de cette CVE.

Dans l'interface : Réglages Système, puis Réseau, puis Pare-feu. Activez-le. Derrière le bouton Options, vous pouvez contrôler quels services et applications sont autorisés à accepter des connexions entrantes, et vous pouvez activer le mode furtif, qui fait que le Mac refuse de répondre aux sondages comme les pings et les balayages de ports provenant de sources non autorisées.

Depuis Terminal :

/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

Cela indique si le pare-feu est actif.

Une limitation importante : le pare-feu applicatif de macOS ne bloque pas les services que vous avez explicitement activés dans Partage. Si Screen Sharing est activé, macOS considère les connexions entrantes vers ce service comme voulues et les laisse passer. Le pare-feu est une couche utile, mais ce n'est pas un substitut à la désactivation des services dont vous ne vous servez pas. Si vous devez bloquer un service activé par Partage, cela relève du routeur ou d'une règle de filtrage de paquets, pas du pare-feu applicatif.

Voyez ce qui écoute réellement

Si vous voulez vérifier plutôt que faire confiance aux interrupteurs, ceci montre quel processus est lié au port de partage d'écran :

sudo lsof -i :5900

Aucune sortie signifie que rien n'écoute sur ce port. Vous pouvez remplacer par 22 pour SSH et 3283 pour le port d'Apple Remote Desktop.

Ce type d'audit est une bonne habitude, indépendamment de toute CVE particulière. Notre guide de sécurité et de confidentialité sur Mac couvre l'ensemble plus large des réglages à passer en revue périodiquement, y compris FileVault, Gatekeeper, les autorisations de confidentialité et ce que les différents services de Partage exposent réellement.

Durcir la configuration si vous avez vraiment besoin d'un accès à distance

Beaucoup de gens ont une vraie raison de joindre un Mac à distance. Un serveur domestique, une machine au bureau, l'ordinateur d'un proche que vous dépannez. Désactiver la fonctionnalité n'est pas une option pour eux. Voici comment la conserver en réduisant l'exposition.

Joignez le Mac via un réseau privé, pas un réseau public

Le changement le plus efficace à lui seul consiste à cesser d'exposer le service sur un réseau que vous ne contrôlez pas, et à placer plutôt le Mac et votre client sur le même réseau privé superposé.

Un VPN vers votre réseau domestique ou professionnel fonctionne. Un réseau overlay comme Tailscale, WireGuard ou ZeroTier aussi : il crée un maillage chiffré entre vos appareils et donne à chacun une adresse privée stable, non joignable depuis l'internet général. Avec cela en place, Screen Sharing n'écoute jamais que sur une interface que seuls vos propres appareils peuvent atteindre. Un attaquant sur le Wi-Fi du café n'est plus adjacent au service en un sens utile, car le service n'est pas exposé sur l'interface locale qu'il partage avec vous.

C'est l'approche qui aurait neutralisé le périmètre réseau local de CVE-2026-65400 à toutes fins pratiques, et elle neutralisera aussi la prochaine. Si vous rencontrez des problèmes de connectivité en la mettant en place, notre guide de dépannage VPN pour macOS couvre les modes de défaillance habituels liés aux profils de configuration, au DNS et au split tunneling.

Ne redirigez jamais le port 5900

Rediriger le port 5900 de votre routeur vers un Mac place le service de partage d'écran directement sur l'internet public, où les scanners automatisés le trouvent en quelques heures. VNC sur le port 5900 est l'un des ports les plus scannés d'internet. Ne faites pas cela. Si vous l'avez fait, annulez-le immédiatement.

Il en va de même pour le 3283 pour Apple Remote Desktop et le 22 pour SSH. Si vous devez exposer SSH, déplacez-le hors du port par défaut, désactivez l'authentification par mot de passe et utilisez des clés — mais la meilleure réponse reste un VPN.

Utilisez un compte dédié avec une liste d'autorisation explicite

N'utilisez pas votre compte administrateur quotidien comme compte d'accès à distance. Créez un compte séparé pour cela, ne lui donnez que les privilèges dont il a besoin, et n'ajoutez que ce compte à la liste des utilisateurs autorisés de Screen Sharing. Si la voie d'accès à distance est compromise, le rayon d'action se limite à ce compte plutôt qu'à une session administrateur.

Attribuez-lui un mot de passe réellement solide. La réutilisation des mots de passe est la raison pour laquelle beaucoup d'incidents d'accès à distance deviennent graves.

Gardez la liste des utilisateurs autorisés explicite et révisée

« Tous les utilisateurs » est pratique et mauvais. Chaque compte du Mac se retrouve implicitement autorisé, y compris les vieux comptes, les comptes de type invité et les comptes de service que vous avez créés il y a des années pour autre chose. Définissez la liste explicitement et revoyez-la quand des personnes partent ou quand vous mettez un compte hors service.

Désactivez les services quand vous ne les utilisez pas

Si vous n'avez besoin de Screen Sharing qu'occasionnellement, activez-le le temps de la session et désactivez-le ensuite. Un service qui tourne vingt minutes par mois a un profil d'exposition très différent de celui qui tourne en continu pendant trois ans.

Comment installer macOS Tahoe 26.6.1

La mise à jour est distribuée via Mise à jour de logiciels comme n'importe quelle autre version mineure.

1. Sauvegardez d'abord. Time Machine ou un clone, peu importe, mais ayez quelque chose. C'est une petite mise à jour et le risque est faible, mais la règle ne change pas.
2. Ouvrez Réglages Système, puis Général, puis Mise à jour de logiciels.
3. Attendez la fin de la vérification. macOS Tahoe 26.6.1 devrait apparaître comme mise à jour disponible.
4. Cliquez sur Mettre à jour maintenant et saisissez votre mot de passe.
5. Laissez le Mac redémarrer. Sur Apple silicon, cela prend généralement dix à vingt minutes au total selon la machine et le disque.
6. Au retour, confirmez avec sw_vers dans Terminal ou en consultant À propos de ce Mac. Vous voulez la version 26.6.1 et le build 25G76.

Depuis Terminal, vous pouvez lister et installer sans passer par l'interface :

softwareupdate --list

Cela montre ce qui est disponible. Pour installer tout ce qui s'applique :

sudo softwareupdate -i -a

Ajoutez --restart si vous voulez que la machine redémarre automatiquement à la fin.

Si la mise à jour n'apparaît pas encore

Apple échelonne la distribution des versions mineures. Le 6 août, des utilisateurs ont signalé que 26.6.1 n'était pas encore apparue sur certains Mac M4 et M5 alors qu'elle était déjà disponible sur d'autres machines, et ces cas se sont résolus d'eux-mêmes sans intervention.

Si Mise à jour de logiciels n'affiche rien :

• Attendez quelques heures et vérifiez de nouveau. Les déploiements échelonnés mettent couramment une journée à atteindre tout le monde.
• Quittez complètement Réglages Système et rouvrez-les, puis revérifiez. Le volet Mise à jour de logiciels met son état en cache et a parfois besoin d'un coup de pouce.
• Lancez softwareupdate --list depuis Terminal, qui interroge directement les serveurs d'Apple et fait parfois remonter une mise à jour que l'interface n'a pas affichée.
• Si votre Mac est géré par une organisation, la mise à jour peut être différée par politique. sudo profiles status -type enrollment vous dira si c'est envisageable, et votre équipe informatique contrôle alors le calendrier.
• En dernier recours, Apple publie des paquets d'installation autonomes, et Mr. Macintosh recense régulièrement les liens directs de chaque version. Télécharger l'installateur complet contourne le déploiement échelonné, au prix d'un téléchargement bien plus lourd.

Si l'installation échoue

Les versions mineures s'installent le plus souvent sans drame, mais les modes de défaillance habituels s'appliquent toujours : espace libre insuffisant, téléchargement interrompu, ou mise à jour qui se bloque en pleine préparation. Notre guide sur les mises à jour macOS bloquées ou qui ne s'installent pas explique comment libérer de l'espace correctement, effacer un téléchargement partiel et sortir d'une installation figée.

En résumé : il vous faut nettement plus d'espace libre que la taille du téléchargement, car macOS a besoin de place pour décompresser et préparer la mise à jour. Pour un delta de 2,1 Go, disposer de 20 Go libres est une marge confortable, pas excessive.

Si vous êtes sur Sonoma ou Sequoia

Apple a livré le même correctif aux deux versions de macOS plus anciennes encore prises en charge, le 6 août 2026 :

Version de macOS	Version corrigée	Build
macOS Tahoe 26	26.6.1	25G76
macOS Sequoia 15	15.7.9	24G830
macOS Sonoma 14	14.8.9	23J631

La marche à suivre est identique : Réglages Système, Général, Mise à jour de logiciels, installer, redémarrer.

Deux remarques méritent d'être faites au sujet du maintien sur un macOS plus ancien. Premièrement, sur ce problème précis, rester sur Sequoia ou Sonoma ne pose pas de souci tant que vous appliquez le correctif correspondant. Vous n'obtenez pas un correctif au rabais. Apple a traité la même CVE sur les trois versions.

Deuxièmement, cela ne tient que tant qu'Apple continue de publier des mises à jour de sécurité pour votre version, ce qu'elle fait pour environ la version courante plus les deux précédentes. Sonoma 14 est à l'extrême limite de cette fenêtre. Si vous êtes sur Sonoma pour une raison précise, cette raison mérite d'être réexaminée régulièrement, car il arrivera un moment où une CVE ne sera corrigée que sur les versions plus récentes.

Les versions plus anciennes reçoivent aussi parfois un sous-ensemble plus restreint de correctifs que la version courante, même quand la CVE phare est partagée. Ce n'est pas le cas ici, puisque 26.6.1 ne contient qu'un seul correctif, mais c'est pourquoi « je suis sur un macOS plus ancien et j'installe toutes les mises à jour » est une position plus fragile qu'elle n'en a l'air sur la durée.

Le cas des Mac Intel

Les Mac Intel reçoivent 26.6.1 comme tout le monde, avec le delta plus léger de 898,9 Mo. La raison de le mentionner à part tient à ce que cela représente.

macOS 27 est réservé à Apple silicon. Les Mac Intel ne peuvent pas l'exécuter, ce qui fait de macOS Tahoe 26 la dernière version majeure que ces machines recevront jamais. La pratique d'Apple est de fournir des mises à jour de sécurité pour une version pendant environ trois ans après qu'elle a cessé d'être la version courante, si bien que les propriétaires de Mac Intel peuvent s'attendre à continuer de recevoir des mises à jour ressemblant exactement à celle-ci : un numéro de build incrémenté, une ou quelques CVE, aucune fonctionnalité.

Cela fait de 26.6.1 un aperçu utile des prochaines années pour le matériel Intel. Les mises à jour seront moins intéressantes et plus importantes. Il n'y aura aucune nouvelle capacité à évaluer, donc la seule question à chaque fois sera de savoir s'il faut installer, et la réponse sera oui. Notre analyse de la fin de l'ère des Mac Intel couvre la liste complète de compatibilité et ce à quoi ressemble réalistement le calendrier de prise en charge.

Si vous faites tourner un Mac Intel en machine toujours allumée, la section d'audit ci-dessus mérite une attention particulière. Les anciens Mac mini sont précisément les machines les plus susceptibles de dormir dans un placard avec Screen Sharing activé et oublié.

L'observation sur les clients VNC tiers

Cette section est spéculative et signalée comme telle. Elle est incluse parce qu'elle peut être utile à un groupe précis de lecteurs, pas parce qu'elle est établie.

Après la sortie de macOS Tahoe 26.6 fin juillet, des utilisateurs ont signalé que des clients VNC tiers ne pouvaient plus se connecter à leurs Mac. Les signalements concernaient RealVNC et d'autres clients tournant sur Windows, iOS et Linux, RealVNC affichant un message évoquant une erreur de protocole liée à une longueur de clé trop grande. Dans les mêmes signalements, le partage d'écran de Mac à Mac continuait de fonctionner normalement, et c'est ce détail qui rend le motif intéressant plutôt qu'une simple panne générique.

Nous n'avons pas pu lire directement le fil de discussion d'origine, cette description repose donc sur des comptes rendus de seconde main et doit être considérée comme telle. Nous n'avons pas connaissance d'une déclaration d'Apple reconnaissant ce comportement.

L'hypothèse, présentée comme une hypothèse : 26.6 a peut-être modifié quelque chose dans la voie d'authentification du partage d'écran d'une manière qui a cassé la compatibilité avec les clients VNC tiers, et CVE-2026-65400 pourrait résider dans ce même code. Un changement qui resserre le traitement de l'authentification, suivi dix jours plus tard d'un correctif pour un bug d'état d'authentification dans le même composant, forme une séquence suggestive. Apple n'a rien publié qui les relie, heise dit que le mécanisme reste flou, et une séquence suggestive n'est pas une preuve.

Ce que cela implique en pratique :

• Si votre client VNC tiers a cessé de fonctionner après 26.6, c'est un motif connu que d'autres personnes ont signalé. Vous n'êtes pas seul et vous n'êtes probablement pas mal configuré.
• S'il est cassé, ne supposez pas que 26.6.1 le répare. La mise à jour traite un problème de sécurité. Rien n'indique qu'elle rétablisse la compatibilité avec les clients tiers, et elle pourrait ne pas le faire.
• Si vous dépendez d'un client VNC tiers pour joindre un Mac, renseignez-vous auprès de l'éditeur de votre client sur la compatibilité avec macOS 26.6 et 26.6.1 avant de mettre à jour une machine que vous ne pouvez pas atteindre physiquement sans peine.
• Rien de tout cela n'est une raison de sauter la mise à jour. Si le choix est entre un client VNC tiers fonctionnel et un contournement d'authentification corrigé, prenez le correctif et trouvez un autre moyen de vous connecter.

Dépannage des problèmes courants

macOS Tahoe 26.6.1 n'apparaît pas dans Mise à jour de logiciels

Problème : Mise à jour de logiciels indique que votre Mac est à jour en 26.6, et 26.6.1 est introuvable, alors qu'elle est sortie le 6 août. Plusieurs utilisateurs l'ont signalé sur des Mac M4 et M5 le jour de la sortie.

Solution : il s'agit presque toujours du déploiement échelonné plutôt que d'une panne. Apple diffuse les mises à jour mineures à des sous-ensembles de machines sur une période de quelques heures à quelques jours. Quittez complètement Réglages Système et rouvrez-les, puisque le volet Mise à jour de logiciels met les résultats en cache. Puis lancez softwareupdate --list dans Terminal, qui interroge directement les serveurs d'Apple et renvoie parfois une mise à jour que l'interface n'a pas fait remonter. Si votre Mac est géré, lancez sudo profiles status -type enrollment pour confirmer si un MDM diffère les mises à jour par politique, auquel cas votre équipe informatique contrôle le calendrier. Les cas signalés le 6 août se sont résolus d'eux-mêmes en moins d'une journée. Si vous en avez besoin immédiatement et ne pouvez pas attendre, un installateur autonome complet contourne le déploiement, au prix d'un téléchargement bien plus lourd.

La mise à jour se télécharge mais ne finit jamais de s'installer

Problème : le téléchargement se termine, ou semble se terminer, puis le Mac reste sur Préparation ou sur une barre de progression figée pendant un long moment sans progression visible.

Solution : commencez par lui laisser plus de temps que ce qui paraît raisonnable, car la phase de préparation peut réellement prendre quinze minutes ou plus sur une machine chargée avec un disque presque plein. Si c'est vraiment bloqué, vérifiez l'espace libre, puisque macOS a besoin de bien plus de marge que la taille du téléchargement pour décompresser et préparer l'installateur. Redémarrez le Mac et réessayez, ce qui efface un téléchargement partiel ou corrompu. Si cela échoue une seconde fois, supprimez la mise à jour mise en cache et laissez-la se retélécharger. Notre guide sur les mises à jour macOS bloquées et en échec couvre la séquence complète, y compris comment vider le cache de mise à jour sans risque et que faire si le Mac redémarre dans une boucle d'installation ratée.

Screen Sharing ne fonctionne plus après la mise à jour

Problème : vous avez installé 26.6.1 et vous ne pouvez plus vous connecter à un Mac ou depuis un Mac via le partage d'écran.

Solution : commencez par confirmer ce qui est réellement activé. Ouvrez Réglages Système, Général, Partage, et vérifiez à la fois la ligne Screen Sharing et la ligne Remote Management, car elles s'excluent mutuellement et une mise à jour ou un changement de politique peut laisser l'état différent de votre souvenir. Vérifiez que le compte qui se connecte figure bien sur la liste des utilisateurs autorisés, plutôt que de vous fier à Tous les utilisateurs, qui a pu être modifié. Si vous vous connectez depuis un autre Mac via Screen Sharing ou le Finder, testez d'abord sur le réseau local pour déterminer si le problème vient du service ou du chemin qui y mène. Si vous vous connectez depuis un client VNC tiers, voyez la section ci-dessus, puisque des utilisateurs ont signalé des échecs de clients tiers à partir de 26.6, comportement non confirmé mais rapporté. Enfin, lancez sudo lsof -i :5900 sur le Mac cible pour confirmer que quelque chose écoute bien.

Remote Management refuse de se désactiver

Problème : vous désactivez Remote Management dans le panneau Partage et il se réactive tout seul, ou l'interrupteur est grisé et ne peut pas être modifié.

Solution : c'est la signature d'un Mac géré. Un profil de configuration poussé par un MDM peut imposer Remote Management et le réappliquera après votre modification locale. Lancez sudo profiles status -type enrollment pour confirmer si le Mac a une inscription MDM active, et sudo profiles list pour voir quels profils sont installés. Si le Mac appartient à votre employeur ou à votre école, n'essayez pas de contourner cela. Contactez la personne qui administre le parc, car retirer la gestion peut enfreindre la politique et sera de toute façon probablement annulé en quelques minutes. Si le Mac est réellement personnel et que vous découvrez une inscription que vous n'avez pas autorisée, c'est une découverte sérieuse qui mérite d'être signalée, et la résolution la plus sûre sur une machine personnelle est une installation propre après sauvegarde de vos données.

Vous ne savez pas si votre Mac a été compromis

Problème : vous avez fait tourner un Mac toujours allumé avec Screen Sharing activé sur un réseau partagé, et vous voulez savoir si quelqu'un a réellement utilisé cette faille contre vous.

Solution : pour être honnête avec vous : il n'existe aucun moyen fiable, au niveau grand public, de répondre à cette question. Apple n'a pas publié d'indicateurs de compromission pour CVE-2026-65400, le mécanisme n'est pas divulgué, et un attaquant qui se serait authentifié auprès de Screen Sharing produirait une activité de journalisation ressemblant globalement à une session légitime. Ici, l'absence de preuve n'est véritablement pas une preuve d'absence.

Ce que vous pouvez tout de même vérifier, en gardant ces limites à l'esprit : ouvrez Console et examinez les journaux système autour de la période qui vous inquiète, en filtrant sur l'activité de partage d'écran, tout en notant que la rétention des journaux macOS est limitée et que les entrées anciennes peuvent avoir simplement disparu. Passez en revue Réglages Système, Utilisateurs et groupes, à la recherche de comptes que vous ne reconnaissez pas. Vérifiez les listes d'utilisateurs autorisés du panneau Partage pour repérer des entrées que vous n'avez pas ajoutées. Regardez dans les Ouvertures et les Éléments en arrière-plan s'il y a quelque chose d'inconnu. Lancez sudo profiles list pour repérer des profils de configuration que vous n'avez pas installés. Consultez la liste des appareils connectés de votre routeur et, s'il les conserve, ses journaux.

Si vous avez une raison concrète de croire qu'une machine précise a été consultée par quelqu'un, et qu'elle contient des données sensibles, la seule remédiation véritablement fiable est une installation propre de macOS suivie d'une restauration des données plutôt que d'une sauvegarde système complète, plus le changement des mots de passe des comptes qui y étaient connectés. C'est une réponse lourde et elle n'est pas justifiée pour la plupart des gens. Apple ne signale aucune exploitation connue de ce problème.

FAQ

Dois-je installer macOS Tahoe 26.6.1 si Screen Sharing était désactivé ?

Oui. Apple n'a jamais indiqué si Screen Sharing devait être activé pour que CVE-2026-65400 soit exploitable, et heise rapporte que cela reste flou. Puisque la condition est inconnue et que la mise à jour ne vous coûte qu'un redémarrage, installez-la. Ne prenez pas un interrupteur désactivé pour la confirmation que vous étiez à l'abri.

Qu'est-ce que CVE-2026-65400, en termes simples ?

C'est un contournement d'authentification dans le service Screen Sharing de macOS. La formulation d'Apple est qu'un attaquant sur le réseau peut être en mesure de s'authentifier auprès de Screen Sharing sans identifiants valides. En pratique, cela signifie que quelqu'un sur le même réseau pourrait potentiellement obtenir une session de partage d'écran sans connaître de mot de passe. Apple l'a corrigé par une meilleure gestion des états.

Cette vulnérabilité a-t-elle réellement été exploitée ?

Apple ne signale aucune exploitation active connue. C'est la formulation standard d'Apple lorsqu'elle n'a aucune preuve d'attaques dans la nature, et Apple signale explicitement les problèmes activement exploités lorsqu'elle en a connaissance. L'absence de cette mention ici est significative, sans pour autant garantir que personne ne s'en est jamais servi.

Quelqu'un peut-il attaquer mon Mac via internet avec cette faille ?

Pas dans des conditions normales. heise note que si le Mac est sur un réseau local et que les ports concernés ne sont pas redirigés au niveau du routeur, le partage d'écran à distance depuis internet n'est pas possible. Le scénario réaliste est celui d'un attaquant déjà présent sur votre segment réseau : Wi-Fi de bureau partagé, résidence universitaire, hôtel, café, ou appareil compromis sur votre propre réseau.

26.6.1 ajoute-t-elle des fonctionnalités ou modifie-t-elle Safari ?

Non. Il n'y a aucune nouvelle fonctionnalité. Safari reste en version 26.6 et n'est pas mis à jour par cette version. Le firmware système reste également inchangé en 18000.161.9. macOS Tahoe 26.6.1 correspond au build 25G76 et contient un unique correctif de sécurité, ce qui explique qu'elle soit sortie sans diffusion en bêta et avec une note de version d'une seule ligne.

Et si j'utilise macOS Sonoma ou Sequoia à la place ?

Apple a rétroporté le même correctif. Prenez macOS Sequoia 15.7.9, build 24G830, ou macOS Sonoma 14.8.9, build 23J631. Vous bénéficiez de la même protection, pas d'une version amoindrie. Rester sur un macOS plus ancien ne pose pas de problème sur ce point précis, tant que vous installez rapidement le correctif correspondant.

Conclusion

macOS Tahoe 26.6.1 est une petite mise à jour portant un seul correctif, et la façon dont Apple l'a livrée en dit plus long que les notes de version. Aucune diffusion en bêta, aucune fonctionnalité, et un rétroportage le jour même vers Sequoia 15.7.9 et Sonoma 14.8.9 : tout indique un éditeur qui voulait refermer cette porte partout, et vite. CVE-2026-65400 permettait à un attaquant sur le réseau local de s'authentifier auprès de Screen Sharing sans identifiants valides, et Apple l'a corrigé par une meilleure gestion des états. C'est là toute l'étendue confirmée du domaine public.

Le vide dans ce dossier, c'est la question activé-ou-désactivé, et elle mérite qu'on s'y attarde plutôt que de la trancher par supposition. Apple n'a pas dit si le service devait tourner. heise dit que ce n'est pas clair. Screen Sharing est désactivé par défaut, ce qui rend tentant d'en conclure que vous n'avez jamais été exposé — et rien de publié n'étaye cette conclusion. Des affirmations plus détaillées sur le mécanisme circulent sans corroboration et ne devraient pas servir à décider s'il faut mettre à jour.

Installez 26.6.1 cette semaine, ou 15.7.9, ou 14.8.9. Puis passez dix minutes dans Réglages Système, Général, Partage, et regardez les trois interrupteurs d'accès à distance plutôt qu'un seul. Confirmez que Screen Sharing et Remote Management sont tous les deux désactivés sauf nécessité, vérifiez Remote Login séparément, remplacez tout réglage Tous les utilisateurs par une liste explicite, et activez le pare-feu. Si vous avez réellement besoin d'un accès à distance à un Mac, joignez-le via un VPN ou un réseau overlay plutôt que de l'exposer sur le réseau où la machine se trouve, et ne redirigez jamais le port 5900. Cette configuration aurait rendu cette CVE largement théorique pour vous, et elle fera de même pour la suivante.

Lecture complémentaire : macOS Tahoe 26.6 est disponible : nouveautés, correctifs de sécurité et guide de mise à jour