Qué publicó Apple el 27 de julio
Las páginas de seguridad de Apple se llenaron de golpe el 27 de julio. macOS Tahoe 26.6 llegó como compilación 25G72 con 155 identificadores CVE únicos, acompañado de Safari 26.6. iOS 26.6 y iPadOS 26.6 enumeraron 78 entradas separadas de vulnerabilidad vinculadas a 87 CVE únicos. Las actualizaciones de watchOS, tvOS y visionOS 26.6 sumaron otras 194 una vez eliminado el solapamiento entre plataformas.
Los componentes citados se leen como un inventario del sistema entero y no como un rincón débil concreto. En el teléfono las correcciones tocan el núcleo, WebKit, la conexión inalámbrica, Siri, la App Store, MediaRemote, ImageIO, SceneKit, libc, CloudAttestation, Game Center, Accesibilidad y Contactos. En el Mac las descripciones son más crudas: fallos que podían permitir a una aplicación obtener permisos de administrador, salir de su entorno aislado, sortear Gatekeeper, esquivar las preferencias de privacidad o alcanzar datos protegidos.
Apple no afirma que ninguno estuviera siendo explotado antes de publicar las actualizaciones, y ningún medio ha aportado pruebas de lo contrario. Contarlos resulta curiosamente difícil: publicaciones especializadas que trabajan sobre el mismo documento de Apple llegan a cifras de entre unos 130 y 155, según cuenten entradas o identificadores. Esa horquilla es un detalle menor, pero indica que el inventario está escrito para que lo lea una persona y no para que lo procese una herramienta.
Los siete intentos son lo que conviene leer
Lo decisivo no está en el número de CVE. macOS Sequoia 15.7.8 y macOS Sonoma 14.8.8 salieron el mismo día, y alcanzaron la publicación solo después de que Apple emitiera siete candidatas a versión final. Una quinta candidata el 13 de julio ya resultó bastante inusual como para que se informara de ella por sí sola. Después llegaron dos más.
Léalo como una señal de ingeniería, no como una anécdota. Una candidata a versión final es la compilación que el fabricante considera terminada. Emitir siete significa que Apple creyó repetidamente que la adaptación estaba lista y descubrió repetidamente que no lo estaba. La rama actual, Tahoe, no necesitó ese vaivén: se escribió una sola vez contra el código para el que se concibieron las correcciones.
Entre las dos, Sequoia 15.7.8 y Sonoma 14.8.8 resuelven más de 138 vulnerabilidades distintas. El volumen es comparable al de Tahoe. Lo que cambia es la dificultad de llevarlo hasta allí, y las notas de versión de Apple para las dos ramas antiguas apenas dicen nada al respecto: solo ofrecen que se trata de correcciones de seguridad importantes, recomendadas para todos los usuarios que sigan en ellas.
El argumento de la estabilidad funciona al revés
La mayoría de las flotas que van una versión por detrás lo hacen a propósito. El razonamiento es conocido y casi siempre sensato: que sean otros quienes encuentren las regresiones, mantener el parque en una compilación que lleva el tiempo suficiente en el mundo como para resultar aburrida y actualizar cuando el negocio tenga una semana tranquila. Aplicada a las funciones, esa lógica se sostiene.
Aplicada a los parches de seguridad, el 27 de julio la invierte. La rama antigua no es la más asentada. Es la que exigió siete intentos, porque una adaptación hacia atrás no es el mismo trabajo que una corrección: el fallo se encuentra y se repara en el código actual y luego se traslada hacia atrás a una base de código que entretanto ha seguido avanzando. Cada versión de distancia entre su parque y la primera línea de Apple es distancia técnica que alguien tiene que cubrir con prisa, y este mes hicieron falta siete pasadas.
La consecuencia de segundo orden tiene que ver con las pruebas y no con el apetito de riesgo. La NIS2 exige a las organizaciones afectadas tratar las vulnerabilidades como un proceso documentado y no como un instinto, y la pregunta de una auditoría rara vez es si usted parcheó. Es cuándo lo supo, qué decidió y por qué. "Nos quedamos una versión atrás por estabilidad" es una respuesta defendible solo hasta que el registro muestra que la rama antigua recibe las correcciones de forma más lenta y más frágil. En España ese registro lo leen el INCIBE y el CCN-CERT según el tipo de entidad.
El orden de trabajo de esta semana
Empiece por las máquinas que ya están expuestas, no por las más fáciles de alcanzar. Todo lo que use Safari o WebKit contra páginas no confiables, cualquier Mac en el que un usuario estándar pudiera ser engañado de forma verosímil para abrir un archivo manipulado y cualquier equipo fuera de la red de la oficina pertenece a la primera oleada. Las elusiones de Gatekeeper y de las preferencias de privacidad pesan sobre todo en los portátiles que salen del edificio.
Después aborde el parque antiguo con honestidad. Si un grupo de Mac está en Sonoma o Sequoia porque el equipo físico no admite Tahoe, eso es un hecho que se planifica y que en algún momento se presupuesta, no una postura que se defiende. Si están en una versión antigua por decisión propia, este es el mes de preguntar si esa decisión sigue comprando lo que se suponía que compraba.
Una cosa que conviene anotar. Registre la fecha de publicación de las notas y la fecha en que se actualizó cada grupo de dispositivos, porque la distancia entre esas dos cifras es lo único de todo esto que una auditoría podrá comprobar después, y lo único que usted controla.
Leer a continuación: El parche de nginx ya está, el exploit llega en agosto | Dos fallos de Cursor con 9.8 entregan la máquina del desarrollador a los atacantes



