El mismo macOS, firmware distinto: Apple cambió en silencio las actualizaciones de Sequoia y Sonoma
Dos Mac con Sequoia 15.7.9 pueden tener ahora un firmware mBoot distinto según cuándo se actualizaron. Apple cambió la actualización sin cambiar el número de compilación. Así puede comprobar el suyo.
Tome dos Mac. Ambas ejecutan macOS Sequoia 15.7.9. Ambas muestran el mismo número de compilación en Acerca de este Mac. Una se actualizó el 7 de agosto de 2026, la otra el 28 de agosto. Abra System Information en cada una y mire "System Firmware Version": la primera dice 18000.161.9, la segunda dice 18000.161.10.
Nada en las notas de la versión de Apple explica esto. La actualización 15.7.9 no recibió un nuevo número de compilación. Las notas de seguridad de esa actualización no fueron modificadas. Apple simplemente empezó a distribuir un firmware distinto dentro de la misma actualización, con el mismo nombre, en algún momento después del 17 de agosto, y la única razón por la que alguien lo sabe es que Howard Oakley mantiene máquinas virtuales precisamente para este tipo de comparación y notó que los números habían cambiado.
Este artículo explica qué versión de firmware debería tener su Mac, cómo leerla, por qué el número dejó de coincidir con la versión de macOS y qué —si acaso algo— debería hacer al respecto.
Puntos clave
- Las Mac con Apple silicon en Sequoia 15.7.9 o Sonoma 14.8.9 pueden tener el mBoot
18000.161.9o el18000.161.10, según si instalaron la actualización antes o después del 17 de agosto de 2026. El número de compilación de macOS es idéntico en ambos casos. 18000.161.10es el firmware que se distribuyó solo con Tahoe 26.6.2 el 17 de agosto. Apple después empezó a incluirlo en las actualizaciones —sin cambios aparentes— de Sequoia y Sonoma, sin decirlo.- Desde macOS 26.4, el firmware de Apple silicon se llama a sí mismo «mBoot», no iBoot, y saltó de la serie
13822.xa la18000.x. Verificamos la etiqueta en nuestra propia Mac: el firmware de arranque literalmente se identifica comomBoot-18000.121.3. - Ya no existe una correspondencia fiable entre la versión de macOS y la versión de firmware. Durante seis años sí la hubo. Esa suposición ahora es incorrecta, y las herramientas y comprobaciones de cumplimiento construidas sobre ella producirán falsas alarmas.
- Esto no es evidencia de un ataque. Pero Apple no ha publicado nada sobre qué cambió, así que una Mac con un número de firmware que usted no puede explicar es un problema de auditoría incluso cuando no es un problema de seguridad.
Qué cambió, en una tabla
Toda la historia está en la columna del firmware. Todas las versiones a continuación corresponden a Mac con Apple silicon; las Mac Intel con chip T2 usan una numeración distinta y se tratan por separado más adelante.
| Fecha | Tahoe | Sequoia | Sonoma | Firmware de Apple silicon |
|---|---|---|---|---|
| 12 dic 2025 | 26.2 | 15.7.3 | 14.8.3 | iBoot 13822.61.10 — las tres sincronizadas |
| 24 mar 2026 | 26.4 (25E246) | 15.7.5 | 14.8.5 | mBoot 18000.101.7 — nombre nuevo, numeración nueva; la sincronía se mantiene |
| 11 may 2026 | 26.5 (25F71) | 15.7.7 | 14.8.7 | mBoot 18000.120.36 — sincronizadas |
| 29 jun 2026 | 26.5.2 (25F84) | — | — | mBoot 18000.121.3 — Sequoia y Sonoma se quedan atrás |
| 27 jul 2026 | 26.6 (25G72) | 15.7.8 | 14.8.8 | mBoot 18000.161.9 — vuelven a sincronizarse |
| 6 ago 2026 | 26.6.1 (25G76) | 15.7.9 | 14.8.9 | mBoot 18000.161.9 — sin cambios |
| 17 ago 2026 | 26.6.2 (25G83) | — | — | mBoot 18000.161.10 — solo Tahoe |
| después del 17 ago | — | 15.7.9 (misma compilación) | 14.8.9 (misma compilación) | mBoot 18000.161.10 — cambiado en silencio |
Oakley afirma que los tres sistemas se mantuvieron sincronizados hasta principios del verano, razón por la cual la fila de marzo se muestra como coincidente. Las cifras provienen de sus publicaciones del día de lanzamiento de cada actualización (26.4, 26.5, 26.6, 26.6.1, 26.6.2), más una fila que podemos confirmar directamente: la Mac en la que se escribió este artículo ejecuta 26.5.2 y reporta 18000.121.3.
La última fila es la que importa. Misma versión, misma compilación, firmware distinto, sin ningún anuncio.
Cómo leer la versión de firmware de su propia Mac
Hay tres formas, y la tercera le muestra algo que las dos primeras no.
System Information
Menú Apple > Acerca de este Mac > Más información > Informe del sistema, y luego Hardware en la parte superior de la barra lateral. Dos líneas importan:
System Firmware Version: 18000.121.3
OS Loader Version: 18000.121.3En una Mac sana estas dos coinciden. Son las dos etapas del firmware de arranque, y Apple las actualiza juntas.
Terminal, la vía rápida
system_profiler SPHardwareDataType | grep -E "Firmware|Loader"Las mismas dos líneas, con posibilidad de scripting. Esto es lo que recogen la mayoría de las herramientas de inventario.
Terminal, la vía que muestra la etiqueta
La cadena de versión que muestra macOS es una versión recortada de lo que el firmware reporta de sí mismo. Para ver la versión sin recortar, lea el árbol de dispositivos:
ioreg -p IODeviceTree -n chosen -r | grep -E "firmware-version|iboot-stage"En nuestra Mac con 26.5.2 esto devuelve:
"iboot-stage-two-tag" = <"mBoot-18000.121.3">
"iboot-stage-one-tag" = <"mBoot-18000.121.3">
"system-firmware-version" = <"mBoot-18000.121.3">Hay dos cosas que vale la pena notar. El firmware se llama a sí mismo mBoot. Los nombres de las propiedades todavía dicen iboot. Ese es todo el cambio de nombre en una sola línea: Apple cambió la cadena que reporta el firmware, y dejó intacta la fontanería que la lee.
Qué es realmente «mBoot»
La propia guía de seguridad de la plataforma de Apple describe la cadena de arranque de Apple silicon en cuatro pasos: el Boot ROM, en el silicio, inicia la cadena de confianza; el Low-Level Bootloader (LLB) verifica firmas y obtiene la LocalPolicy desde el Secure Enclave; iBoot carga el resto del firmware, verifica las kernel collections y el hash raíz del volumen de sistema firmado; luego el kernel toma el control. El documento no contiene la palabra «mBoot» en ningún lugar. Según la documentación publicada de Apple, el componente todavía se llama iBoot.
Lo que ocurrió en macOS 26.4 es que cambió la cadena de versión. La nota de lanzamiento de SilentKnight de marzo de Oakley registra la transición apareciendo por primera vez en la beta 2 de 26.4, de iBoot 13822.101.6 a mBoot 18000.101.6, y manteniéndose hasta la versión final 18000.101.7. Su interpretación es que Apple quería «unificar el firmware de Mac y de otros dispositivos bajo el mismo sistema de numeración». Eso es una inferencia; Apple no ha dicho nada. Lo que podemos confirmar es la mitad observable: en cualquier Mac con 26.4 o posterior, las dos etapas de arranque se identifican como mBoot-<versión>, y la numeración empieza en 18000.
En términos prácticos: mBoot es iBoot con una nueva etiqueta de nombre. Hace el mismo trabajo, ocupa el mismo lugar en la cadena, y se actualiza mediante el mismo mecanismo: una actualización o instalación de macOS que resulta contener una versión más nueva.
Por qué el firmware solía coincidir exactamente con macOS
Para entender por qué el cambio de agosto es una ruptura, hay que saber lo ordenada que era la situación antes.
En las Mac Intel sin chip T2, el firmware era específico de cada modelo. Cada instalador de macOS incluía una biblioteca de actualizaciones EFI, una para cada modelo en el que se podía instalar, así que el firmware «correcto» para una Mac dada dependía tanto de la versión de macOS como de la máquina. Oakley compiló esas tablas a mano durante años.
Las Mac con T2 simplificaron esto: una EFI común y una versión de iBridge común por cada versión de macOS, sin importar el modelo.
Apple silicon lo simplificó aún más. Desde 2020 hasta mediados de este año, cada Mac con Apple silicon en una versión determinada de macOS tenía el mismo firmware, y —la parte que importaba para la seguridad— las tres versiones de macOS soportadas actualizaban su firmware al mismo tiempo. Cuando Tahoe 26.2 llevó el firmware a 13822.61.10 en diciembre de 2025, las actualizaciones de seguridad del mismo día para Sequoia 15.7.3 y Sonoma 14.8.3 hicieron lo mismo. La versión de firmware de una Mac le decía exactamente qué actualización de seguridad tenía, sin importar cuál de los tres sistemas ejecutara.
Oakley dice que encontró este vínculo tan sólido que llegó a considerar eliminar por completo las comprobaciones de firmware de SilentKnight.
Cómo se rompió la sincronía en el verano de 2026
La ruptura se produjo en dos pasos.
El primero fue un hueco en el calendario de actualizaciones. Entre el 11 de mayo y el 27 de julio, Sequoia y Sonoma no recibieron ninguna actualización de seguridad. Tahoe recibió dos: 26.5.1, una corrección empresarial para que las Mac con M5 no se apagaran bajo ciertas extensiones de red de filtrado de contenido, y 26.5.2, una actualización de seguridad. La segunda de ellas incluyó una actualización de firmware, a 18000.121.3. Durante unas seis semanas, una Mac con Tahoe y una Mac con Sequoia, ambas completamente parcheadas, ejecutaron firmwares distintos. Oakley lo señaló a finales de junio como «la primera vez en los últimos seis años que un gran número de Mac tendrán un firmware desincronizado».
La oleada del 26.6, el 27 de julio, lo reparó: Tahoe 26.6, Sequoia 15.7.8 y Sonoma 14.8.8 pasaron todos a 18000.161.9, y las actualizaciones del 6 de agosto (26.6.1, 15.7.9, 14.8.9) dejaron el firmware intacto. Todo volvió a coincidir.
Luego, el 17 de agosto, Apple lanzó Tahoe 26.6.2 —la versión fuera de ciclo que incorporó retroactivamente correcciones de la beta de macOS 27— con el firmware 18000.161.10. No hubo ninguna actualización correspondiente para Sequoia o Sonoma. Esos sistemas se quedaron en .9. Desincronizados de nuevo, y esta vez con una versión de seguridad de por medio.
La parte silenciosa
Todo lo anterior es desordenado, pero está documentado: cada una de esas versiones de firmware se reportó el mismo día. Lo que no se documentó es lo que ocurrió después.
Oakley había actualizado sus máquinas virtuales de Sequoia y Sonoma a 15.7.9 y 14.8.9 el 7 de agosto, y desde entonces se han mantenido en 18000.161.9, porque no se les ha ofrecido ninguna actualización posterior. Pero cuando creó máquinas virtuales nuevas de Sequoia y Sonoma el 28 de agosto y las actualizó a esas mismas 15.7.9 y 14.8.9, aparecieron con 18000.161.10, el firmware que hasta entonces solo se había distribuido con Tahoe 26.6.2.
It appears that those Macs that were updated to 15.7.9 or 14.8.9 prior to the release of 26.6.2 on 17 August had their firmware updated to 18000.161.9, while those updated since 17 August have been provided with 18000.161.10 instead, without any change in macOS version or build number. There has been no mention of any such change in Apple's security release notes.
Comprobamos la otra mitad de esa afirmación. La página de contenido de seguridad de Apple para 26.6.2 no menciona en absoluto ni firmware, ni mBoot, ni iBoot. Tampoco lo hacen las páginas de 15.7.9 y 14.8.9. Según el registro público de Apple, no cambió nada.
Una nota sobre la evidencia. La comparación de Oakley usa máquinas virtuales en lugar de Mac físicas. Eso es una fortaleza más que una debilidad para esta pregunta en concreto: en Apple silicon, el firmware de arranque de una VM de macOS lo suministra el propio instalador y actualizador del invitado, así que una VM nueva que reporta .10 tras instalar «15.7.9» significa que el paquete de actualización de 15.7.9 ahora incluye .10. Esto no nos dice cómo se tratará una Mac física que ya está en .9, y no hemos podido probarlo nosotros mismos.
¿Qué número debería tener?
Dada la tabla anterior, esto es lo que cabe esperar.
| Usted ejecuta | Actualizada antes del 17 ago | Actualizada después del 17 ago |
|---|---|---|
| Tahoe 26.6.2 | (no es posible) | 18000.161.10 |
| Tahoe 26.6.1 | 18000.161.9 | — actualizar a 26.6.2 |
| Tahoe 26.5.2 | 18000.121.3 | — actualizar a 26.6.2 |
| Sequoia 15.7.9 | 18000.161.9 | 18000.161.10 |
| Sonoma 14.8.9 | 18000.161.9 | 18000.161.10 |
| Sequoia 15.7.8 / Sonoma 14.8.8 | 18000.161.9 | 18000.161.9 |
Si su Mac con Sequoia o Sonoma muestra 18000.161.10, tiene el firmware más nuevo y no hay nada que hacer. Si muestra 18000.161.9, tiene el firmware que era correcto el día en que se actualizó, y por ahora no existe ninguna actualización que lo cambie: Apple no ha vuelto a ofrecer 15.7.9 ni 14.8.9 a las Mac que ya las tienen.
Cualquier otra cosa —un número 13822.x en una Mac que dice estar en 26.4 o posterior, o un número 18000.x que no aparece en esta tabla— merece entenderse antes de descartarla. La explicación inocente más habitual es que la Mac tiene más de un macOS instalado y usted está leyendo el loader de un volumen distinto; vea Solución de problemas más abajo.
¿Importa esto realmente?
Sinceramente: probablemente no mucho, para la mayoría de la gente, ahora mismo. Pero las razones por las que sí importa merecen enunciarse con precisión, porque son distintas de lo que la gente suele suponer.
No es «su Mac es insegura»
Nadie fuera de Apple sabe qué cambió entre 18000.161.9 y 18000.161.10. Llegó junto a una actualización de seguridad, lo que sugiere que es relevante para la seguridad, pero las versiones puntuales de firmware también corrigen compatibilidad de hardware, gestión de energía y errores en el arranque. Las notas de 26.6.2 de Apple acreditan 28 CVE y ninguno se describe como una corrección de firmware. Si está en .9, tiene el firmware que Apple consideraba vigente hace tres semanas.
Es «su inventario está equivocado»
Durante seis años, la «versión de firmware» fue un atributo derivado: conociendo la versión de macOS, se conocía el firmware. Cualquier cosa construida sobre eso —una regla de cumplimiento, un grupo inteligente de MDM, una hoja de cálculo, un script que marca anomalías— ahora verá dos poblaciones de Mac idénticas y no podrá decirle cuál es la correcta. SilentKnight, la herramienta de consumo más usada para esto, cambió su comportamiento en la versión 3.01 para reportar la versión de firmware como «encontrada» en lugar de juzgarla vigente u obsoleta, precisamente porque ese juicio ya no es posible.
Es «Apple cambió una actualización ya distribuida sin dejar rastro»
Esta es la parte que debería preocuparle más que el número de versión en sí. Las actualizaciones de Apple silicon se aplican mediante lo que Oakley llama el Update Brain, un componente específico de cada actualización que macOS descarga para ejecutar esa actualización en concreto. Apple, evidentemente, cambió lo que instala una de esas actualizaciones, mantuvo idénticos la versión y el número de compilación, y no publicó nada. Su conclusión es contundente:
In the absence of any information from Apple, some could reasonably suspect this was the result of a sophisticated attack.
Él no cree que lo sea. Nosotros tampoco. Pero «no podemos distinguir esto de un ataque usando la información publicada por Apple» no es donde se supone que debe estar un proceso de actualizaciones de seguridad.
Si está en Sequoia o Sonoma y quiere el firmware más nuevo
Tiene tres opciones y solo la primera es recomendable.
Esperar
Oakley espera que Sequoia 15.8 se lance junto con macOS 27 en la segunda mitad de septiembre. Esa actualización casi con toda seguridad incluirá el firmware que sea vigente en ese momento, que para entonces podría ser más nuevo que .10: él espera que el firmware Golden Gate salte a aproximadamente 20457.1.29. Sonoma es un caso distinto: es muy posible que su versión final sea 14.8.9, en cuyo caso una Mac con Sonoma actualizada antes del 17 de agosto se quedará en .9 de forma permanente. Lo cual está bien, porque así se quedó también toda Mac con Sonoma que se actualizó a tiempo.
Reinstalar macOS desde Recuperación
Un «Reinstalar macOS» desde recoveryOS descarga una copia nueva de la versión instalada y puede actualizar el firmware si el instalador contiene uno más nuevo. Dado que las instalaciones nuevas de 15.7.9 ahora incluyen .10, esto podría funcionar. No lo hemos probado, toma una hora, y es una respuesta desproporcionada para una discrepancia en una cadena de versión. No haga esto para perseguir un número.
Reactivación con DFU
El procedimiento de reactivación y restauración de Apple para Mac con Apple silicon recarga el firmware desde una segunda Mac a través de un cable USB-C. Apple dice que la reactivación «no borra su Mac» y que conviene intentarla antes de una restauración, que sí lo hace. Requiere una Mac anfitriona con macOS 14 o posterior y un cable USB-C que admita datos y carga: Apple indica explícitamente que no se use un cable Thunderbolt 3. Esta es la herramienta correcta para una Mac que no arranca. Es la herramienta equivocada para una Mac que arranca sin problemas y tiene un número de firmware que no le gusta. Se menciona solo para que sepa que existe.
Si está en Tahoe
Si está en 26.6.2, ya tiene .10 y nada de esto le aplica. Si está en 26.6.1 o una versión anterior, la solución es la actualización que de todos modos debería instalar.
El próximo cambio de firmware que vea será el grande. El firmware de Golden Gate, según la lectura de Oakley de las betas, pasa a una serie 20457.x. El nuevo Mac mini y el Mac Studio se lanzan el 22 de septiembre con una compilación previa de macOS 27 y necesitarán una actualización inmediata a 27.0.1: se espera que su firmware cambie al mismo tiempo.
Para administradores de flotas
Tres ajustes concretos.
Deje de tratar la versión de firmware como algo derivable de la versión de macOS. Cualquier regla del tipo «15.7.9 implica 18000.161.9» ahora es incorrecta para una parte de su flota, y esa parte queda definida por el momento de la actualización, algo que probablemente no registró.
No genere alertas solo por .9 frente a .10. Ambos son resultados legítimos de la misma actualización de Apple. Si quiere un único valor por versión de macOS con el que comparar, use el más nuevo como objetivo y trate .9 como «correcto a la fecha de instalación, convergerá en la siguiente actualización».
Registre la versión de firmware en el momento de la inscripción y en cada actualización, para poder distinguir «esta Mac se actualizó pronto» de «el firmware de esta Mac cambió sin una actualización de macOS», que es el caso que realmente merece una revisión. En Apple silicon, el firmware solo cambia durante una instalación o actualización de macOS, así que un cambio de firmware sin un cambio de macOS correspondiente es la anomalía a vigilar, no una discrepancia entre dos Mac.
Qué debería hacer Apple
Es una petición pequeña. Las páginas de contenido de seguridad de Apple ya listan cada componente y cada CVE de una actualización. Añadir una línea —«Esta actualización incluye mBoot 18000.161.10»— no costaría nada y habría hecho visible el cambio de agosto el mismo día en que ocurrió. Si el cambio fue deliberado y benigno, que es con diferencia el caso más probable, no hay razón para dejar que la gente lo descubra comparando máquinas virtuales.
Mac Intel
Las Mac Intel con chip T2 reportan dos componentes de firmware: el firmware de sistema de estilo EFI y el iBridge del T2 (bridgeOS). La publicación de Oakley sobre 26.6.2 los da como 2103.160.2.0.0 y iBridge 23.16.16068.0.0,0, sin cambios respecto a 26.6.1. La historia de mBoot no aplica en absoluto al hardware Intel; la numeración nunca cambió y la sincronía de las tres versiones nunca se rompió ahí. Las Mac Intel en Tahoe están en su última versión de macOS de todos modos, así que este es el linaje de firmware final que verán.
Solución de problemas comunes
System Information muestra dos números distintos
«System Firmware Version» y «OS Loader Version» normalmente coinciden. La razón más habitual de que difieran es que la Mac tiene más de un volumen de macOS instalado —por ejemplo, una beta de Golden Gate en un volumen separado— y el loader reportado es el emparejado con un sistema distinto. Arranque en el otro volumen y compare. Si difieren con un único macOS instalado, eso es inusual y vale la pena reportarlo a Apple.
SilentKnight dice «encontrada» en lugar de «vigente»
Es la herramienta funcionando como está diseñada desde la versión 3.01. Ya no puede decirle si su firmware es el más reciente, porque Apple ya no garantiza una única respuesta por versión de macOS. Compare con la tabla anterior en su lugar.
Una máquina virtual muestra una versión de firmware que no coincide con la del anfitrión
Es lo esperado. En Apple silicon, el firmware de una VM de macOS proviene del instalador del invitado, no de la Mac anfitriona. Esta es exactamente la razón por la que las VM de Oakley pudieron revelar el cambio.
ioreg no devuelve nada para el nodo chosen
Probablemente esté en una Mac Intel, donde el árbol de dispositivos está organizado de forma distinta y no existe iboot-stage-one-tag. Use en su lugar system_profiler SPHardwareDataType, que reporta «Boot ROM Version» y, en las Mac con T2, la versión de iBridge bajo Controller.
Mi Mac con Sequoia muestra 18000.161.10 pero la actualicé el 7 de agosto
Entonces algo actualizó el firmware después de esa fecha. Los candidatos son una reinstalación de macOS, una reactivación, o una actualización que pasó desapercibida. Revise Software > Instalaciones en System Information por si hay algo fechado después del 17 de agosto. Si no hay nada, tome nota: un cambio de firmware sin una instalación correspondiente es el único patrón de este artículo que merece una segunda mirada.
Preguntas frecuentes
¿Es 18000.161.10 una corrección de seguridad?
Se desconoce. Se distribuyó junto con una versión de seguridad y Apple no ha descrito su contenido. Trátelo como «más nuevo», no como «corrige una vulnerabilidad conocida».
¿Debo hacer algo si mi Mac está en 18000.161.9?
No. Era el firmware correcto el día en que se actualizó, y la próxima actualización de macOS que instale traerá el vigente. No hay ninguna vulnerabilidad expuesta que Apple haya asociado con .9.
¿Por qué el firmware se llama a sí mismo mBoot cuando los documentos de Apple dicen iBoot?
Apple renombró la cadena de versión en macOS 26.4 y no ha actualizado su documentación de seguridad para reflejarlo. En nuestra Mac el firmware reporta mBoot-18000.121.3, mientras que las claves del árbol de dispositivos que lo almacenan todavía se llaman iboot-stage-one-tag y iboot-stage-two-tag. Funcionalmente, es el mismo componente.
¿Puede cambiar el firmware sin una actualización de macOS?
En Apple silicon, no: el firmware solo se escribe durante una instalación, actualización, reactivación o restauración de macOS. Por eso un cambio de firmware sin un registro de instalación correspondiente es el caso genuinamente anómalo.
¿macOS 27 arreglará la sincronía?
La reiniciará. Se espera que Golden Gate, Tahoe 26.7 y Sequoia 15.8 lleguen juntos en septiembre y que compartan firmware desde el primer día. Si Apple los mantiene sincronizados después, o repite el patrón de este verano, es la pregunta abierta.
Conclusión
Durante seis años, la versión de firmware de una Mac con Apple silicon fue función de una sola cosa: la versión de macOS. Eso la hacía útil: un único número que le decía qué actualización de seguridad tenía una Mac, sin importar si ejecutaba la versión actual de macOS o una de las dos anteriores. Este verano eso dejó de ser cierto, primero porque las actualizaciones de mitad de ciclo de Tahoe llevaban un firmware que los sistemas más antiguos no recibían, y luego, de forma más grave, porque Apple cambió lo que instalan las actualizaciones de Sequoia y Sonoma sin cambiar nada visible en ellas.
Nada de esto hace que su Mac sea menos segura. Sí hace que el número de firmware sea más difícil de interpretar, hace menos útiles las herramientas que dependían de él, y demuestra que Apple revisará una actualización ya distribuida en silencio. Si administra Mac, ajuste sus expectativas ahora, antes de que la oleada de lanzamientos de septiembre añada una cuarta versión de macOS al panorama. Si no lo hace, la conclusión práctica es más sencilla: .9 y .10 están ambos bien, y el número que hay que vigilar es el que cambia cuando nada más lo hizo.
Lectura relacionada: macOS Tahoe 26.6.2 y quién encontró sus 28 CVE, la corrección de Screen Sharing en 26.6.1, cómo funcionan las actualizaciones de seguridad en segundo plano en Tahoe, y qué hacer cuando una actualización de macOS deja una Mac sin poder arrancar.