Le 24 juillet 2026, Apple a publié une mise à jour silencieuse de son moteur anti-malware intégré XProtect, portant la base de règles à la version 5352. Cette diffusion couvre toutes les versions de macOS encore supportées, de macOS Sequoia jusqu’à macOS Tahoe et macOS Golden Gate.
Apple ne communique pas publiquement le détail des menaces adressées, mais l’analyse de la base YARA embarquée, rendue publique par Howard Oakley sur The Eclectic Light Company, permet d’identifier les évolutions concrètes de cette mise à jour.
Éléments impactés
Composant : XProtect (moteur de signatures anti-malware intégré à macOS)
Version de règles : 5352
Date de publication : 24 juillet 2026
Systèmes concernés : toutes les versions de macOS supportées
Diffusion : automatique via les mécanismes de mise à jour d’Apple ; sur Sequoia, Tahoe et Golden Gate, la propagation se fait aussi via iCloud
Détails
Article — Apple has released an update to XProtect for all macOS
Source : The Eclectic Light Company (Howard Oakley) | Publication : 2026-07-24
Résumé factuel repris de l’article : la mise à jour XProtect 5352 introduit deux nouvelles règles YARA visant les familles MACOS.BOATLOAD.REWA et MACOS.BOATLOAD.REFU. Fait plus inhabituel, elle retire les règles concernant MACOS.DUBROBBER.D et MACOS.DUBROBBER.E, et amende la règle relative à MACOS.SOMA.D. Le fichier XPScripts.yr, dédié aux règles Osascript, n’est pas modifié.
Gravité : évaluation officielle non communiquée par Apple. Il ne s’agit pas d’un correctif de vulnérabilité (CVE), mais d’une mise à jour de signatures qui renforce la détection de malwares actifs et retire d’anciennes signatures devenues obsolètes ou redondantes.
Recommandations :
Vérifier que la version 5352 est bien installée sur les Mac administrés, via À propos de ce Mac puis Rapport système > Installations, ou avec SilentKnight/SystHist pour un inventaire précis.
Sur macOS Sequoia, Tahoe et Golden Gate, forcer la vérification en Terminal avec sudo xprotect check et, si besoin, sudo xprotect update.
Sur les versions antérieures, si SilentKnight signale une désynchronisation, forcer l’installation via l’identifiant de mise à jour XProtectPlistConfigData_10_15-5352.
Rester attentif aux publications ultérieures d’Apple : le retrait des règles DUBROBBER.D/E reste inexpliqué à ce stade et pourrait indiquer soit une consolidation dans une autre règle, soit une réévaluation du risque.
Tableau des références
Titre de la page du support technique
URL officielle
Date de publication
Apple has released an update to XProtect for all macOS (The Eclectic Light Company, Howard Oakley)
Avis de non-responsabilité : Cette publication est générée automatiquement à des fins purement informatives. Bien que les données soient issues de veilles technologiques, elles ne sauraient se substituer aux publications officielles. Pour toute décision relative à la sécurité de vos systèmes, il convient de vérifier et de valider les informations fournies en consultant directement les bulletins officiels du NIST (National Institute of Standards and Technology) et d’Apple Security.
Le 2 juillet 2026, l’équipe Jamf Threat Labs, sous la plume du chercheur Thijs Xhaflaire, a publié une analyse détaillée d’un nouveau voleur d’informations (« infostealer ») pour macOS baptisé PamStealer. Ce logiciel malveillant se dissimule sous l’apparence de Maccy, un gestionnaire de presse-papiers open source populaire, et cible spécifiquement les Mac équipés d’une puce Apple Silicon. Son mode opératoire présente deux particularités qui méritent l’attention : d’une part, une chaîne d’exécution en deux étapes qui combine un AppleScript compilé (.scpt) et une charge finale écrite en Rust ; d’autre part, une validation locale du mot de passe utilisateur via l’API PAM (Pluggable Authentication Modules) de macOS, avant exfiltration.
Ce bulletin s’inscrit dans la continuité de la veille sur les infostealers macOS. Il ne s’agit pas d’une vulnérabilité au sens strict, mais d’une campagne active exploitant l’ingénierie sociale et un contournement discret des protections système. Pour les utilisateurs de Mac, le message est clair : télécharger Maccy uniquement depuis le site officiel maccy.app et se méfier des sites imitant les marques d’outils légitimes.
Éléments impactés
Système visé : macOS, uniquement sur Apple Silicon (M1, M2, M3, M4 et M5). Les Mac Intel sont épargnés par cette variante en raison d’un contrôle d’empreinte matérielle.
Application usurpée : Maccy (maccy.app), gestionnaire de presse-papiers open source légitime développé par Alex Rodionov.
Domaines malveillants identifiés par Jamf : maccyapp[.]com et maccyapp[.]net.
Données ciblées : mots de passe stockés dans les navigateurs, cookies, données d’extensions de portefeuilles de cryptomonnaies, éléments du trousseau iCloud et contenu du presse-papiers.
Mesure officielle : le développeur de Maccy a publié un avertissement sur son site officiel et son dépôt GitHub.
La victime est attirée vers un site imitant Maccy (maccyapp[.]com ou maccyapp[.]net) et télécharge une image-disque contenant un fichier AppleScript compilé nommé Maccy.scpt.
L’utilisateur est invité à ouvrir le fichier avec Script Editor puis à exécuter le script via le raccourci Cmd + R ou en cliquant sur « Run ». Ce mode d’exécution reste opérationnel même lorsque le fichier porte encore l’attribut com.apple.quarantine, ce qui rend l’approche particulièrement attractive alors qu’Apple renforce régulièrement Gatekeeper et Terminal.
Le script exécute un JXA (JavaScript for Automation) intégré qui télécharge et installe la charge suivante en s’appuyant sur des API Objective-C natives.
Le dropper effectue une empreinte de l’hôte (architecture CPU, langue, disposition du clavier, fuseau horaire). Cette empreinte sert à dériver une clé qui déchiffre une configuration contenant l’URL de la charge et le chemin d’installation. Sur Mac Intel, la clé dérivée est différente et le déchiffrement échoue, ce qui termine l’exécution.
Le script évite également les environnements sandboxés ou d’analyse, ainsi que les systèmes dont le fuseau horaire, la langue et la disposition clavier correspondent à des pays d’Europe de l’Est (Russie, Biélorussie, Kazakhstan, Arménie, Azerbaïdjan, Kirghizistan, Moldavie, Tadjikistan, Ouzbékistan, Turkménistan, Géorgie).
Une fois les vérifications passées, un binaire Mach-O écrit en Rust est téléchargé. Il se déguise sous l’apparence de l’application Finder et prend en charge la collecte de données : navigateurs, extensions de portefeuilles de cryptomonnaies, trousseau iCloud, contenu du presse-papiers.
Le voleur affiche une invite native de mot de passe demandant le mot de passe système. Le mot de passe saisi est validé localement via l’API PAM : si la validation échoue, l’invite est réaffichée jusqu’à saisie correcte.
Une fois un mot de passe valide capturé, un second message factice, imitant l’alerte Gatekeeper (« Maccy is damaged and can’t be opened. You should move it to the Trash »), est affiché. Il s’agit d’un leurre : la charge a déjà été exécutée, le mot de passe capturé et la persistance mise en place.
La persistance est assurée par un petit binaire Mach-O arm64 embarqué, qui imite l’apparence de Réglages Système.
Les données collectées sont chiffrées puis exfiltrées vers avenger-sync[.]live par une requête HTTP sortante.
Gravité
Jamf Threat Labs ne publie pas de score CVSS pour cette campagne. L’équipe qualifie cependant PamStealer d’illustration d’une évolution des stealers macOS courants vers des chaînes d’exécution plus discrètes et des implémentations natives qui réduisent les opportunités de détection classiques tout en restant compatibles avec les mécanismes standard de macOS.
Recommandations
Ne télécharger Maccy que depuis le site officiel maccy.app ou depuis le dépôt GitHub officiel du projet.
Ne jamais exécuter un script AppleScript (.scpt) reçu par un canal non vérifié, même s’il semble anodin dans Script Editor : le contenu malveillant peut être caché après plusieurs pages de lignes vides.
Se méfier des sites qui imitent visuellement des marques légitimes (maccyapp[.]com, maccyapp[.]net) : seul maccy.app est le site officiel.
Ne pas saisir son mot de passe système en réponse à une invite déclenchée par une application dont l’origine n’est pas certaine.
Maintenir macOS et les protections XProtect à jour via Mise à jour de logiciels.
Sur un Mac Apple Silicon, considérer que l’absence d’exécution sur Intel ne signifie pas absence de risque : cette variante est spécifiquement optimisée pour Apple Silicon.
Références
Titre de la page
URL officielle
Date de publication
PamStealer: macOS Malware Posing as Clipboard Manager App
Avis de non-responsabilité : Cette publication est générée automatiquement à des fins purement informatives. Bien que les données soient issues de veilles technologiques, elles ne sauraient se substituer aux publications officielles. Pour toute décision relative à la sécurité de vos systèmes, il convient de vérifier et de valider les informations fournies en consultant directement les bulletins officiels du NIST (National Institute of Standards and Technology) et d’Apple Security.
Depuis WWDC 2026, les mises à jour de XProtect et XPR se sont tues. Apple déploie en parallèle deux architectures de protection, introduit l’outil xprotect en ligne de commande et prépare « Golden Gate », un modèle de sécurité natif Apple Silicon. Ce que les notes de version « sans CVE » ne disent pas.
Votre Mac n’a pas reçu de nouvelle signature de malware depuis le 2 juin. L’outil de remédiation XPR, lui, n’a pas bougé depuis le 17 février cent quarante-deux jours d’immobilité, un record historique. Pourtant, aucune alerte n’a été émise, aucun communiqué n’a été publié. Si vous ouvrez l’utilitaire softwareupdate, tout paraît normal. Mais sous le capot, Apple a silencieusement basculé vers une architecture duale de protection, gérée par un nouvel outil en ligne de commande nommé xprotect, qui télécharge ses règles depuis iCloud via un helper privilégié authentifié par la Secure Enclave. Bienvenue dans l’ère « Golden Gate ».
Le silence qui en dit long
Depuis des années, le rythme était métronomique : XProtect (les règles Yara de détection) s’actualisait chaque semaine, XPR (le scanner de remédiation) toutes les quatre à dix-huit semaines. C’était prévisible, documenté, rassurant. Puis, mi-juin 2026, juste après la WWDC, le métronome s’est arrêté. La version 5347 de XProtect, publiée le 2 juin, est restée la dernière en date pendant plus de cinq semaines. Côté XPR, la version 157 du 17 février n’a toujours pas de successeur, pulvérisant le précédent record d’intervalle.
Howard Oakley, sur Eclectic Light Company, a été le premier à pointer cette anomalie le 10 juillet. Ses relevés montrent que les mises à jour XProtect, hebdomadaires depuis dix-huit mois, n’ont été perturbées que par les périodes de fêtes. L’intervalle actuel égale le pire creux de Noël. Quant à XPR, ses 142 jours d’inactivité dépassent largement sa fourchette historique de 30 à 126 jours. Ce n’est pas un oubli : c’est une rupture.
Parallèlement, Apple a publié macOS Tahoe 26.5.1 et iOS 26.5.1 le 1er juin, estampillés « This update has no published CVE entries ». La même mention accompagne les mises à jour 15.7.7 pour macOS Sequoia et 14.8.7 pour macOS Sonoma. En langage clair : ce ne sont pas des correctifs de vulnérabilités connues. Ce sont des changements d’architecture déployés sous couvert de « mises à jour de sécurité sans CVE ».
Deux XProtect, deux canaux, une même machine
Depuis macOS Sequoia (15), votre Mac héberge non plus un mais deux bundles XProtect distincts. Le premier, historique, siège dans /Library/Apple/System/Library/CoreServices/XProtect.bundle et continue d’être mis à jour via le démon softwareupdated — le canal classique des mises à jour système. Le second, nouveau et désormais préféré, occupe un emplacement parallèle géré par l’outil xprotect en ligne de commande et son compagnon privilégié, XProtectRemediatorHelper.
Ce helper s’exécute dans un contexte hautement privilégié, authentifié par la Secure Enclave, et établit une connexion TLS mutuelle vers les serveurs de distribution iCloud pas vers le CDN public d’Apple. La différence est fondamentale : l’ancien canal pousse des mises à jour groupées (batch) selon le calendrier de softwareupdated ; le nouveau permet une distribution continue (push), découplée du cycle de mise à jour du système d’exploitation.
La page de manuel man xprotect, introduite avec macOS Sequoia et Tahoe, documente trois sous-commandes : xprotect status pour inspecter l’état des deux bundles, xprotect update pour forcer une actualisation manuelle du nouveau bundle, et xprotect scan pour lancer un scan à la demande. C’est la première fois qu’Apple expose un outil d’administration de sa protection anti-malware aux administrateurs et utilisateurs avertis.
Pourquoi cette dualité ?
L’architecture historique XProtect/MRT/XPR repose sur un modèle hérité de l’ère Intel : détection par signatures (Yara), remédiation par suppression de fichiers connus, le tout orchestré depuis l’espace utilisateur avec des privilèges élevés. Ce modèle a montré ses limites face aux attaques « ClickFix » qui prolifèrent en 2026 : l’utilisateur est manipulé pour exécuter lui-même un AppleScript malveillant (souvent via Command-R dans un faux terminal), contournant ainsi toute détection de binaire. XProtect ne voit rien, car aucun fichier malveillant n’est écrit sur le disque avant exécution.
La réponse d’Apple ne peut pas être une énième règle Yara. Elle nécessite un changement de paradigme : passer de la détection périodique de fichiers à une vérification continue du comportement, ancrée dans le matériel. C’est là qu’intervient « Golden Gate » le nom de code interne évoqué par Oakley pour désigner la refonte du modèle de sécurité pour Apple Silicon complet.
Golden Gate : le noyau dur de la sécurité Apple Silicon
Le nom de code « Golden Gate » n’apparaît dans aucune documentation publique. Il émerge des observations croisées : l’arrêt simultané des deux canaux de mise à jour, l’introduction de l’outil xprotect avec son helper sécurisé par Secure Enclave, la distribution via iCloud avec TLS mutuel, et les mises à jour « sans CVE » qui modifient l’infrastructure sans corriger de faille référencée.
L’hypothèse technique la plus solide : Golden Gate exploite les primitives matérielles exclusives aux puces Apple Silicon Secure Enclave, démarrage vérifié, mémoire unifiée, extensions de noyau signées Apple pour remplacer le triptyque Gatekeeper + signature de code + SIP (héritage Intel) par un modèle « zero-trust » où chaque exécution de binaire peut déclencher une vérification cloud (avec cache local chiffré). Le containment matériel (isolation via Virtualization Framework + Secure Enclave) remplacerait la détection logicielle pure. XPR serait progressivement remplacé par un « SecurityKit » étendant EndpointSecurity pour les EDR tiers, tandis que les MDM géreraient des « modèles de menace » au lieu de listes blanches/noires.
Ce n’est pas une spéculation gratuite : la documentation développeur XProtect Framework (https://developer.apple.com/documentation/security/xprotect) décrit déjà des API pour l’inspection de code en temps réel, et l’outil xprotect en ligne de commande préfigure l’interface d’administration de ce nouveau modèle.
Ce que cela change pour vous, aujourd’hui
Concrètement, sur un Mac sous macOS Sequoia 15 ou Tahoe 26, vous disposez de deux moteurs de protection actifs. L’ancien continue de recevoir des règles Yara via softwareupdate (quand elles reprennent). Le nouveau, plus réactif, tire ses règles d’iCloud via XProtectRemediatorHelper. Vous pouvez vérifier leur état à tout moment :
`bash xprotect status `
La sortie affiche la version, la date et la source de chaque bundle. Si le nouveau bundle semble périmé, xprotect update force une synchronisation immédiate depuis iCloud. Un xprotect scan ~/Downloads lance un audit à la demande sur un dossier suspect une fonctionnalité inédite pour l’utilisateur final.
Pour les administrateurs de parcs, la dualité impose une vigilance accrue : les profils de configuration MDM qui gèrent les mises à jour de sécurité via softwareupdated ne couvrent plus le nouveau canal. Il faut s’assurer que le trafic vers les serveurs de distribution iCloud (ports 443, TLS mutuel, certificats ancrés dans la Secure Enclave) n’est pas bloqué par un pare-feu d’entreprise mal configuré.
Tableau comparatif : ancien vs nouveau canal XProtect
| Caractéristique | Canal historique (softwareupdated) | Nouveau canal (xprotect + iCloud) | |—————-|————————————–|————————————-| | Emplacement du bundle | /Library/Apple/System/Library/CoreServices/XProtect.bundle | Emplacement parallèle géré par xprotect | | Déclencheur de mise à jour | Calendrier softwareupdated (batch hebdomadaire) | Push continu depuis serveurs iCloud | | Authentification | Certificats Apple standard | TLS mutuel + Secure Enclave | | Outil d’administration | softwareupdate (système) | xprotect (CLI utilisateur/admin) | | Visibilité utilisateur | Aucune (opaque) | xprotect status, xprotect scan | | Résilience aux attaques ClickFix | Faible (signatures statiques) | Potentiellement meilleure (vérif. continue) | | Documentation publique | Notes de mise à jour macOS | man xprotect, page développeur XProtect Framework |
Ce qu’il faut surveiller dans les mois qui viennent
1. Reprise des mises à jour XPR : si le délai dépasse 180 jours sans nouvelle version, cela confirmera l’abandon progressif de l’architecture XPR au profit du modèle Golden Gate. 2. Documentation officielle de xprotect : l’apparition d’une page de support Apple (HTxxxx) dédiée à l’outil CLI signalerait la fin de la phase expérimentale. 3. Extensions EndpointSecurity : les éditeurs EDR tiers (Jamf, Kandji, SentinelOne, CrowdStrike) devront migrer vers les nouvelles API « SecurityKit » si Golden Gate se concrétise. 4. Mises à jour « sans CVE » : chaque occurrence de cette mention dans les notes de version macOS/iOS marquera probablement une brique supplémentaire de l’infrastructure Golden Gate.
En résumé : ce qu’il faut retenir et faire
1. Vérifiez l’état de vos deux XProtect avec xprotect status c’est gratuit, instantané, et ça révèle si le nouveau canal fonctionne. 2. Autorisez le trafic iCloud/TLS mutuel sur vos pare-feux d’entreprise — sans lui, le nouveau canal de protection est coupé. 3. Testez xprotect scan sur les dossiers à risque (Téléchargements, pièces jointes mail) c’est le premier scanner à la demande natif macOS. 4. Suivez les notes de version « sans CVE » elles sont le signal faible en apparence, fortes en réalité architecturale. 5. Anticipez la fin de XPR — si votre stratégie de sécurité repose sur les moteurs de remédiation actuels, préparez la migration vers les API EndpointSecurity étendues.
La protection anti-malware sur Mac ne s’est pas arrêtée : elle a muté. Le silence des mises à jour n’est pas une panne, c’est le bruit d’un changement de moteur en plein vol. Apple ne répare pas une vulnérabilité elle reconstruit la forteresse autour du silicium qu’elle contrôle. C’est ce que « Golden Gate » promet : une sécurité qui ne dépend plus de la fréquence des signatures, mais de la physique de la puce.
Sources
1. Howard Oakley, « Is malware protection changing? », Eclectic Light Company, 10 juillet 2026 — https://eclecticlight.co/2026/07/10/is-malware-protection-changing/ 2. Apple Support, « Apple security releases », HT201222 — entrées macOS Tahoe 26.5.1, iOS 26.5.1, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7 (« This update has no published CVE entries ») — https://support.apple.com/en-us/100100 3. Apple Developer, man xprotect (page de manuel macOS Sequoia/Tahoe) — documentation de l’outil CLI xprotect status, xprotect update, xprotect scan 4. Apple Developer Documentation, XProtect Framework — https://developer.apple.com/documentation/security/xprotect
Versions et matériels concernés : macOS Sequoia 15.x, macOS Tahoe 26.x, Mac à puce Apple Silicon (M1 à M5), Secure Enclave requise pour le helper XProtectRemediatorHelper.
