Hay exploit público para Telerik UI en ASP.NET: el parche está desde julio

Desde hoy hay una herramienta pública que convierte un fallo de cifrado de Telerik UI para ASP.NET AJAX en ejecución de código en el servidor, sin usuario y sin contraseña. La publicó la consultora australiana TantoSec el 7 de septiembre de 2026, junto con el análisis de la cadena paso por paso. Y antes de que cierres la pestaña para ir a apagar el servidor: Progress publicó el parche el 8 de julio, casi dos meses antes, y la cadena no funciona sobre una instalación por defecto.

Eso no vuelve inofensivo al exploit de Telerik que se publicó hoy. Lo vuelve chequeable, que es distinto: en diez minutos podés saber si tu aplicación cumple las dos condiciones que hacen falta, y si las cumple, sabés exactamente qué actualizar.

¿Esto te toca a vos? Son dos condiciones, no una

Acá está la parte que los titulares se comen. Correr una versión afectada no alcanza para ser vulnerable a esta cadena. TantoSec lo escribe en su propio informe, en la sección de resumen: la cadena tiene «precondiciones que no se cumplen en una instalación por defecto» (traducción propia; en el original, «preconditions that are not met by a default installation»). Son dos, y tienen que darse las dos:

• Una página alcanzable con un control RadAsyncUpload cuyo manejador del lado del servidor (FileUploaded) lea la propiedad UploadResult. O sea: no cualquier pantalla con un botón de subir archivo, sino una que además haga algo con el resultado de esa subida.
• Una clave de cifrado propia y explícita configurada en Telerik.AsyncUpload.ConfigurationEncryptionKey.

Y acá viene el detalle que da un poco de bronca: esa segunda condición es una recomendación de endurecimiento del propio Telerik. TantoSec lo señala con todas las letras: «which is a recommended hardening setting», o sea, «que es una opción de endurecimiento recomendada». Es decir que la aplicación que siguió la guía de seguridad del fabricante y se puso una clave propia quedó en peor posición que la que dejó todo como venía. No es la primera vez que la seguridad informática le paga así al que hizo los deberes, pero sigue doliendo igual.

Si tu aplicación no cumple las dos, esta cadena concreta —la que TantoSec demostró— no te alcanza. Lo que no significa que estés al día, y acá hay que ser preciso para no dejarte con una falsa tranquilidad:

• No tener clave propia no es un escudo. Existe otra variante, la que se registró como CVE-2026-13184, que aplica justamente cuando no hay clave configurada: ahí la protección de integridad puede caer en una clave por defecto predecible. TantoSec explica que esa vía corresponde a un modo de inyección distinto, que su demostración publicada no usó — el laboratorio no tenía la clave por defecto, así que ese camino quedó fuera de la corrida. Según The Hacker News, para ese modo alternativo no se publicó herramienta.
• Y hay una segunda cadena aparte, en los componentes de persistencia, que no depende de nada de lo anterior.

Traducido: las dos condiciones te sacan del ataque que hoy tiene herramienta lista, no del boletín entero. Que es, justamente, el argumento para actualizar igual.

Qué versión te afecta y cuál lo arregla

El aviso de Progress lista tres componentes, todos con el mismo techo —2026.2.519— y el mismo arreglo: 2026.2.708 (2026 Q2 SP1). Lo que cambia entre ellos es a qué aplicaciones les toca. Para saber qué versión tenés, abrí el proyecto en Visual Studio y mirá la de Telerik.Web.UI.dll en las referencias.

Sí, leíste bien: 2010. La ventana de versiones afectadas arranca hace dieciséis años, que en una PyME con un sistema de facturación hecho a medida en 2014 y nunca tocado desde entonces es un escenario bastante realista.

Qué es un «oráculo de padding», en criollo

La cadena arranca con algo que suena esotérico y es bastante intuitivo. El control cifra su configuración con AES en modo CBC y sin ningún chequeo de integridad: no verifica que lo que le mandaron sea lo que él había emitido. Entonces, cuando alguien le manda datos manipulados, el servidor puede fallar de dos maneras distintas — porque el relleno del bloque no cierra, o porque cierra pero lo que queda adentro no es un JSON válido— y responde distinto en cada caso.

Esa diferencia es toda la filtración. Repitiéndola muchas veces, un atacante descifra el contenido y, con la técnica que TantoSec detalla en su informe, también puede forjar configuración válida sin conocer jamás la clave — el propio registro de su corrida lo dice sin vueltas al llegar a ese paso: forja los metadatos mediante el oráculo, sin necesitar clave alguna. Con eso nombra una clase .NET arbitraria que el control resuelve sin lista blanca, y termina cargando una DLL desde una ruta que el atacante controla.

Vale aclarar que «muchas veces» es literal: la corrida completa que documenta TantoSec necesitó unas 127.000 consultas a unas 30 por segundo — algo más de una hora contra un laboratorio propio—. La propia empresa aclara que contra un servidor remoto o con límite de peticiones eso se estira. No es un ataque de un clic, y esa lentitud es información útil para el que tiene que priorizar.

