Una cadena de exploits pública de Telerik RadAsyncUpload encadena un padding oracle hasta lograr RCE sin autenticación

El 7 de septiembre de 2026 se publicó una cadena de exploits funcional contra Progress Telerik UI for ASP.NET AJAX, que convierte varias vulnerabilidades de RadAsyncUpload en ejecución remota de código sin autenticación.

La empresa de seguridad TantoSec publicó la herramienta de línea de comandos telerik-rau-exploit junto con dos payloads DLL de modo mixto. Uno escribe una web shell en el servidor objetivo, mientras que el otro se ejecuta completamente en memoria.

El ataque no es universal. Además de una versión vulnerable de Telerik, requiere una configuración específica de la aplicación que no viene habilitada de forma predeterminada. Sin embargo, cuando se dan esas condiciones, un atacante sin autenticación puede recuperar o falsificar metadatos de carga cifrados, seleccionar un tipo .NET arbitrario y hacer que IIS cargue código malicioso.

Progress corrigió la cadena en Telerik UI for ASP.NET AJAX 2026.2.708, también identificada como 2026 Q2 SP1. La versión se publicó el 8 de julio, antes de que los CVE y el aviso de seguridad se hicieran públicos el 22 de julio.

El exploit requiere tres condiciones de despliegue

Progress identifica como afectadas por la cadena de RadAsyncUpload las versiones de Telerik UI for ASP.NET AJAX comprendidas entre 2010.1.309 y 2026.2.519. La versión 2026.2.708 y las posteriores contienen la corrección.

NVD registra CVE-2026-13181, CVE-2026-13182, CVE-2026-13183 y CVE-2026-13184 de forma más amplia como vulnerabilidades que afectan a las versiones anteriores a 2026.2.708.

Ejecutar una versión vulnerable no basta para utilizar el exploit publicado. Según TantoSec, deben cumplirse estas tres condiciones:

• La aplicación muestra un control RadAsyncUpload.
• El código de la aplicación en el servidor lee o procesa de algún otro modo el resultado de la carga.
• El control utiliza una clave de cifrado configurada explícitamente y no predeterminada.

El requisito de utilizar una clave personalizada resulta llamativo, ya que Telerik ha recomendado las configuraciones de cifrado personalizadas como medida de refuerzo de la seguridad. Rotar esa clave o sustituirla por otra más robusta no detiene el ataque: el padding oracle funciona sin necesidad de descubrir la propia clave.

Las aplicaciones que no presentan alguno de los dos comportamientos necesarios a nivel de aplicación no pueden explotarse mediante la cadena pública de RadAsyncUpload. Por tanto, los administradores deberían revisar el uso y la configuración reales de los controles, en lugar de basarse exclusivamente en los inventarios de paquetes.

El ataque también genera un volumen considerable de tráfico. Una ejecución completa en laboratorio requirió aproximadamente 127.000 solicitudes al oracle y tardó alrededor de una hora. La limitación de velocidad o una infraestructura de producción más lenta podrían prolongar ese periodo y ofrecer una posible oportunidad de detección.

Cómo un padding oracle se convierte en ejecución de código

RadAsyncUpload protege el estado del cliente mediante AES en modo CBC, pero no añade un mecanismo de integridad capaz de detectar la manipulación del texto cifrado antes de procesarlo.

Cuando un servidor recibe metadatos cifrados modificados, su comportamiento varía según el resultado. Los datos con un padding criptográfico no válido siguen un camino, mientras que los datos que superan la validación del padding pero fallan durante el análisis del JSON siguen otro.

Esa diferencia crea un padding oracle. Al modificar repetidamente el texto cifrado y observar las respuestas de la aplicación, un atacante puede deducir información sobre los metadatos de carga protegidos.

Desactivar las respuestas de error detalladas no elimina necesariamente la señal. Las diferencias en los tiempos de procesamiento aún pueden revelar si el padding se aceptó, lo que da lugar al oracle basado en tiempo registrado como CVE-2026-13183. TantoSec atribuyó esta variante a Justin Steven.

TantoSec también desarrolló un método que utiliza la semilla de cifrado fija del control para falsificar una configuración de carga cifrada sin recuperar la clave de cifrado configurada. La configuración resultante puede establecer un tipo .NET elegido por el atacante.

RadAsyncUpload resuelve ese tipo sin aplicar una lista de permitidos. Después, el objeto se deserializa en un gadget que recupera y carga una DLL desde una ubicación controlada por el atacante.

Los payloads publicados son ensamblados de modo mixto que contienen componentes administrados y nativos. El código nativo se ejecuta cuando se carga la DLL, con la identidad y los permisos del grupo de aplicaciones de IIS. Por consiguiente, el atacante puede acceder a archivos de la aplicación, secretos y otros recursos disponibles para el proceso de trabajo.

Cuatro CVE forman la cadena pública de RadAsyncUpload

Las vulnerabilidades divulgadas abarcan el oracle criptográfico, la falsificación de metadatos y la fase final de ejecución de código.

Vulnerabilidad	Función en el ataque	CVSS
CVE-2026-13181	El procesamiento de AsyncUploadTypeName controlado por el atacante permite resolver tipos .NET de forma insegura y lograr RCE	8,1
CVE-2026-13182	Los fallos diferenciados en el descifrado y el procesamiento del JSON exponen un padding oracle de AES-CBC	7,5
CVE-2026-13183	Las diferencias en los tiempos de respuesta mantienen el oracle cuando se ocultan los errores detallados	7,5
CVE-2026-13184	Una clave de integridad predeterminada predecible puede permitir falsificar metadatos en una modalidad de ataque alternativa	7,5

