El incidente de Telegram Desktop es un ejemplo clásico de cómo la interacción de múltiples vulnerabilidades aparentemente menores puede llevar a un impacto crítico, en este caso, la toma de control de la cuenta. La causa raíz es una combinación de una deserialización insegura en el mecanismo de comunicación entre procesos (IPC) y una función privilegiada (el esquema URI interpret:) que carecía de controles de autorización adecuados.
La inyección IPC se produjo porque el separador de comandos (punto y coma) no se escapaba en la serialización de URLs para la comunicación entre instancias de la aplicación. Esto permitía a un atacante inyectar comandos arbitrarios en el flujo de IPC. El segundo defecto crítico fue la existencia del esquema URI interpret:, diseñado originalmente para automatizar la publicación de lanzamientos, que podía leer archivos arbitrarios del disco y enviarlos a un chat sin confirmación ni verificación de autorización. Este esquema, aunque no accesible directamente por el sistema operativo, se volvió alcanzable a través de la inyección IPC.
Las salvaguardas fallaron en varios puntos. Primero, la falta de un escape robusto en la serialización de datos para IPC es un error fundamental de seguridad. Segundo, la función InterpretSendPath que manejaba el esquema interpret: no implementó ninguna verificación de autorización, asumiendo que solo sería invocada por procesos de confianza o scripts internos. Esto es un fallo en el principio de "least privilege" y "defense in depth". La combinación de la capacidad de inyectar comandos y la existencia de una función de lectura de archivos sin autorización permitió la exfiltración de archivos sensibles, incluyendo los datos de sesión, lo que llevó a la toma de control de la cuenta.