Si la aplicación esconde los mensajes de error detallados, el truco no muere: se lee la misma diferencia midiendo cuánto tarda el servidor en cada caso, una variante que se registró aparte como CVE-2026-13183. Y no es un plan B endeble — los propios investigadores la describen como una señal chica pero estable, que es de lo que vive un oráculo por tiempo. Por eso el arreglo real no fue esconder errores sino cambiar el cifrado: 2026.2.708 abandona AES-CBC y pasa a AES-GCM, que valida una etiqueta antes de descifrar nada. Si el primer byte manipulado se rechaza, no hay oráculo que consultar.

¿Lo están usando? Acá hay que ser honestos

Esta es la parte donde conviene separar lo que se sabe de lo que se supone, porque las tres fuentes disponibles dicen cosas distintas y ninguna cierra el tema.

• CISA, en julio: en su enriquecimiento del registro CVE, fechado el 23 de julio de 2026, clasificó la explotación como none y la automatización como no, con impacto técnico total. 🔴 Ojo con el alcance: esa evaluación es de julio, casi siete semanas antes de que existiera el exploit público, y el registro no muestra ninguna actualización posterior al 24 de julio de 2026. Es una foto vieja, no el estado de hoy.
• El catálogo KEV de CISA, el de vulnerabilidades con explotación conocida: verificamos el archivo completo el 7 de septiembre —versión del 4 de septiembre, 1.695 entradas— y CVE-2026-13181 no figura. Eso prueba ausencia en ese archivo y a esa fecha; no es una garantía hacia adelante.
• Un proveedor dice lo contrario, sin mostrar nada: la empresa IONIX afirma en su ficha del CVE que su equipo «está rastreando intentos de explotación en curso» (traducción propia; consultado el 7 de septiembre de 2026). La afirmación va sola: en esa página no la acompaña ninguna fecha ni volumen, y no distingue explotación real de escaneo rutinario del manejador, que es ruido de fondo permanente en internet. Conviene saber además que IONIX vende gestión de superficie de ataque y cierra esa misma página ofreciendo un informe de exposición. La dejamos citada y fechada, no como hecho.

Lo que no encontramos en ninguna fuente leída: víctimas. Ni en LATAM ni en ningún lado. Eso es ausencia de información publicada, no prueba de que no haya pasado nada.

El antecedente que explica por qué este componente asusta

El nerviosismo alrededor de RadAsyncUpload no es nuevo ni es infundado, pero viene de otro fallo. En 2019 se publicó CVE-2019-18935, una deserialización en el mismo manejador, y ése sí terminó explotado a gran escala: está en el catálogo KEV de CISA desde el 3 de noviembre de 2021, y la propia ficha lo marca con uso conocido en campañas de ransomware.

Ese historial es la razón por la que cualquier ejecución de código sin autenticar en este componente levanta la ceja de medio mundo. Pero son dos bichos distintos: el de 2019 fue explotado masivamente, el de 2026 —hasta donde muestran las fuentes públicas de hoy— no. Confundirlos es exactamente el error que convierte una tarea de mantenimiento en un fin de semana perdido.

Cómo se hizo esto: el caso raro donde todo funcionó

La cronología que publica TantoSec merece un párrafo, porque es la contracara de las noticias de zero-day que solemos escribir acá. Reportaron el 22 de mayo; Progress acusó recibo tres días después; en junio aparecieron dos hallazgos más; el 1 de julio el fabricante mandó una compilación de prueba para que los investigadores validaran el arreglo, y en esa revisión aparecieron varios problemas nuevos, entre ellos un XXE sin autenticar en RadLayoutBuilder, que se arreglaron en la misma versión aunque no tengan CVE propia en este boletín. La versión salió el 8 de julio, las CVE el 22 de julio, y el informe con la herramienta recién hoy, casi dos meses después del parche.

Divulgación coordinada de manual: quien tenía que arreglar, arregló; quien encontró, esperó. Si estás corriendo una versión vieja a esta altura, el problema ya no es de Progress.

Si ya te pasó, no lo vas a ver en el log de errores

Este punto sale del aviso del fabricante y conviene tomarlo en serio: Progress advierte que una explotación exitosa «no deja rastro evidente en los registros de error estándar de ASP.NET» (traducción propia). Buscar excepciones no sirve.

Hasta ahí el boletín. Lo que sigue no está en el aviso de Progress: son las señales de comportamiento que propone The Hacker News, más las que se desprenden de la cadena que documentó TantoSec. Van con esa atribución, no como recomendación del fabricante:

• El proceso de trabajo de IIS (w3wp.exe) lanzando cmd.exe o cualquier intérprete de comandos (señal propuesta por The Hacker News, genérica de webshell).
• Archivos .aspx nuevos o inesperados en la raíz del sitio. En la demostración de TantoSec, el paso final escribe precisamente un shell.aspx.
• Una DLL escrita en la carpeta temporal del control de subida o dentro de App_Data: es donde aterriza el archivo en la corrida documentada.
• Ráfagas largas de peticiones al manejador Telerik.Web.UI.WebResource.axd, y en particular con el parámetro type=rau, que es el que enruta al control de subida. Recordá el orden de magnitud: la corrida de laboratorio necesitó más de cien mil peticiones, así que el patrón es un volumen anómalo sostenido, no un puñado de intentos.

