Zero click, silencioso, remoto DoS en Android

Artículo original ↗ Discusión en Hacker News ↗

Una vulnerabilidad de Android recientemente divulgada permite que un único SMS WAP Push malformado bloquee repetidamente el proceso del teléfono del sistema, cortando las llamadas activas (incluidas las llamadas de emergencia) sin interacción del usuario y pudiendo dejar los dispositivos incapaces de realizar llamadas hasta que la SIM se mueva a otro terminal. Los comentaristas debaten cuán grave es en la práctica este riesgo de denegación de servicio, con qué facilidad pueden enviarse esos mensajes a través de redes reales y si las operadoras o las estaciones base falsas podrían convertirlo en un arma a gran escala. Gran parte de la conversación también critica el escrito “hypey” generado por IA y la clasificación inicial de Google como “won’t fix”, señalando que Google ya ha asignado un CVE y ha distribuido un parche (ya incorporado por GrapheneOS) tras lo que parece haber sido una mala comunicación interna.

Vulnerabilidad e impacto

  • Los datos SMS WAP Push malformados (p. ej., al puerto 2948) pueden provocar que com.android.phone de Android se bloquee, cortando las llamadas, incluidas las llamadas de emergencia, sin interacción del usuario ni mensaje visible.
  • La entrega repetida puede corromper una base de datos SQLite interna de SMS/telefonía, haciendo que el proceso del teléfono se bloquee en cada arranque. El dispositivo pierde de hecho la capacidad de telefonía mientras que el Wi‑Fi sigue funcionando.
  • La recuperación descrita es: mover el perfil SIM/eSIM a un dispositivo que no sea Android (para que los mensajes pendientes sean confirmados con ACK), y luego limpiar la base de datos corrupta (por ejemplo, eliminar telephony.db) o hacer un restablecimiento de fábrica. Para eSIM esto es mucho más difícil.
  • Algunos cuestionan si SQLite debería corromperse por un bloqueo a mitad de escritura; otros afirman haber observado corrupción de la base de datos en la práctica.

Explotabilidad y papel de las operadoras

  • Se proporciona una APK de PoC para enviar el SMS malformado desde un dispositivo a cualquier número de teléfono objetivo; no se necesita comprometer localmente a la víctima.
  • Varios comentaristas con experiencia dicen que los tipos de SMS no visibles para el usuario (WAP Push, SMS silenciosos, configuración APN, indicadores de buzón de voz) son reales y a menudo no se filtran.
  • Otros se muestran escépticos: no está claro si mensajes WAP Push malformados arbitrarios pueden atravesar todas las redes de las operadoras, o si algunas redes ya los filtran o descartan.
  • Se discutieron escenarios como acoso personal (por ejemplo, contra una expareja), interrupción o supresión dirigida, o ataques combinados con IMSI catchers / torres falsificadas.

Severidad, respuesta de Google y parcheado

  • Hay debate sobre la severidad: algunos lo ven como un “DoS temporal” y algo menor; otros subrayan que deshabilitar remotamente las llamadas de emergencia es un problema de seguridad grave.
  • Google clasificó inicialmente el informe como “won’t fix” / “no es un problema de seguridad”, probablemente a través de un triager de primera línea. Esto generó críticas y se enmarcó como parte de una degradación más amplia de la calidad y de la sobrecarga del VRP.
  • Comentarios posteriores señalan que Google en realidad se comprometió a corregirlo en junio, lo distribuyó mediante parches de vista previa de seguridad en julio, y aparecerá en el Boletín de seguridad de Android de noviembre de 2026 como CVE-2026-58882 (Crítico). El cierre anterior se atribuye a una mala comunicación interna / gestión como duplicado.
  • Una bifurcación endurecida de Android informa haber enviado el parche meses antes y confirma que sus propios usuarios no se ven afectados.

Escrito generado por IA y debate sobre “slop”

  • Muchos comentarios se centran en el tono generado por IA de la página de aterrizaje: “hypeslop”, lenguaje de marketing excesivamente dramático y una fraseología característica.
  • Algunos sostienen que el pulido con IA oculta la claridad técnica y perjudica la credibilidad; otros defienden usar LLMs para el diseño/copy, dado que el error y la PoC son reales.
  • Debate metadiscursivo sobre que HN vote alto sitios de vulnerabilidades generados por IA pese a las quejas generalizadas sobre el “AI slop”.