La primera versión candidata de Linux 7.3 llega con soporte de arranque para Apple M3 y una revisión de KVM, Omarchy publicó su segunda versión de seguridad en seis días tras formalizar su equipo dedicado, y SCTPhantom y RefluXFS suman 27 y 46 días sin parche completo en las LTS de Ubuntu.
La primera versión candidata de Linux 7.3, publicada el 30 de agosto en el repositorio oficial del kernel, suma soporte de arranque para los Apple M3 Pro, Max y Ultra y una revisión completa de KVM.
El repositorio oficial del kernel Linux en GitHub registró el 30 de agosto de 2026 la etiqueta v7.3-rc1, la primera versión candidata del ciclo 7.3, publicada por Linus Torvalds tras el cierre de la ventana de fusión que esta sección reportó el sábado anterior. La nueva candidata eleva el código fuente del kernel a cerca de 41 millones de líneas y suma soporte de arranque inicial para los procesadores Apple M3 Pro, M3 Max y M3 Ultra, además de compatibilidad con el controlador Thunderbolt en equipos con Apple Silicon, según reportó LinuxCompatible. La lista de cambios también añade soporte para la infraestructura UALink de AMD y para aceleradores CXL de Tipo 2, dos tecnologías orientadas a centros de datos de inteligencia artificial, y marca al planificador sched_ext como funcionalmente completo, según la misma cobertura, republicada por 9to5Linux y Tux Machines. El respaldo a chips de Apple llega después de años de soporte comunitario no oficial a través del proyecto Asahi Linux, mientras que UALink y CXL Tipo 2 posicionan al kernel para el hardware de entrenamiento de inteligencia artificial que fabricantes como AMD empujan como alternativa a Nvidia. El lanzamiento estable de Linux 7.3 está calculado para la segunda mitad de octubre de 2026, el 18 o el 25 de ese mes, según LinuxCompatible. Costa Rica no tiene fabricantes de procesadores Apple, AMD o infraestructura CXL identificados en esta cobertura, pero cualquier desarrollador tico que use una MacBook con chip M3 bajo Asahi Linux o Fedora Asahi Remix se beneficiará del soporte de arranque oficial en cuanto la versión estable llegue a su distribución.
cat /feed/distribucioneslinuxomarchy.md
El repositorio oficial del proyecto liderado por David Heinemeier Hansson publicó la madrugada del 31 de agosto una nueva versión validada por el equipo Omarchy Security, con corrección de una falla de inyección de comandos en los instaladores de temas.
> El repositorio oficial de Omarchy en GitHub publicó la madrugada del 31 de agosto, a las 03:42 UTC, la versión 4.0.2 de la distribución, descrita en sus notas de lanzamiento como "un conjunto adicional de parches de seguridad validados y examinados por el equipo Omarchy Security" (traducción de esta sección). La lista de cambios corrige una vulnerabilidad de inyección de comandos de shell en los instaladores de temas y aplicaciones, exige paquetes firmados del repositorio oficial de Omarchy, endurece los permisos del directorio de políticas del navegador y desactiva por defecto la autenticación por contraseña en las instalaciones de SSH que el sistema configura, según el registro de cambios en github.com/basecamp/omarchy.
> La versión llega apenas seis días después de la 4.0.1, publicada el 25 de agosto con la primera ronda de trabajo del equipo Omarchy Security -entre ellos los colaboradores identificados como mdisec y acrogenesis, cuya incorporación DHH anunció esa misma semana, según esta sección reportó el 30 de agosto-, lo que confirma que el equipo de seguridad formalizado hace apenas unos días ya produce parches concretos. La secuencia de dos lanzamientos de seguridad en seis días es la respuesta más tangible que el proyecto ha dado hasta ahora a la crítica de calidad de código que Tux Machines planteó el 14 de agosto bajo el término "slopware", aunque ninguna de las dos versiones cita esa crítica de forma directa en sus notas de lanzamiento. Ningún medio especializado había cubierto de forma independiente la versión 4.0.2 al cierre de esta edición; la información proviene únicamente del registro de cambios oficial del proyecto en GitHub.
> Omarchy no confirmó, en las fuentes consultadas, si publicará un reporte de auditoría independiente sobre la falla de inyección de comandos corregida hoy. Costa Rica no tiene desarrolladores de Omarchy identificados en esta cobertura, pero cualquier usuario tico de la distribución que no actualice a la versión 4.0.2 permanece expuesto a esa falla en los instaladores de temas hasta que aplique el parche.
El rastreador de seguridad de Canonical, consultado por esta sección la mañana del 31 de agosto de 2026, mantiene el estado "Vulnerable" para CVE-2026-64564 (SCTPhantom) en las siete versiones LTS de Ubuntu activas, con severidad crítica de 9,8 sobre 10 en la escala CVSS v3.1, según ubuntu.com. La página del CVE no registra cambios desde el 27 de agosto -cuatro días sin actualización-, lo que sitúa a la falla en 27 días sin parche completo en el kernel genérico desde su publicación el 4 de agosto. La National Vulnerability Database, sin embargo, puntúa la misma falla en 8,5 sobre 10 bajo la escala CVSS v4.0 -un punto menos que el 9,8 de Ubuntu bajo CVSS v3.1-, una diferencia que The Hacker News atribuyó a cuánto pesa cada metodología el requisito de acceso local previo y la necesidad de que el módulo del kernel para SCTP esté activo en el objetivo. CIQ, la firma de soporte comercial de Rocky Linux, publicó además una guía de mitigación que acota la exposición práctica a los servidores con ese módulo cargado, según su base de conocimiento -una condición que, en la mayoría de los servidores web o de bases de datos sin necesidad de SCTP, ya está deshabilitada por defecto o puede desactivarse sin afectar el servicio. Canonical no confirmó, al cierre de esta edición, una fecha para completar el traslado del parche -ya presente en las ramas estables 6.6.148, 6.12.101, 6.18.42, 7.1.6 y en la candidata 7.2-rc5, según reportó Cyber Security News- al kernel genérico de las LTS. Costa Rica no tiene cifras propias de servidores locales con el módulo SCTP activo, pero cualquier institución o proveedor de hosting tico que use Ubuntu LTS en producción debe mantener la mitigación de Canonical -deshabilitar el módulo con "install sctp /bin/false"- mientras el parche definitivo no llegue.
El rastreador de seguridad de Canonical, consultado por esta sección la mañana del 31 de agosto de 2026, mantiene el estado "Vulnerable" para CVE-2026-64600 (RefluXFS) en las versiones 18.04, 20.04, 22.04 y 24.04 LTS de Ubuntu, y "vulnerable, trabajo en curso" en la 26.04, según ubuntu.com; las versiones 14.04 y 16.04 no están afectadas. La página del CVE tampoco registra cambios desde el 27 de agosto, lo que sitúa a la falla en 46 días sin corrección desde que el parche llegó al árbol ascendente del kernel el 16 de julio, según reportó The Hacker News. RefluXFS y SCTPhantom son dos vulnerabilidades distintas que esta sección ha cubierto en paralelo desde finales de julio, y conviene no confundirlas pese a que ambas afectan al kernel de las LTS de Ubuntu al mismo tiempo. RefluXFS es una condición de carrera en la ruta de copia sobre escritura de XFS que permite a un usuario local sin privilegios redirigir una escritura hacia un archivo protegido, según la investigación original de Qualys; el error vive en el kernel desde la versión 4.11 de 2017, casi nueve años. Ubuntu la califica con severidad "Alta" (CVSS 7,8) y prioridad "Media", frente a la severidad "Crítica" (CVSS 9,8) y el escape de contenedor confirmado que distingue a SCTPhantom. Qualys estima en más de 16,4 millones los sistemas Red Hat Enterprise Linux, Fedora Server y Amazon Linux potencialmente expuestos a RefluXFS -una cifra que no incluye a Ubuntu, cuyo número de instalaciones expuestas Canonical no ha publicado. Canonical no confirmó, al cierre de esta edición, una fecha para trasladar el parche de RefluXFS -disponible en el árbol ascendente desde julio- a sus versiones LTS. Costa Rica no tiene cifras propias de particiones XFS con reflink activo en producción, pero cualquier proveedor tico de hosting que use XFS sobre Ubuntu LTS sigue expuesto a una escalada de privilegios local mientras el parche no llegue, aunque el vector exige que el atacante ya tenga una cuenta sin privilegios en el sistema.
El proyecto Incus, la bifurcación comunitaria de LXD que mantiene Linux Containers, publicó el 27 de agosto de 2026 la versión 7.4, con soporte de migración casi en vivo -tanto del lado del cliente como del servidor- para instancias con discos dependientes durante operaciones dentro de un mismo clúster, según el registro de cambios publicado en github.com/lxc/incus. La versión suma gestión de claves de arranque seguro, inspección y modificación de NVRAM, y mejoras en el manejo de snapshots sobre los sistemas de archivos ZFS y Btrfs. La versión también oculta las claves de configuración sensibles de las respuestas de la API, según el mismo registro de cambios, sin que el proyecto detalle públicamente si esa corrección responde a un reporte de seguridad externo. Incus se usa como base de infraestructura de contenedores en distribuciones como Debian y openSUSE, lo que vuelve relevante cualquier mejora en el manejo de ZFS y Btrfs para operadores que administran flotas de contenedores sobre esos sistemas de archivos -el mismo Btrfs cuyo rendimiento de entrada/salida directa esta sección reportó el 30 de agosto que alcanzó el 95% del máximo teórico en Linux 7.3. El proyecto no publicó, en las fuentes consultadas, cifras de adopción de Incus 7.4 fuera de su propio repositorio. Costa Rica no tiene cifras propias de operadores locales de Incus identificados en esta cobertura, pero cualquier proveedor tico de hosting o nube que use contenedores sobre ZFS o Btrfs se beneficia de las mejoras de migración y snapshots en cuanto adopte la nueva versión.
— El proyecto de virtualización de contenedores y máquinas Incus publicó el 27 de agosto la versión 7.4 con migración casi en vivo entre nodos, gestión de claves para arranque seguro y dos correcciones de seguridad, según el registro de cambios oficial en GitHub.
Omarchy contestó esta semana a la crítica de calidad de código con dos lanzamientos de seguridad en seis días, mientras el kernel Linux inaugura su ventana de pruebas para 7.3 sin adoptar una política formal sobre el uso de inteligencia artificial en el desarrollo.
Los tres frentes que esta sección viene siguiendo desde el 25 de agosto -los mantenedores del kernel Linux usando IA en su flujo diario de trabajo, la votación de Debian sobre inteligencia artificial en el código y la crítica de Tux Machines a la calidad de Omarchy bajo el término "slopware"- llegan hoy 31 de agosto con Omarchy como el frente más activo: la distribución publicó su segunda versión de seguridad en seis días, con el equipo Omarchy Security corrigiendo hoy una falla de inyección de comandos en sus instaladores de temas, un día después de que Linux 7.3 entrara en su fase de pruebas públicas sin ninguna política equivalente a la que Debian aprobó el 28 de agosto. La combinación de gobernanza formal -equipo núcleo, equipo de seguridad dedicado- y lanzamientos frecuentes de parches es, hasta ahora, la respuesta más concreta que Omarchy ha dado a la crítica de calidad de código, aunque el proyecto sigue sin publicar en sus canales oficiales una respuesta directa al término "slopware" que Tux Machines usó el 14 de agosto. El kernel, mientras tanto, no muestra el mismo movimiento: la primera candidata de Linux 7.3, publicada el 30 de agosto, no incluye ningún cambio de política sobre el uso de asistentes de IA como Gemini en el flujo de trabajo de sus mantenedores, la misma práctica que Debian, dos días antes, pidió a sus colaboradores someter a revisión humana explícita. Esta sección seguirá el rastreador de Canonical hasta que SCTPhantom y RefluXFS reciban parche en el kernel genérico, los canales oficiales de Omarchy en busca de una respuesta directa a la crítica de Tux Machines, y la próxima ventana de fusión del kernel para verificar si surge una política formal sobre IA. Costa Rica no participa directamente en ninguno de los tres procesos, pero cualquier desarrollador tico que instale hoy la versión 4.0.2 de Omarchy o una LTS de Ubuntu sin parchar convive, a su escala, con la misma tensión entre velocidad de desarrollo y control de calidad que atraviesa a todo el ecosistema.
El 31 de agosto cerró con Omarchy publicando su segunda versión de seguridad en seis días, Linux 7.3-rc1 disponible para pruebas desde el día anterior, y SCTPhantom y RefluXFS sumando 27 y 46 días sin parche en Ubuntu.
El lunes 31 de agosto de 2026 confirmó que Omarchy publicó la versión 4.0.2 con una nueva tanda de parches validados por su equipo de seguridad, la segunda en seis días tras la 4.0.1 del 25 de agosto, según el registro de cambios oficial del proyecto en GitHub. En desarrollo del kernel, la primera versión candidata de Linux 7.3 -publicada el 30 de agosto con soporte de arranque para Apple M3 y una revisión de KVM, según LinuxCompatible- sigue su curso hacia el lanzamiento estable de octubre. En seguridad, el rastreador de Canonical confirmó que SCTPhantom llega a 27 días y RefluXFS, una falla distinta con nueve años de antigüedad, a 46 días sin parche completo en el kernel genérico de las LTS de Ubuntu, ambas sin cambios desde el 27 de agosto. El contraste del día quedó entre la velocidad con la que el recién formado equipo Omarchy Security produce parches concretos -dos versiones de seguridad en seis días- y el estancamiento de más de tres semanas que sostiene Canonical en el traslado de parches ya disponibles en el kernel genérico hacia sus propias LTS. Esa misma tensión entre respuesta rápida y control de calidad atraviesa también al kernel, que entra en su ventana de pruebas para 7.3 sin adoptar una política formal sobre el uso de inteligencia artificial en el desarrollo, a diferencia de la regla que Debian aprobó la semana pasada. Esta sección seguirá el rastreador de Canonical hasta que SCTPhantom y RefluXFS reciban parche en el kernel genérico, la versión estable de Linux 7.3 prevista para octubre, y los canales oficiales de Omarchy en busca de una respuesta directa a la crítica de calidad de código que motivó la formación de su equipo de seguridad. Costa Rica no participa directamente en ninguno de estos procesos, pero la banca, los proveedores de hosting y la comunidad tica de software libre que dependen de Ubuntu y de distribuciones basadas en Arch siguen expuestos, en distinta medida, a cada frente que permanece abierto.