GrapheneOS corrige una filtración de VPN en Android que Google dijo que no iba a parchear

• GrapheneOS corrigió en una nueva actualización una vulnerabilidad de evasión de VPN que podía filtrar la dirección IP real incluso cuando estaban activadas “Always-On VPN” y “Block connections without VPN” en Android
• La vulnerabilidad se originaba en la función de cierre de conexiones QUIC de la pila de red de Android 16, y permitía que una app común registrara una carga útil UDP en system_server usando solo permisos estándar
• Cuando el socket UDP de la app era destruido, el system_server con privilegios enviaba directamente la carga útil almacenada por la interfaz de red física en lugar del túnel VPN, evadiendo la protección de bloqueo de la VPN
• Google clasificó el problema como “Won’t Fix (Infeasible)” y “NSBC”, y mantuvo su postura de que no cumple con los criterios para un aviso de seguridad de Android
• GrapheneOS desactivó la “registerQuicConnectionClosePayload optimization” en la release 2026050400, que además incluye el parche de seguridad de Android de mayo de 2026, mejoras a hardened_malloc, actualizaciones del kernel Linux y una corrección retroportada para libpng CVE-2026-33636

---

Cómo funciona la vulnerabilidad

• Según el análisis técnico de Yusuf, la API vulnerable permitía que una app común con solo los permisos otorgados automáticamente INTERNET y ACCESS_NETWORK_STATE registrara una carga útil UDP arbitraria en system_server
• Después, cuando el socket UDP de la app era destruido, el proceso privilegiado system_server de Android enviaba directamente la carga útil almacenada por la interfaz de red física del dispositivo en lugar del túnel VPN
• Como system_server opera con privilegios de red elevados y está exento de las restricciones de enrutamiento de la VPN, ese paquete evade por completo la protección de bloqueo de VPN de Android
• El investigador de seguridad lowlevel/Yusuf demostró la vulnerabilidad en un Pixel 8 con Android 16 usando Proton VPN junto con el modo de bloqueo de Android
• La app en cuestión filtró la IP pública real del dispositivo a un servidor remoto incluso con la protección de VPN totalmente activada

Causa y manejo por parte de Google

• Google introdujo la función para permitir que las aplicaciones cerraran correctamente sesiones QUIC cuando un socket se destruye de manera inesperada
• La implementación aceptaba cargas útiles arbitrarias sin verificar si realmente eran tramas válidas de QUIC CONNECTION_CLOSE
• La implementación tampoco comprobaba originalmente si la aplicación estaba restringida a tráfico exclusivo por VPN
• El investigador reportó el problema al equipo de seguridad de Android, pero Google lo clasificó como “Won’t Fix (Infeasible)” y “NSBC” (Not Security Bulletin Class)
• Google determinó que el problema no cumplía los criterios para ser incluido en los avisos de seguridad de Android
• El investigador pidió una revisión argumentando que cualquier app podía filtrar información de red identificable usando solo permisos estándar, pero Google mantuvo su postura y aprobó la divulgación el 29 de abril

Actualización y mitigaciones de GrapheneOS

• GrapheneOS es un sistema operativo basado en Android, centrado en privacidad y seguridad, desarrollado principalmente para dispositivos Google Pixel, y lo usan quienes buscan un sandboxing de aplicaciones más fuerte, mitigaciones de exploits y menor dependencia de los servicios de Google
• GrapheneOS desactivó por completo esa optimización en la release 2026050400 para evitar la filtración de VPN
• Yusuf señaló que GrapheneOS completó y distribuyó la corrección en menos de una semana
• La versión más reciente también incluye, además de la corrección de la filtración de VPN, todo el nivel de parches de seguridad de Android de mayo de 2026
• La actualización incluye varias mejoras a hardened_malloc, actualizaciones del kernel Linux en las ramas 6.1, 6.6 y 6.12 de Android, y una corrección retroportada para CVE-2026-33636 de libpng
• También se incluyen una nueva compilación del navegador Vanadium y restricciones ampliadas para Dynamic Code Loading
• Los usuarios de Android estándar pueden mitigar temporalmente el problema desactivando la bandera DeviceConfig close_quic_connection mediante ADB
• Esta medida requiere acceso de desarrollador
• Si Google elimina esa bandera de función en futuras actualizaciones, esta mitigación podría dejar de estar disponible

