Cadena de vulnerabilidades en Telerik UI permite ejecución remota de código sin autenticación

La firma de seguridad TantoSec ha publicado una cadena de exploits funcional contra vulnerabilidades en Telerik UI para ASP.NET AJAX que permite a un atacante no autenticado ejecutar código remoto en el servidor que aloja una aplicación vulnerable. Progress Software parchó las fallas en julio; la explotación requiere una configuración no predeterminada, pero la divulgación incluye un análisis detallado y una herramienta lista para usar, lo que pone un vector de ataque completo en manos del público por primera vez.

Detalles de la vulnerabilidad

Los fallos subyacentes no son nuevos. Progress lanzó el parche en la versión 2026.2.708 (2026 Q2 SP1) el 8 de julio y publicó los CVE y el aviso el 22 de julio. Lo que cambió el 7 de septiembre es la divulgación del método y las herramientas: Marcio Almeida de TantoSec explicó toda la cadena y publicó una herramienta de línea de comandos, telerik-rau-exploit, junto con dos payloads DLL de modo mixto: uno que escribe un web shell en disco y otro que se ejecuta completamente en memoria.

La cadena afecta al control de carga de archivos RadAsyncUpload en las versiones 2010.1.309 hasta 2026.2.519, según el aviso de Progress; las versiones 2026.2.708 y posteriores están corregidas. El bug más grave, una falla de resolución de tipos sin restricciones rastreada como CVE-2026-13181, tiene una puntuación CVSS de 8.1 (alta); su calificación de 'alta complejidad de ataque' refleja los requisitos de configuración descritos a continuación, más que la dificultad de explotación una vez cumplidos.

Precondiciones y explotación

No basta con ejecutar una versión vulnerable. TantoSec dice que la cadena tiene 'precondiciones que no se cumplen en una instalación predeterminada': una página debe mostrar un control RadAsyncUpload cuyo manejador del lado del servidor lea el resultado de la carga, y la aplicación debe configurarse con una clave de cifrado explícita y no predeterminada para el control, lo cual es una configuración que Telerik recomienda como endurecimiento. Los sitios con una versión afectada sin ambas condiciones no son explotables mediante esta cadena.

Cuando se cumplen esas condiciones, el beneficio es la ejecución de código con los privilegios del grupo de aplicaciones de IIS. El punto de entrada es un oráculo de padding (CVE-2026-13182): como el control cifra su estado del lado del cliente con AES-CBC y sin verificación de integridad, el servidor responde de manera diferente a datos manipulados dependiendo de si los bytes descifrados tienen padding válido o simplemente fallan al analizarse como JSON.

Esa diferencia permite a un atacante descifrar y, con una técnica que TantoSec construyó alrededor de la semilla de cifrado fija del control, falsificar la configuración de carga cifrada sin conocer la clave. La misma falsificación permite al atacante nombrar un tipo .NET arbitrario, que el control resuelve sin una lista blanca (CVE-2026-13181) y deserializa en un gadget que carga una DLL desde una ubicación que el atacante controla.

La DLL cargada es un ensamblado de modo mixto que ejecuta código nativo tan pronto como se carga. No es instantáneo: la ejecución de extremo a extremo de TantoSec tomó aproximadamente 127,000 solicitudes de oráculo, alrededor de una hora contra un objetivo de laboratorio, y más tiempo contra un servidor con límite de velocidad. Si la aplicación oculta mensajes de error detallados, el oráculo aún puede leerse a través de la sincronización de las respuestas, una variante rastreada como CVE-2026-13183.

Estado de explotación y antecedentes

No hay informes confirmados de explotación de estos fallos en la naturaleza, y ninguno aparece en el catálogo de vulnerabilidades explotadas conocidas de CISA hasta el 7 de septiembre. Un proveedor de gestión de superficie de ataque, IONIX, afirma en su sitio que está 'rastreando intentos de explotación en curso', pero no proporciona fechas, volúmenes ni otros detalles, y no distingue la explotación del escaneo ordinario de Internet del manejador.

El componente tiene un largo historial de ataques en el mundo real, pero a través de bugs más antiguos, no de estos. Una falla de deserialización de 2019 en el mismo manejador, CVE-2019-18935, se encadenó con una debilidad de cifrado de 2017 y fue explotada por grupos de ransomware y actores estatales, incluida una violación de 2022 a una agencia federal de EE. UU., y aún se explotaba hasta 2025. Ese historial es por lo que una ruta de ejecución de código no autenticado en este manejador llama la atención, incluso sin explotación confirmada.

Dos puntos adicionales delimitan la historia. El boletín de julio de Progress cubre en realidad dos cadenas de ataque separadas: la cadena de RadAsyncUpload detallada por TantoSec, y una cadena distinta de ejecución remota de código en los componentes RadPersistenceManager y RadDockLayout (CVE-2026-13185, -13186 y -13190), atribuida a Markus Wulftange de CODE WHITE y a Progress, para la cual no se ha lanzado ningún exploit público. Y dentro de la cadena de RadAsyncUpload, una cuarta falla que involucra una clave predeterminada predecible (CVE-2026-13184) se aplica solo a un modo de ataque alternativo que la demostración publicada no utilizó.

Recomendaciones y mitigaciones

Actualice a Telerik UI para ASP.NET AJAX 2026.2.708 (2026 Q2 SP1) o posterior, que reemplaza el esquema AES-CBC defectuoso con cifrado autenticado y cierra toda la cadena. Progress califica la actualización como su única recomendación oficial y advierte que una clave personalizada más fuerte no ayuda, porque el oráculo nunca necesita la clave.

Para los sitios que no puedan actualizar de inmediato, Progress señala varios pasos provisionales:

  • Configurar customErrors a RemoteOnly u On, lo que obliga al atacante a usar la variante más lenta basada en tiempos.
  • Deshabilitar el manejador de carga por completo (Telerik.Web.DisableAsyncUploadHandler establecido en true) si RadAsyncUpload no es necesario.
  • Eliminar cualquier clave de cifrado personalizada para que el control use la clave de máquina de ASP.NET con AES y HMAC, o generar claves de máquina fuertes manualmente en lugar de en tiempo de ejecución.

Dado que Progress advierte que una explotación exitosa 'no deja rastros obvios en los registros de errores estándar de ASP.NET', los defensores deben buscar comportamientos anómalos en lugar de firmas de error: el proceso de trabajo de IIS (w3wp.exe) ejecutando cmd.exe, un archivo .aspx nuevo o inesperado en la raíz web, o una DLL de modo mixto escrita en la carpeta temporal del control de carga o en App_Data.

TantoSec informó los problemas a Progress el 22 de mayo; el parche se lanzó el 8 de julio y los CVE siguieron el 22 de julio. Almeida atribuyó a su colega Justin Steven la variante del oráculo de tiempo.

Cybersecurity
Cybersecurity
Cybersecurity
Cybersecurity

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *