redinpulse/cve-2026-84568PoCs de laboratório reproduzíveis para o automountd do macOS e análise guiada pelo código-fonte para CVE-2026-84568 (path traversal em fstype levando à execução de código como root) e CVE-2026-84570 (bypass do Gatekeeper).
Uma análise pública e orientada por fontes do CVE-2026-84568 e do CVE-2026-84570, com provas reversíveis para entrada LDAP/OD, entrega via NFS, despacho de helper, comportamento do Gatekeeper e a fronteira do nó de dispositivo.
Status de publicação — outubro de 2026. A Apple corrigiu ambas as vulnerabilidades em 14 de setembro de 2026 no macOS Sequoia 15.8, macOS Tahoe 26.7 e macOS Golden Gate 27. O reprodutor neste repositório destina-se apenas a um laboratório isolado e autorizado contendo um Mac intencionalmente sem patch.
Status de validação. Os validadores no host incluídos foram executados com sucesso em um host de laboratório macOS 26.4 (build 25E246, arm64) afetado. O teste de despacho de helper, a cadeia completa de entrega NFS via loopback, a sonda de pathname/credenciais, o diferencial do Gatekeeper e o teste de fronteira nodev/dispositivo retornaram todos PASS. No teste do Gatekeeper, as avaliações estavam habilitadas; o app era estruturalmente válido, mas assinado ad-hoc sem Team ID; a avaliação explícita via spctl o rejeitou; o mount NFS não tinha noexec nem quarentena; e o LaunchServices o executou sem uma etapa de aprovação. Cada validador também retornou cleanup_result=PASS, e uma verificação independente pós-execução confirmou que seus registros de diretório temporário, mounts, arquivos e alterações em /etc/exports foram removidos ou restaurados. O harness em Python foi exercitado separadamente contra um servidor OpenLDAP temporário com o esquema real de atributos automount/Apple: tanto a rota automountKey quanto a apple-user-homeurl passaram nas verificações de criação/leitura de volta/timeout/restauração. Essas observações caracterizam aquela build afetada e o harness incluído; não são afirmações sobre versões corrigidas.
Crédito de pesquisa: Mr.Gedik (@h4ck2s3c); o CVE-2026-84568 é creditado publicamente a Mr.Gedik, e o CVE-2026-84570 a Mr.Gedik, nos avisos da Apple.
Esta é a versão pública da pesquisa. Contém apenas informações respaldadas pelos avisos publicados da Apple, pelo código open-source da Apple e pelo material de laboratório reproduzível incluído. Identificadores de casos privados, comunicações privadas, artefatos não públicos e pesquisas não relacionadas são intencionalmente excluídos.
Os dois CVEs compartilham uma superfície de ataque, mas representam causas-raiz independentes:
| CVE | Impacto publicado pela Apple | Fronteira no lado do cliente |
|---|---|---|
| CVE-2026-84568 | Um atacante de diretório de rede pode executar código arbitrário com privilégios de root | Um fstype controlado pelo diretório influenciava o caminho do executável selecionado pelo automountd |
| CVE-2026-84570 | Um app pode contornar as verificações do Gatekeeper | Um automount NFS controlado pelo diretório cruzava tanto a fronteira de proveniência de aplicação quanto a de política de nó de dispositivo |
A Apple lista ambos os problemas em autofs no conteúdo de segurança para macOS Golden Gate 27, macOS Tahoe 26.7 e macOS Sequoia 15.8.
Os mapas de automount do macOS são dados de controle executáveis. Uma linha de mapa seleciona um tipo de sistema de arquivos, fornece opções de mount, identifica um recurso e, em última instância, influencia o despacho privilegiado de mount. Antes das atualizações de setembro de 2026, duas falhas de validação permitiam que dados fornecidos pelo diretório cruzassem fronteiras de segurança no cliente:
fstype forjado podia escapar do namespace pretendido de helpers /sbin/mount_<type> e resolver para um executável entregue via NFS.nodev esperada. O mount de rede resultante também não tinha política de noexec nem de quarentena, de modo que um app que falhasse em uma avaliação explícita do Gatekeeper ainda podia ser iniciado a partir dele.Essas são observações relacionadas, não mecanismos intercambiáveis. nodev controla se vnodes de dispositivos especiais são interpretados; ele não implementa o Gatekeeper. noexec controla a execução na fronteira do VFS. O Gatekeeper avalia separadamente a confiança e a proveniência da aplicação. O validador do CVE-2026-84570 relata cada fronteira de forma independente, para que uma flag nodev ausente nunca seja apresentada como prova de um bypass do Gatekeeper por si só.
O acesso de escrita ao diretório é um pré-requisito de entrada, não a autoridade resultante. Alterar um atributo de automount ou de home do usuário não é equivalente a escolher um caminho de executável em cada Mac consumidor nem a enfraquecer a política do kernel de uma montagem NFS. Essas transformações ocorrem no cliente.
stat() direto por uma conta sem privilégios retornou ENOTDIR; portanto, um resultado de realpath() ou stat() sem privilégios não é um proxy válido para o automountd aqui.nodev demonstrado para o CVE-2026-84570. A cadeia completa do 84568 teve sucesso enquanto sua montagem de entrega mantinha nodev e nosuid.A configuração padrão de automount expõe entradas baseadas em diretório abaixo de /home:
/etc/auto_master: /home auto_home -nobrowse,hidefromfinder
/etc/auto_home: +auto_home
/etc/auto_home: +/usr/libexec/od_user_homes
A primeira inclusão resolve registros de automount. A inclusão do mapa executável invoca od_user_homes, que resolve informações de diretório pessoal do usuário e emite uma linha de mapa. Ambas as rotas convergem no parser de automount.
O harness público mantém ambas as formas de diretório explícitas:
| Rota | Entrada de diretório | Chave/valor autofs resultante |
|---|---|---|
automount | Entrada RFC 2307 cujo RDN é automountKey=<key> sob um mapa automountMapName=auto_home; valor em automountInformation | <key> → linha de mapa bruta |
userhome | Entrada de usuário existente; valor em apple-user-homeurl | a chave de nome de registro do usuário → linha de mapa envolvida em <home_dir><url>…</url></home_dir> |