[GN⁺]

Comentarios de Hacker News

• Si system_server funciona con altos privilegios de red y queda excluido de las restricciones de enrutamiento de la VPN, entonces en Android una VPN en realidad no es una VPN
  Más allá de este bug, me da curiosidad si otros sistemas operativos cerrados también funcionan así

  • iOS también es igual, y tengo entendido que para evitarlo se necesita una licencia empresarial para más de 250 dispositivos
    Mullvad y otros ya habían tratado este problema hace tiempo
  • Términos como “private” o “trust” significan cosas distintas en el mundo de las computadoras y en las costumbres humanas
    Me preocupa que la gente vea palabras con la misma ortografía y no note la diferencia de contexto, extendiendo por error la confianza humana al modelo de confianza de las computadoras
  • En macOS también hubo casos en que sus propias apps podían saltarse una VPN siempre activa
    No sé bien si había una vulnerabilidad o hueco que permitiera enviar tráfico directamente a destinos arbitrarios
  • Me pregunto qué tan difícil es corregir system_server y otras rutas de bypass

• Igual que con Manifest V3, impedir el espionaje no va con los intereses de Google
  Ese tipo de limitaciones perjudica su modelo de negocio

• La razón técnica por la que esto es grave es que la fuga ocurre desde system_server, un proceso privilegiado
  El modo de bloqueo propio de Android promete explícitamente que ningún tráfico evitará la VPN. Si el propio sistema envía paquetes por la interfaz física, entonces esa promesa se rompe a nivel de kernel, no en espacio de usuario, así que es difícil decir que “no amerita un aviso de seguridad”

• Si Google autorizó la divulgación el 29 de abril, sorprende que aun así respetaran el embargo y retrasaran la distribución de la corrección hasta mayo
  No sé por qué no lo publicaron de inmediato

  • Probablemente para no dañar la relación con Google como proveedor
    Nos guste o no, GrapheneOS depende de Android controlado por Google

• Entiendo que hay malas razones de negocio, pero no sé cómo pueden conservar la dignidad clasificando una fuga de VPN como algo que no es un problema de seguridad

  • Depende de cómo veas el papel de una VPN
    Originalmente, una VPN servía para acceder a una red privada o corporativa a través de otra red, como conectar oficinas entre sí o entrar desde casa a la oficina. Solo después pasó a verse como una especie de herramienta de seguridad
    Si ves el código de VPN como algo tipo “basta con que el teléfono pueda acceder a la impresora de la oficina por 5G”, entonces un pequeño bug donde una conexión QUIC no se cierra bien puede parecer menor. En cambio, si piensas “este túnel de WireGuard debe proteger mi identidad pase lo que pase” o “debe ser una copia exacta de todo el tráfico que entró y salió de internet”, entonces sí es un problema grande
    Yo diría que ni la VPN de Android ni prácticamente ninguna VPN fue diseñada como mecanismo de privacidad o seguridad. Menos aún frente a apps que pueden ejecutar código en el dispositivo, y el propio equipo también hace muchas interacciones de red, incluso dentro del chip del módem
    Que Google cerrara el bug fue un error, pero entiendo por qué no lo consideran un bug de seguridad en su programa de recompensas
  • Esa pregunta solo es posible si asumes que hay dignidad que preservar
  • Desde la perspectiva de Google, no es un bug sino una función
    Google es una empresa de publicidad y también un contratista ofensivo, así que que los usuarios de VPN filtren paquetes le beneficia por ambas razones
  • Les pagan para hacer eso
  • No creo que se pueda trabajar en Google si consideras que la divulgación no deseada de datos personales es un problema de seguridad

• También se parece a cuando Meta elimina el cifrado de extremo a extremo
  Es más bien un “no, queremos ver todo lo que dices y haces”

