El 28 de octubre, en la conferencia OffensiveCon de Tokio, el investigador Saifeldeen Aziz presentó una ponencia sobre vulnerabilidades zero-click en los stickers animados de Telegram. Estas vulnerabilidades no requieren ninguna interacción del usuario: basta con que el cliente renderice el sticker recibido. Según el resumen, se encontraron varios errores de corrupción de memoria en la biblioteca rlottie, utilizada por los clientes de Telegram para dibujar estos stickers. Además, la verificación de stickers por parte del servidor pudo ser eludida mediante errores lógicos en su entrega. Para Telegram en iOS, la cadena, según el autor, conduce a la ejecución de código. Esto afecta principalmente a los usuarios de iPhone y iPad, ya que en Android y en la versión de escritorio, los stickers ya son renderizados por un nuevo motor de Telegram, mientras que en iOS, rlottie sigue en uso.

Qué se sabe sobre la ponencia

La ponencia se titula «Stickers r-lot-tie Handle: Vulns, Bypasses, and Telegram's Zero-Click Attack Surface» y figuraba en el programa del segundo día de la conferencia, el 28 de octubre a las 10:30 AM hora de Tokio. Los organizadores publicaron una imagen del escenario a la 01:32 UTC, durante la presentación. Todavía no hay grabaciones, diapositivas, análisis públicos ni números CVE para los hallazgos de Aziz, por lo que todo lo que se sabe sobre el contenido proviene del resumen.

Según el resumen, la investigación duró aproximadamente un año y consta de tres pasos:

  • Fuzzing de rlottie. El fuzzing es la alimentación automática de millones de archivos malformados a un programa en busca de fallos; en este caso, fue dirigido por un modelo de lenguaje. Se encontraron varios errores de corrupción de memoria que, según el resumen, afectan a los clientes de Telegram en iOS, Android y escritorio.
  • Elusión de la verificación del servidor. El servidor de Telegram verifica los stickers y no permite el paso de archivos sospechosos; en esto se basaba el modelo de amenazas. El resumen describe errores lógicos específicos en la forma en que se entregan y verifican los stickers, así como varias elusiones de las protecciones en el servidor y en el cliente.
  • Cadena contra iOS. Todo esto se ha combinado en un exploit que ejecuta código en Telegram para iOS; el autor analiza por separado las limitaciones del exploit.

El resumen no incluye los pasos de reproducción, y esta artículo tampoco los contiene.

Por qué un sticker es peligroso sin hacer clic

Un sticker animado es un archivo TGS: un JSON comprimido con gzip en formato Lottie, donde la animación se describe mediante contornos vectoriales. El cliente lo rasteriza con una biblioteca nativa tan pronto como el sticker entra en el área visible: en el chat, en la vista previa del diálogo, en las reacciones o en los emojis de estado personalizados. Por lo tanto, un error en el renderer es una superficie de ataque sin interacción del usuario, y el único filtro entre el remitente y el código vulnerable es el servidor de Telegram.

De aquí surge la pregunta con la que concluye el resumen: si la seguridad del cliente depende de que el proveedor decida qué archivo llega al código vulnerable, ¿es esto una medida de protección, un riesgo arquitectónico o algo más cercano a una puerta trasera (backdoor)?

El caso ZDI

La ponencia continúa una disputa que comenzó en primavera. El 26 de marzo, Zero Day Initiative informó a Telegram sobre un error en rlottie que permitía escribir datos antes del inicio de un búfer asignado y ejecutar código. El 31 de marzo, Telegram respondió que la vulnerabilidad estaba cerrada mediante una verificación en el servidor, y el 14 de abril solicitó la cadena completa hasta la ejecución de código. El 15 de octubre, ZDI publicó el boletín ZDI-26-757 como una vulnerabilidad sin parche, con una calificación CVSS de 7.0; en primavera, cuando se informó por primera vez del caso, se mencionaba una calificación de 9.8 (SecurityAffairs, CyberInsider). La ponencia de Aziz se presenta como una refutación del argumento de Telegram: el código que se consideraba inalcanzable resultó serlo.

El propio rlottie de Telegram no es un objetivo nuevo. En 2020, Shielder encontró 13 errores en él, incluido CVE-2021-31322; estos se corrigieron en las versiones 7.1 en otoño de 2020, y el análisis se publicó en febrero de 2021. En septiembre de 2026, circuló por los chats un sticker que cerraba la aplicación en todos los clientes, excepto en la versión web.

Qué cambios hace Telegram en el código

Telegram está escribiendo su propio renderer de Lottie en Rust: tlottie. En su descripción se afirma directamente que el JSON de la animación se considera una entrada no confiable, y se compara con un fork de rlottie de 2019, que utilizan los clientes.

En el código fuente de Telegram para Android 13.1.1 ya no hay rlottie nativo, sino que se encuentra el tlottie compilado; Android cambió a él en la versión 12.10.0, y la versión de escritorio en septiembre.

En Telegram para iOS, tlottie se añadió el 11 de septiembre, como un segundo motor junto a rlottie, no en su lugar. Los stickers, emojis, reacciones y el teclado de stickers eligen el motor en cada renderizado, y el servidor puede devolverlos a rlottie con el flag ios_killswitch_disable_tlottie. Además, en 50 lugares —interfaz secundaria, pantallas previas al inicio de sesión, ventana "Compartir", exportación desde el editor de medios— siempre se renderiza con rlottie. No se puede determinar por el código si estas modificaciones están relacionadas con los hallazgos de Aziz; el resumen indica que el código de renderizado vulnerable permanece en los clientes oficiales.