Apple DeepTech : macOS 26.4 : Les UUID des apps deviendraient éphémères (et c’est un pivot sécuritaire)

macOS 26.4 semble introduire un changement discret dans la manière dont certaines permissions sont associées aux applications : des UUID différents seraient désormais générés à chaque nouvelle session système et deviendraient invalides après un redémarrage du Mac.

macOS 26.4 : Apple modifie discrètement la gestion des permissions persistantes

macOS 26.4 semble introduire un changement discret dans la manière dont certaines permissions sont associées aux applications : des UUID différents seraient désormais générés à chaque nouvelle session système et deviendraient invalides après un redémarrage du Mac.

Apple n’a, à ce jour, publié aucune documentation officielle détaillant cette évolution. Les observations proviennent principalement d’analyses indépendantes menées par Howard Oakley autour du mécanisme MACL (Mandatory Access Control List).

En apparence, il pourrait s’agir d’un simple changement d’implémentation interne. Pourtant, les conséquences potentielles sont importantes : une permission accordée pendant une session pourrait ne plus être réutilisable automatiquement après un redémarrage.

L’objectif semble clair : réduire les mécanismes d’accès persistants et limiter les possibilités de compromission sur le long terme.

Une évolution discrète vers des autorisations plus éphémères

Jusqu’à présent, certaines autorisations reposaient sur des identifiants relativement stables. Si ces observations sont confirmées, macOS évoluerait progressivement vers un modèle davantage centré sur l’intention immédiate de l’utilisateur.

Autrement dit, les autorisations ne seraient plus forcément considérées comme acquises durablement.

Le bénéfice potentiel est évident : compliquer la tâche des attaques qui s’appuient sur des permissions persistantes.

Le revers existe aussi : davantage de friction pour certaines applications professionnelles ou certains outils d’administration.

Exploration technique : comprendre MACL

Depuis macOS Catalina, Apple utilise un attribut étendu appelé com.apple.macl pour enregistrer certaines autorisations liées aux fichiers.

Ce mécanisme contient généralement :

  • un en-tête de deux octets ;
  • un UUID associé à une application autorisée.

L’évolution observée jusqu’à présent ressemble à ceci :

Avant octobre 2019 : L’existence même du mécanisme MACL reste relativement discrète et peu documentée publiquement.

Octobre 2019 : Quinn « The Eskimo! » (Apple Developer Forums) évoque publiquement une structure composée d’un en-tête 01 00 suivi d’un UUID.

Octobre 2020 : Adam Chester documente une évolution utilisant un en-tête 02 00 avec un UUID considéré comme stable et persistant.

macOS 26.4 (avril 2026) : Les analyses récentes de Howard Oakley suggèrent qu’un UUID différent pourrait être attribué à chaque nouvelle session.

Si ce comportement est confirmé, une permission accordée lors d’une session précédente pourrait ne plus être reconnue automatiquement après un redémarrage.

Ce mécanisme pourrait ainsi réduire fortement l’intérêt d’attaques reposant sur des identifiants persistants précédemment compromis.

Plusieurs impacts commencent déjà à se dessiner :

  • Certains scripts de sauvegarde automatisés pourraient nécessiter une nouvelle autorisation après redémarrage.
  • Certaines applications professionnelles de synchronisation pourraient devoir revoir leur modèle de gestion des accès.
  • Les techniques d’attaque utilisant des permissions persistantes deviendraient plus complexes à maintenir.
  • Apple renforcerait l’isolation entre les sessions, avec un impact potentiel sur l’expérience utilisateur.

Comme souvent en sécurité, il s’agit probablement d’un équilibre : plus de protection, au prix d’un peu moins de transparence pour l’utilisateur.

Tableau des sources

TitreURLAuteurDate
The MACL extended attributehttps://eclecticlight.co/2026/04/21/the-macl-extended-attribute/Howard OakleyAvril 2026
Privacy: how locations are protectedhttps://eclecticlight.co/2026/04/20/privacy-how-locations-are-protected/Howard OakleyAvril 2026
We Need To Talk About MACLhttps://blog.xpnsec.com/we-need-to-talk-about-macl/Adam ChesterOctobre 2020
Apple Developer Forums – MACL first mentionhttps://developer.apple.com/forums/thread/124121Quinn « The Eskimo! »Octobre 2019

Vous avez une question, une idée ou une remarque ? Je serai ravi de vous lire : henrido@hdrapin.com