• Me pregunto cuál es una buena forma de conseguir un teléfono para GrapheneOS
  Quería probar GrapheneOS, pero me cuesta decidirme a comprar un Pixel. Incluso usados, hasta la serie “a” normalmente supera los 300 dólares y hay que irse varias generaciones atrás. Además está el tema de si se puede desbloquear el bootloader. Todavía me cuesta gastar 449 dólares en un Pixel 10a nuevo

  • Quizá no ayude por ahora, pero GrapheneOS anunció recientemente una alianza con Motorola, así que en uno o dos años podrían empezar a soportar algunos dispositivos Motorola
    Como referencia, cuando salió Google Fi compré el Pixel 10a por unos 300 dólares
  • Mejor no compres el Pixel 10a
    El Pixel 9a es casi el mismo dispositivo y todavía se vende nuevo
  • Recomiendo la serie Pixel 8 o superior
    Lo más seguro es comprarlo nuevo en una tienda normal o en Google Store, no en una tienda de operador
    Los usados son casi una apuesta por el tema del desbloqueo OEM, así que conviene revisar la política de devoluciones y verificar antes de comprar que el desbloqueo OEM esté accesible
  • Ya respondí en otro hilo: https://news.ycombinator.com/item?id=48076522
    Básicamente, compra un Pixel 6 o posterior en el que esté garantizado que se puede desbloquear el bootloader. Eso sí, al Pixel 6 pronto le quedará solo soporte mínimo, así que recomiendo Pixel 7 o posterior. La mayoría de las unidades usadas no permiten desbloquear el bootloader
    O sea, lo mejor es comprar directo a Google, o comprar en eBay uno que ya tenga instalado GrapheneOS/CalyxOS/LineageOS, o uno donde el vendedor indique explícitamente que el bootloader sí se puede desbloquear
    En mi experiencia, si el vendedor no lo menciona de entrada, pedirle que lo revise no sirve de mucho. Casi nadie quiere pasar por el proceso de verificación, la respuesta suele ser “no se puede”, pueden malinterpretar la pregunta y responder solo “es desbloqueado”, o quizá ya estén cansados de ese tipo de preguntas
  • También puedes esperar un poco
    Se está trabajando en soportar más hardware de teléfonos, y durante un tiempo hubo especulación sobre de qué marca sería

• Intenté probar GrapheneOS comprando barato un Pixel 6 usado, pero no me gustó mucho
  Siento que la experiencia de usuario de LineageOS es bastante mejor. La estructura del gestor de paquetes se siente rara, como una muñeca rusa. La “App Store” predeterminada solo trae algunos programas básicos, y uno de ellos es Accrescent, que a su vez es otro gestor de paquetes, pero aún tiene muy pocas apps, así que al final necesitas otro más. Del lado de GrapheneOS parecen preferir Obtainium sobre F-Droid, y eso también me parece una decisión extraña
  Prefiero mucho más un gestor de paquetes completamente de código abierto, y hay valor real en construir desde el código fuente externamente y, si es posible, de forma reproducible, en lugar de confiar en paquetes de GitHub. El modelo de seguridad de GrapheneOS se ve extrañamente centralizado. Los beneficios reportados en privacidad y seguridad me resultan difíciles de evaluar por cuenta propia

  • Puedes simplemente descargar F-Droid por tu cuenta
    No entiendo por qué hay tanta insistencia en que deba existir una tienda de apps predeterminada, fija y preinstalada
    Operar una tienda de apps da tanto trabajo como mantener un fork de Android, y cuando ya existen opciones como F-Droid, Play Store con Aurora Store, Obtainium y otras, es difícil culpar a los desarrolladores de GrapheneOS por no invertir un esfuerzo enorme en eso
  • La App Store es más bien un punto de partida mínimo para decidir de dónde obtener apps
    En el estado predeterminado solo tienes el launcher y el sistema operativo mínimo, y para un minimalista eso es todo lo necesario
    Si necesitas más, tú decides a dónde ir. Yo a eso le llamo darle poder al usuario; tú pareces llamarle incomodidad. Si es así, tal vez ese sistema operativo no sea para ti
  • Que un software sea libre o de código abierto no significa que por naturaleza sea más seguro o más privado
    “Open source” es, en esencia, un término de licencia
    La “App Store” de GrapheneOS existe para ofrecer las apps más básicas necesarias para un uso general. Accrescent se distribuye ahí porque, como tienda real de apps, sí sigue la línea base de seguridad de Android, mientras que F-Droid y Aurora Store no
    No creo que tenga mucho valor que un tercero compile apps, como hace F-Droid, para comprobar si hay comportamiento malicioso. Esas revisiones no son muy confiables y ya se han eludido antes. Esa es una de las razones por las que WireGuard ya no está en F-Droid. Si no confías en una app lo suficiente como para obtenerla directamente de su desarrollador, probablemente no deberías usarla
    Las ventajas de privacidad y seguridad de GrapheneOS están diseñadas para ser casi invisibles para el usuario promedio. Por ejemplo, tiene un asignador de memoria endurecido y extensiones de etiquetado de memoria para prevenir fallos por corrupción de memoria, además de la posibilidad de instalar Google Play en sandbox para usar servicios de Google sin que Google controle todo el dispositivo
  • GrapheneOS heredó la interfaz de usuario de Android Open Source Project, y también se basan en ella el sistema predeterminado de los Pixel y muchos forks de Android de otros fabricantes
    La App Store de GrapheneOS existe para cumplir el papel de tienda principal de apps que AOSP requiere. También sirve para actualizar apps principales por separado del sistema operativo y, en algunos casos, para reflejar apps
    Accrescent se refleja porque está centrado en privacidad y seguridad. Actualmente sigue en alfa y el envío de apps está cerrado, pero pronto se abrirá
    Google Play se refleja para compatibilidad con apps que lo requieren y para acceso a Play Store
    La comunidad de GrapheneOS prefiere Obtainium porque permite obtener apps firmadas por el desarrollador desde sitios como GitHub. F-Droid firma y compila casi todas las apps de su repositorio principal con una infraestructura de compilación antigua y una coordinación deficiente
    El modelo de seguridad de GrapheneOS hereda el modelo de seguridad de AOSP y lo endurece aún más
  • Qué gusto que CalyxOS se esté activando de nuevo
    GrapheneOS tiene muchas implementaciones técnicas impresionantes, pero Calyx parece resolver varias cosas de una forma más simple y más cercana a Android puro