Mitigaciones oficiales, si de verdad no podés actualizar

Progress es explícito en que su única recomendación oficial es actualizar y en que lo demás es, en sus palabras, «un paliativo temporal» (traducción propia). Con esa advertencia por delante, éstas son las medidas que publica:

• Poner customErrors en RemoteOnly u On en el Web.config. No cierra el agujero: obliga al atacante a usar la variante por tiempo, que es más lenta y más trabajosa, pero que —según los propios investigadores— no impide la explotación.
• Desactivar el manejador de subida si la aplicación no lo usa, con Telerik.Web.DisableAsyncUploadHandler en true.
• Revisar las claves personalizadas del Web.config. Para las versiones que el boletín identifica como v2026.2.514 y anteriores, la recomendación del fabricante es quitarlas para que el control caiga en la clave de máquina de ASP.NET, que suma HMAC. 🔴 Y acá viene el paso que no se puede saltear, porque hacer solo la mitad te deja igual de expuesto: Progress marca como crítico generar esas claves a mano en IIS. Es decir, en IIS abrís el sitio, entrás en Machine Key, elegís HMACSHA256 como método de validación, destildás las dos casillas de «Automatically generate at runtime», hacés clic en Generate Keys, aplicás y reciclás el grupo de aplicaciones. Si las dejás autogeneradas, según el propio boletín se reproduce el mismo colapso del HMAC que se quería evitar. Después de actualizar a 2026.2.708 se pueden volver a usar claves propias, porque ahí ya protegen con AES-GCM.
• No usar almacenamiento en cookies para RadPersistenceManager ni RadDockLayout, y no derivar la clave de almacenamiento de datos que venga del usuario. Esto apunta a la otra cadena, la que no tiene exploit público.
• Mover la carpeta temporal de RadAsyncUpload fuera de App_Data. El boletín la clasifica como defensa en profundidad y aclara que va siempre después de la anterior, no en su lugar.

Las siete CVE del boletín, y quién encontró cada una

El boletín de julio no cubre una vulnerabilidad: son siete. Progress las presenta como una sola cadena combinada; The Hacker News las lee como dos cadenas separadas, y para el lector esa segunda lectura es la útil, porque distingue lo que hoy tiene herramienta de lo que no. TantoSec detalló y publicó herramienta para la de RadAsyncUpload. La otra, en los componentes de persistencia, fue reportada por Markus Wulftange de CODE WHITE y por el propio equipo de Progress; según el mismo medio, para ésa no se publicó exploit.

El detalle de cada una está en el boletín de seguridad de Progress, y la ficha individual de la principal, con su vector completo, en el artículo dedicado a CVE-2026-13181.

Preguntas que te vas a hacer

Tengo la versión afectada pero mi aplicación no es pública, corre en la red interna. ¿Cambia algo?

Cambia quién puede intentarlo. Si además cumplís las dos condiciones de arriba, el vector sigue siendo de red y sin autenticación: cualquiera que llegue al manejador puede probar. Lo que hace la red interna es reducir ese «cualquiera» a quien ya esté adentro — una mitigación real, no un blindaje, y que no sirve de nada si el atacante ya entró por otro lado.

¿Alcanza con poner una clave de cifrado más larga y más difícil?

No, y el fabricante lo dice de frente. El oráculo nunca necesitó la clave: se apoya en cómo responde el servidor, no en adivinar el secreto. Una clave más fuerte no toca el mecanismo.

Corro una versión de 2015 y actualizar me rompe media aplicación. ¿Qué hago?

Es el caso más común y el más incómodo. La ruta honesta es: aplicar las mitigaciones de arriba hoy como puente, y planificar la actualización con tiempo y con un entorno de prueba. Progress mantiene documentación de actualización entre versiones; si tu licencia quedó fuera del acuerdo de mantenimiento, el propio boletín indica contactar a un representante de la empresa para resolver el acceso a la descarga. Lo que no es una opción sostenible es quedarse en el puente para siempre.

La conclusión, sin épica

Hoy salió un exploit funcional para un fallo que el fabricante arregló hace dos meses y que necesita una configuración específica para funcionar. Ninguna de las fuentes que leímos documenta una víctima concreta —con la salvedad del reclamo sin evidencia de IONIX—, y el CVE no está en el catálogo de explotación conocida de CISA. Eso no es una emergencia: es una tarea de mantenimiento con fecha.

La emergencia sería la versión de esta historia donde nadie revisa qué versión corre, la nota se archiva y dentro de dos años aparece un CVE-2019-18935 nuevo, con su entrada en el KEV y su campaña de ransomware asociada. Esa historia ya la vivimos con este mismo componente. La diferencia, esta vez, es que el parche llegó primero.

¿Sabés qué versión de Telerik corre tu sistema? Contanos abajo ⬇️