CVE-2026-28912 — Notas de ingeniería inversa y reproducción

Ingeniería inversa independiente del bug de seguimiento de enlaces simbólicos de macOS PackageKit (CVE-2026-28912), además de un PoC funcional que demuestra que el instalador escribe un archivo controlado por el atacante como root a través de un enlace simbólico de directorio en la ruta de destino de instalación.

El bug es un recorrido de ruta no sincronizado en la lógica de reenlace de archivos de PKCoreShove. Un .pkg malicioso puede declarar una ruta de destino en un directorio sin privilegios, colocar un enlace simbólico de directorio en uno de los componentes de la ruta apuntando a una ubicación privilegiada, y provocar que el instalador — ejecutándose como root — escriba en el objetivo del enlace simbólico. La corrección de Apple en 26.6 añade _PKSIPOpenPathSafely, que recorre cada componente de la ruta con O_NOFOLLOW y rechaza cualquier enlace simbólico.

El CVE de un vistazo

Campo	Valor
CVE	CVE-2026-28912
Componente	PackageKit (PKCoreShove, PKBundleComponent)
Afecta a	macOS Tahoe 26.5 y anteriores
Parcheado en	macOS Tahoe 26.6
Impacto del aviso	"Una app podría obtener privilegios de root."
CVSS v3.1	7.8 (Alto)
Reportado por	Descubridores originales según el aviso de Apple

Por qué existe este análisis

El aviso de Apple para CVE-2026-28912 documenta el impacto y la versión parcheada. No documenta el mecanismo técnico:

Qué función de PackageKit sigue el enlace simbólico
Por qué el instalador recorre la ruta de destino sin comprobar cada componente
Qué función se añadió en 26.6 para cerrar el bug
Por qué la corrección inserta un recorrido con O_NOFOLLOW exactamente en ese punto
Por qué el PoC debe usar un enlace simbólico de directorio en lugar de un enlace simbólico de archivo
Por qué un enlace simbólico a nivel de archivo en el destino se reemplaza en lugar de seguirse

No se encontró ningún análisis técnico público en el momento de escribir esto. Este repositorio llena ese vacío con un análisis de ingeniería inversa independiente de PackageKit entre 26.4 y 26.6, y un PoC funcional que demuestra la primitiva en vivo.

Esto no es una reclamación de descubrimiento. El CVE fue reportado por los descubridores originales y parcheado por Apple. La contribución aquí es el análisis técnico y la reproducción.

Resumen de la vulnerabilidad

PKCoreShove _relinkFile:dest: en macOS 26.4 recorre la ruta de destino componente por componente al crear un archivo:

; macOS 26.4, PackageKit
1a9fb14f8   _relinkFile:dest:
    ...
    bl   _linkResolutionProhibitted     ; returns 0 in the normal case
    mov  w8, 0x10                       ; RENAME_NOFOLLOW_ANY
    cmp  w0, 0
    csel w22, w8, wzr, ne               ; w22 = 0x10 if prohibited, else 0
    ...
    mov  x2, x22
    bl   _renamex_np                    ; uses w22 as flags

_linkResolutionProhibitted devuelve 0 (falso) cuando el proceso llamador no puede modificar archivos SIP — el caso normal para una instalación iniciada por el usuario. Eso desactiva RENAME_NOFOLLOW_ANY, por lo que el rename sigue cualquier enlace simbólico en la ruta de destino.

La corrección de 26.6 añade _PKSIPOpenPathSafely, llamada desde PKBundleComponent initWithBundleAtPath:relativeToDestination::

; macOS 26.6, PackageKit
1aa6dfe18   bl   _PKSIPOpenPathSafely    ; walks each component with O_NOFOLLOW

_PKSIPOpenPathSafely:

Abre cada componente de la ruta con O_NOFOLLOW (0x4)
Detecta enlaces simbólicos mediante S_IFLNK (0xa000 en st_mode)
Comprueba la protección SIP mediante _PKSIPFullyProtected
Lee SF_RESTRICTED mediante fgetattrlist
Usa close_drop_np para liberar la extensión de sandbox en la limpieza

Cualquier componente que sea un enlace simbólico apuntando fuera de la ruta prevista se rechaza con EPERM o ELOOP, y la instalación falla.