• Para “corregir la fuga de VPN”, GrapheneOS desactivó la optimización registerQuicConnectionClosePayload y dijo que con eso prácticamente anuló el vector de ataque en los Pixel compatibles
  O sea, GrapheneOS “corrigió” la fuga desactivando la optimización
  Antes en HN solían elogiar QUIC, y bajivoteaban a quien preguntaba a quién beneficiaba más QUIC. Puede que usar QUIC convenga a otros, pero para mí el intercambio no vale la pena, así que bloqueo el tráfico QUIC
  QUIC a veces viene activado por defecto en software distribuido por Google, como Android, y en algunos casos ni siquiera se puede desactivar

  • En GrapheneOS, QUIC como tal sigue funcionando perfectamente
    Lo que GrapheneOS quitó fue solo la forma en que una app puede pedirle al sistema operativo que cierre automáticamente una conexión QUIC en situaciones como cuando la app muere. Desde la perspectiva del servidor, es una optimización porque evita que la conexión quede abierta ocupando recursos hasta que expire por inactividad y pase por el procedimiento de cierre, pero no es una optimización del lado del cliente
    Además de esto, GrapheneOS corrigió unas 5 fugas de VPN más y sigue trabajando en otras. La implementación actual de VPN en Android es por perfil, pero ese perfil todavía no usa su propio namespace de red, y el resolvedor DNS junto con varios servicios centrales tienen que manejar correctamente el soporte de VPN, por lo que sigue siendo propensa a fugas
    Más adelante planean mejorar la arquitectura de VPN para hacerla mucho más resistente a fugas. También vendrá soporte para ejecutar apps o grupos de apps en máquinas virtuales, lo que podría ofrecer una protección más fuerte
  • Lo que quedó expuesto fue una ruta para cerrar conexiones QUIC de forma elegante mediante una llamada inadecuada o explotable; no que GrapheneOS haya desactivado QUIC por completo
    QUIC en sí es excelente; esto se parece más a una función del Android de Google, un sistema operativo de vigilancia, que a una función del protocolo
    Además, al revisarlo en un sistema anterior a la versión más reciente, ni siquiera funcionaba correctamente

• Android puro es spyware y adware
  Antes a un software así se le llamaba malicioso y se eliminaba, pero ahora se volvió el valor predeterminado

  • Todos están de acuerdo, pero no sé cuál sea la solución
    Como el 99% de los usuarios no se preocupa por esto, el único punto de presión real serían los fabricantes de teléfonos. Se siente impotencia al no tener ninguna capacidad de influir en alguien con peso real en este ámbito