CVE-2026-13181 tiene el vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Su nivel alto de complejidad del ataque refleja las condiciones de despliegue necesarias, no la necesidad de autenticación o interacción del usuario.

CVE-2026-13182 y CVE-2026-13183 tienen el vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Proporcionan primitivas de divulgación de información que permiten realizar manipulaciones posteriores.

CVE-2026-13184 tiene el vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. Se aplica cuando falta Telerik.Upload.ConfigurationHashKey y machineKey no se ha configurado explícitamente, lo que puede hacer que la integridad de los metadatos de carga dependa de una clave predeterminada predecible. Esta vía alternativa no se utilizó en la demostración publicada.

Otra cadena de RCE de Telerik también recibió correcciones

El boletín de Progress de julio también abordó una vía independiente de RCE sin autenticación que afecta a las aplicaciones que utilizan almacenamiento basado en cookies en RadPersistenceManager o RadDockLayout.

La cadena incluye CVE-2026-13185, CVE-2026-13186 y CVE-2026-13190. Las tres tienen una puntuación CVSS de 8,1 y el vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.

CVE-2026-13185 implica la deserialización del contenido de cookies controlado por el atacante. No se conocen los datos exactos de las versiones afectadas, las clasificaciones CWE ni los registros técnicos de CVE-2026-13186 y CVE-2026-13190.

La investigación se atribuyó a Markus Wulftange, investigador de CODE WHITE, y a Progress. No se ha publicado ningún exploit para esta segunda cadena.

Aplicar primero el parche y buscar después indicadores en el nivel de IIS

La recomendación oficial de Progress es instalar Telerik UI for ASP.NET AJAX 2026.2.708 o una versión posterior. La implementación corregida sustituye la construcción CBC vulnerable por un cifrado autenticado y cierra por completo la vía de RadAsyncUpload.

Cuando no sea posible aplicar el parche de inmediato, Progress enumera varias medidas temporales:

1. Establecer customErrors de ASP.NET en RemoteOnly u On. Esto oculta las diferencias explícitas entre errores, aunque los atacantes aún pueden utilizar el oracle basado en tiempos, más lento.
2. Establecer Telerik.Web.DisableAsyncUploadHandler en true si no se necesita RadAsyncUpload.
3. Eliminar la clave de cifrado personalizada de las cargas, para que el control utilice una clave de máquina de ASP.NET con AES y HMAC.
4. Como alternativa, configurar manualmente claves de máquina robustas en lugar de generarlas durante la ejecución.

Estas medidas deben considerarse una reducción temporal del riesgo, no sustitutos de la versión corregida.

Los registros de errores estándar de ASP.NET pueden no aportar pruebas claras de una explotación exitosa. Los equipos de defensa deberían revisar la telemetría de endpoints, sistemas de archivos y solicitudes web en busca de:

• w3wp.exe iniciando cmd.exe u otros procesos secundarios inesperados.
• Archivos .aspx nuevos o modificados en la raíz web de una aplicación.
• DLL de modo mixto en directorios temporales de RadAsyncUpload.
• Creación inesperada de DLL en App_Data.
• Solicitudes malformadas sostenidas contra el controlador de RadAsyncUpload.
• Grandes secuencias de solicitudes compatibles con aproximadamente 127.000 sondeos del oracle.
• Fallos repetidos relacionados con metadatos cifrados o pruebas orientadas a medir tiempos.

Un payload en memoria puede dejar menos artefactos en el sistema de archivos, por lo que el comportamiento de los procesos de trabajo y la telemetría de red son especialmente relevantes.

No hay explotación confirmada en 2026, pero Telerik tiene antecedentes en KEV

A fecha del 7 de septiembre de 2026, ninguna de las vulnerabilidades de Telerik de 2026 descritas aquí figuraba en el catálogo Known Exploited Vulnerabilities de CISA. Tampoco hay informes confirmados de que la nueva cadena se haya utilizado con éxito en ataques reales.

La empresa de gestión de la superficie de ataque IONIX afirma que está siguiendo intentos de explotación, pero no ha aportado fechas, volúmenes ni pruebas técnicas que permitan distinguir entre una explotación dirigida y el escaneo rutinario. La afirmación no está verificada.

No obstante, el componente de carga de Telerik cuenta con un historial documentado de explotación. CVE-2019-18935, un fallo crítico de deserialización de RadAsyncUpload con una puntuación de 9,8, entró en el catálogo KEV de CISA el 3 de noviembre de 2021. Las agencias federales estadounidenses recibieron como fecha límite de corrección el 3 de mayo de 2022, con instrucciones de aplicar las actualizaciones del proveedor.

Esa vulnerabilidad anterior se utilizó en campañas de ransomware y por actores estatales, incluido un ataque contra una agencia federal estadounidense en 2022. Según los informes, la explotación continuó hasta 2025. Estos incidentes no demuestran que se hayan explotado los nuevos CVE, pero muestran que los controladores de Telerik expuestos siguen siendo objetivos atractivos.

Otra vulnerabilidad asociada con Telerik y Progress, CVE-2026-8037, entró en KEV el 7 de agosto de 2026. La publicación de un exploit completo para RadAsyncUpload ofrece ahora a los equipos de defensa un motivo adicional para inventariar los controles expuestos e instalar 2026.2.708 sin demora.