Project Zero de Google demostró un nuevo exploit zero-click contra los teléfonos Pixel 10, mostrando un escalamiento completo desde remoto hasta kernel sin interacción del usuario. Durante la investigación, Project Zero encontró acceso a memoria no protegido desde userspace en el driver del chip de procesamiento de video Tensor G5, que permite escritura directa a memoria de kernel.
Usando fallas descubiertas previamente en componentes de decodificación de medios (en este caso CVE-2025-54957 en el decodificador de audio Dolby), Project Zero adaptó un ataque del Pixel 9 para que funcionara contra el Pixel 10, a pesar de las nuevas protecciones de hardware diseñadas para mitigar corrupciones de memoria.
La lectura del autor es mixta. Una vez reportado el bug en el Pixel 9, era esperable que el equipo de Android revisara fallas similares en sus sistemas más nuevos. En el lado positivo, Project Zero reportó las vulnerabilidades al equipo de Android en noviembre de 2025 y fueron parchadas en febrero de 2026, 71 días después. Eso son 19 días bajo el límite de 90 días del disclosure timeline.
¿Qué opina Linus Torvalds sobre los reportes con IA?
Linus Torvalds aclaró posiciones sobre vulnerabilidades de seguridad detectadas por IA en el kernel de Linux en un mensaje reciente a la lista de correo sobre el ciclo de desarrollo del kernel Linux 7.1.
En su estilo seco habitual, Torvalds apoya el uso de herramientas de IA en general, pero considera que cualquier bug reportado por IA es, por definición, público. Linus también pide que quienes envíen reportes generados por IA verifiquen que el reporte es preciso y se involucren en arreglar el problema, en vez de hacer un drive-by report sin verificar.
GitHub sube el listón para los bug bounties
De forma similar a Linus, GitHub detalló cómo manejará los reportes generados por IA en un intento por elevar la calidad de los reportes que recibe su programa de bug bounty.
Es algo irónico que una plataforma que se metió a fondo en la IA enfrente problemas de escala con reportes generados por IA en su propio programa de seguridad, pero el problema es real. GitHub lista lo que parece un set razonable de requisitos para un buen reporte: aportar un ejemplo funcional de la vulnerabilidad en acción, adherirse al alcance del bounty y, por supuesto, que el reporte sea válido.
Las tres exigencias apuntan directo a cosas en las que la IA ha sido históricamente mala, sobre todo a escala cuando la usan personas con poca experiencia en seguridad. Los modelos suelen fabricar código, fixes y datos. Los reportes completamente falsos terminan haciendo perder tiempo.
GitHub también aclara que los repositorios maliciosos no están dentro del alcance del programa, indicando que los usuarios son responsables de qué repositorios clonan o forkean. Tiene sentido para un programa donde alguien podría crear un repo arbitrariamente malicioso y reportarlo como bug, pero queda corto frente a la explotación reciente del proceso de build de GitHub Actions. Esperar que cada usuario entienda las implicancias del workflow de Actions antes de forkear un repo público parece poco realista a largo plazo.
Breach de repositorios internos de GitHub
GitHub publicó en su blog de seguridad un compromiso de repositorios internos.
No hay muchos detalles, pero GitHub indica que una extensión comprometida de VSCode en el equipo de un desarrollador fue usada para obtener credenciales de sistemas internos. Si suena familiar, es porque varios de los gusanos actuales que apuntan a NPM y PyPi incluyen código para infectar extensiones de VSCode también.
GitHub dice que solo se vieron afectados repositorios internos de la compañía, y que si se detectan repositorios de clientes comprometidos los usuarios serán notificados. Si te parece divertido que un desarrollador de GitHub, propiedad de Microsoft, haya sido comprometido por una extensión de Microsoft (VSCode), alojada en el repositorio de extensiones de Microsoft, diría que tienes razón.
El kernel saca el zero-copy de AF_ALG
El kernel Linux está removiendo el código zero-copy de AF_ALG. AF_ALG forma parte de las librerías de cifrado a nivel de kernel y ha sido usado en los exploits CopyFail.
El parche señala que la funcionalidad zero-copy fue concebida originalmente para acelerar aceleradores de cifrado por hardware, pero rara vez se usa con ese fin y casi no tiene dependencias en userspace. Al eliminar la API zero-copy, poco usada pero muy compleja, los desarrolladores del kernel esperan cerrar futuras vulnerabilidades de la clase CopyFail que manipulan el cache de tablas de página.
CISA se "self-doxea"
Una contratista de la agencia federal estadounidense de ciberseguridad CISA dejó un repo público en GitHub, irónicamente bautizado "Private-CISA", con credenciales de servicios cloud de CISA, tokens de autenticación, contraseñas en texto plano y credenciales internas.
Brian Krebs reporta los detalles completos. Las credenciales incluían acceso a los sistemas AWS GovCloud de CISA, el sistema de build interno para herramientas, y logins en texto plano al repositorio de librerías internas. GitHub tiene protecciones para evitar la publicación accidental de tokens, pero estaban explícitamente desactivadas.
El repositorio había estado activo desde noviembre de 2025, y aún después de bajarlo las credenciales filtradas permanecieron activas en AWS GovCloud durante 48 horas adicionales.
NGINX 0-Day
El servidor NGINX corre en millones de sistemas, aproximadamente entre el 30% y el 40% de los servidores web, tanto como web server tradicional como proxy de servicios internos.
El mes pasado, la vulnerabilidad "nginx-rift" permitió ejecución arbitraria de código vía el motor de rewrite de NGINX. Ahora, la vulnerabilidad "nginx-poolslip" fue encontrada, causando denegación de servicio y en algunos casos ejecución remota de código incluso en las versiones más recientes de NGINX.
Por ahora no hay parches oficiales, aunque es probable que lleguen pronto. La sugerencia principal de mitigación es asegurarse de que ninguna regla rewrite, if o set en la configuración de NGINX use grupos de captura PCRE sin nombre.
Pid-fd: el bug Linux ya es oficial
El bug "pid-fd" mencionado la semana pasada ya tiene parche oficial y CVE.
No hay que confundirlo con los bugs CopyFail o DirtyFrag, que permiten acceso root corrompiendo el cache de páginas de datos de archivos en RAM. Este bug, también llamado "ssh-keysign-pwn", permite leer cualquier archivo sin importar los permisos, exponiendo archivos críticos como /etc/shadow o las llaves SSH privadas del servidor y los usuarios, y ejecutar comandos como root vía utilidades comunes como ssh-keysign, pkexec y accounts-daemon.
RDS-Pintheft, otro bug del kernel
Sin recibir demasiada atención, el grupo V12 publicó código de prueba de concepto para otro bug del kernel Linux, bautizado "RDS-pintheft".
El bug está en el código de red RDS de Linux, un método alternativo de comunicaciones para clusters de alta velocidad. Funciona de manera similar a CopyFail y DirtyFrag: el mal manejo de buffers de memoria permite sobreescribir el cache de páginas y reemplazar el contenido percibido de un binario suid-root, otorgando root instantáneo.
El exploit requiere que los módulos RDS y RDS TCP estén cargados, lo que no ocurre en todas las distros. Si el módulo está cargado, o el atacante puede forzar su carga automática, y tiene capacidad de ejecutar código localmente, parece game over. Los parches están disponibles y serán integrados pronto en los kernels de las distribuciones.
Google expone detalles de un bug de Chromium
Bleeping Computer reporta que Google expuso por error los detalles de un exploit no parchado en Chromium que habilita botnets basados en JavaScript en todos los navegadores Chromium. Chromium es el motor open source que está debajo de Google Chrome, pero también de Microsoft Edge, Vivaldi, Opera, Arc y Brave.
El bug permite que los service workers sigan corriendo en background incluso cuando la página original se cerró, o incluso cuando se cerró el navegador. Eso habilita que sitios maliciosos, o avisos publicitarios con JavaScript inyectado en sitios legítimos, sigan emitiendo requests sin que el usuario lo sepa, alimentando una botnet para fraude de clics o ataques de denegación de servicio.
El bug fue reportado originalmente en 2022 pero ignorado hasta 2024, cuando se marcó como requiriendo atención. En febrero de 2026 quedó marcado como arreglado, aunque no se habían enviado parches. El 20 de mayo, los detalles del bug se liberaron automáticamente porque había estado cerrado por más de 14 semanas marcado como fixed.
Pero en los hechos el bug no estaba arreglado, y el investigador notó que las alertas previas que podían haber dado una pista al usuario de que algo estaba ocurriendo ya no existen, lo que vuelve el ataque aún más sigiloso. Es probable que lleguen parches adicionales pronto, dada la publicidad y la severidad del problema.