Qué contiene este repositorio

Ingeniería inversa

Diff de desensamblado de PKCoreShove _relinkFile:dest: y _linkResolutionProhibitted entre 26.4 y 26.6
Identificación del campo vulnerable: _linkResolutionProhibitted devolviendo 0 para procesos que no modifican SIP
Identificación de la corrección: _PKSIPOpenPathSafely añadida a PKBundleComponent, recorrido con O_NOFOLLOW por componente
Análisis de llamadas al sistema: el instalador usa renamex_np con RENAME_NOFOLLOW_ANY = 0x10 solo cuando el llamador puede modificar archivos SIP
Confirmación en tiempo de ejecución: fs_usage muestra al instalador hacer stat/listxattr sobre el objetivo del enlace simbólico y escribir a través del enlace simbólico de directorio

Consulta docs/ANALYSIS.md para el análisis completo y docs/ARTIFACTS.md para direcciones y muestras de logs.

Reproducción

link.sh — un PoC autocontenido de un solo archivo:
1. Crea un enlace simbólico de directorio en $HOME/cve-poc/target → $HOME/cve-poc/real
2. Construye un .pkg cuyo payload declara un archivo en $HOME/cve-poc/target/poc.txt
3. Lo instala con sudo installer
4. Verifica que el archivo aterrizó en $HOME/cve-poc/real/poc.txt — con propietario root:wheel

Qué demuestra este PoC

Un payload .pkg que declara un archivo bajo un directorio sin privilegios
El instalador siguiendo un enlace simbólico de directorio en esa ruta
Un archivo propiedad de root siendo creado fuera del destino declarado
Captura en vivo de la escritura mediante fs_usage

Qué NO demuestra este PoC

Un enlace simbólico a nivel de archivo en el destino. Los enlaces simbólicos de archivo son reemplazados por renamex_np, no seguidos — la escritura debe ser a través de un enlace simbólico de directorio en la ruta.
Ejecución de código, escalada de privilegios o una shell en la víctima
Weaponización: el PoC usa por defecto $HOME/cve-poc/real/, no /etc/sudoers.d/ o /Library/LaunchDaemons/

El impacto demostrado es la primitiva de seguimiento de enlaces simbólicos — el comportamiento exacto que la corrección de 26.6 cierra.

Requisitos

Host objetivo (víctima)

macOS Tahoe 26.5 o anterior (PackageKit vulnerable)
pkgbuild, installer, fs_usage
Root (para el instalador)

No se necesita un host atacante separado

El PoC se ejecuta completamente en el objetivo. Tanto el enlace simbólico como el payload se crean localmente. Esto mantiene el PoC autocontenido y reproducible sin ninguna configuración de red.

Uso

chmod +x link.sh
./link.sh

Ajuste opcional mediante variables de entorno:

sudo CONTENT="test content" ./link.sh

CONTENT establece el contenido escrito a través del enlace simbólico. Por defecto es hello.

Salida esperada

[*] System information:
ProductName:        macOS
ProductVersion:     26.4
BuildVersion:       25E246

[*] Setup...
    Symlink:  /Users/nerd/cve-poc/target → /Users/nerd/cve-poc/real

[*] Build .pkg...
    Payload:  /Users/nerd/cve-poc/payload/Users/nerd/cve-poc/target/poc.txt
    Package:  /Users/nerd/cve-poc/poc.pkg

[*] Install (password prompt expected)...
installer: Package name is poc
installer: Installing at base path /
installer: The install was successful.

[✓] VULNERABILITY CONFIRMED
    Landed at /Users/nerd/cve-poc/real/poc.txt
    Owner:   root:wheel
    Content: hello

CVE-2026-28912 trigger SUCCESSFUL

Verificación del parche

En un sistema parcheado (26.6), el mismo PoC falla:

[✗] Not triggered
No file was created in /Users/nerd/cve-poc/real/

Consulta docs/PATCH_DIFF.md para la comparación de desensamblado.

Detalles a tener en cuenta con .pkg (para reproducibilidad)

Dos detalles del PoC se descubrieron durante el desarrollo y se documentan aquí para que otros que construyan herramientas similares no se topen con ellos:

cve-2026-28912

Más Populares