Exploit público de Telerik UI en ASP.NET: parche en julio; otro boletín pide 2026.3.812

Corrección del 15 de septiembre de 2026. La primera versión de esta nota decía que con 2026.2.708 ya estabas cubierto. Era un error nuestro: un boletín de Progress del 2 de septiembre, anterior a la nota, deja afectada esa versión si la aplicación usa RadEditor o RadImageEditor, y el arreglo es la 2026.3.812. Lo explicamos en una sección nueva.

Desde el 7 de septiembre de 2026 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, 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ó ese día. 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. Aparte, un segundo boletín de Progress, de septiembre, por otra cadena, lleva la versión a instalar a la 2026.3.812.

¿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 en el mismo boletín de julio 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 de julio entero, ni del de septiembre. Que es, justamente, el argumento para actualizar igual.

Qué versión afecta la cadena de julio y cuál la arregla

El boletín de julio lista tres componentes, todos con el mismo techo —2026.2.519— y el mismo arreglo: 2026.2.708, publicada el 8 de julio. Lo que cambia entre los tres es a qué aplicaciones les toca. Para RadEditor y RadImageEditor rige otro rango, el del boletín de septiembre. 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.

El boletín de septiembre: otra cadena, y ahí 2026.2.708 no alcanza

El 2 de septiembre, Progress publicó un segundo boletín crítico de seguridad. Es otra cadena, en otros componentes, y el crédito vuelve a ser de Marcio Almeida, de TantoSec. Según el fabricante, un atacante sin autenticar puede encadenar dos fallos hasta ejecutar código en el servidor:

• CVE-2026-18672 (CVSS 7.5): un path traversal en RadImageEditor que puede dejar leer archivos fuera de las carpetas de imágenes, sin autenticarse. El boletín dice que por ahí se pueden obtener secretos de configuración de la aplicación. Según su ficha, alcanza con usar RadImageEditor (suelto o dentro del editor de imágenes de RadEditor) para estar potencialmente afectado, y no hay configuración que lo mitigue antes de actualizar.
• CVE-2026-19219 (CVSS 8.1): los parámetros de los diálogos del explorador de archivos de RadEditor no tienen suficiente protección de integridad. Con cierto material de claves de la aplicación en la mano, un atacante puede cambiar las carpetas donde ese explorador lee, escribe y sube archivos, y eso puede terminar en ejecución remota de código.

¿Te toca? Y dónde se cruza con el boletín de julio

Según la ficha de CVE-2026-19219, la aplicación puede ser vulnerable si se dan todas estas condiciones: usa RadEditor con los diálogos de explorador de archivos habilitados; tiene una Telerik.Web.UI.DialogParametersEncryptionKey propia o una machineKey con valor fijo; y ese material de claves quedó expuesto o se obtuvo por otra vía. Con la machineKey autogenerada y sin clave propia para los diálogos, este vector no se puede falsificar en remoto.

El problema: según el boletín de septiembre, la mitad de RadImageEditor permite obtener cualquier DialogParametersEncryptionKey configurada, así que el secreto de la clave no alcanza para frenar del todo esta cadena.

🔴 Acá se cruzan los dos boletines. El de julio aconseja generar la machineKey a mano en IIS (para v2026.2.514 y anteriores) y, desde 2026.2.708, permite volver a usar claves propias: las dos cosas figuran entre esas condiciones. Según la ficha, ninguna de las dos alcanza sola, porque exige además que la clave haya quedado expuesta; pero no lo tomes como resguardo, porque con RadImageEditor la propia cadena puede servir para obtener la clave propia de los diálogos (párrafo anterior). Si tu aplicación usa RadEditor, la salida no es elegir entre consejos: es actualizar a 2026.3.812.

Mitigaciones de septiembre y estado de explotación

Para Progress, solo actualizar cierra esta cadena; estas medidas reducen el riesgo mientras tanto:

• Confirmar que la identidad del grupo de aplicaciones no tenga permiso de escritura en la raíz de la aplicación web, y deshabilitar la ejecución de scripts en cualquier carpeta donde sí pueda escribir.
• Sacar de las páginas los controles RadImageEditor y RadEditor afectados hasta poder actualizar.
• Si la aplicación no necesita los diálogos ni el explorador de archivos, deshabilitar el manejador Telerik.Web.UI.DialogHandler.aspx en el web.config.

¿Hay explotación de esta cadena? El boletín no la informa, CISA marcó la explotación como none en las dos CVE el 2 de septiembre y ninguna figura en el catálogo KEV del 14 de septiembre. No encontramos una herramienta pública: es ausencia de información, no garantía.

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.

¿Están usando la cadena de julio? 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, según TantoSec, salió arreglado en 2026.2.708 junto con el resto, aunque esos hallazgos nuevos no tengan CVE propia en el boletín de julio. La versión salió el 8 de julio, las CVE el 22 de julio, y el informe con la herramienta recién el 7 de septiembre, 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), y el boletín de septiembre repite la misma advertencia para su cadena. Buscar excepciones no sirve.

Hasta ahí los boletines. Lo que sigue no está en ninguno de los dos boletines de Progress y apunta a la cadena de julio: 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 de julio, 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 en el boletín de julio (las de septiembre están en su sección):

• 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. El boletín de julio agrega que desde 2026.2.708 se pueden volver a usar claves propias, porque ahí protegen con AES-GCM. Si tu aplicación usa RadEditor, leé antes el cruce con el boletín de septiembre.
• 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 de julio, 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 julio 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. En la cadena de septiembre tampoco sirve, por lo que explicamos más arriba.

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 —a 2026.3.812 o posterior— 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 boletín de julio 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

El 7 de septiembre salió un exploit funcional para un fallo que el fabricante había arreglado dos meses antes 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 CVE-2026-13181 no está en el catálogo de explotación conocida de CISA. Eso no es una emergencia: es una tarea de mantenimiento con fecha, y con el boletín de septiembre la versión de destino es la 2026.3.812.

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 ⬇️