L’exploit public de Telerik RadAsyncUpload enchaîne un oracle de padding jusqu’à l’exécution de code à distance sans authentification

Une chaîne d’exploitation fonctionnelle ciblant Progress Telerik UI for ASP.NET AJAX a été publiée le 7 septembre 2026, transformant plusieurs faiblesses de RadAsyncUpload en exécution de code à distance sans authentification.

La société de sécurité TantoSec a publié l’outil en ligne de commande telerik-rau-exploit, accompagné de deux charges utiles DLL en mode mixte. L’une écrit un web shell sur le serveur cible, tandis que l’autre s’exécute entièrement en mémoire.

L’attaque n’est pas universelle. Elle nécessite une configuration applicative particulière, non activée par défaut, en plus d’une version vulnérable de Telerik. Lorsque ces conditions sont réunies, un attaquant non authentifié peut récupérer ou forger des métadonnées de téléversement chiffrées, sélectionner un type .NET arbitraire et contraindre IIS à charger du code malveillant.

Progress a corrigé la chaîne dans Telerik UI for ASP.NET AJAX 2026.2.708, également identifié comme 2026 Q2 SP1. Cette version a été publiée le 8 juillet, avant la publication des CVE et de l’avis de sécurité, le 22 juillet.

L’exploitation nécessite trois conditions de déploiement

Progress indique que les versions 2010.1.309 à 2026.2.519 de Telerik UI for ASP.NET AJAX sont affectées par la chaîne RadAsyncUpload. La version 2026.2.708 et les versions ultérieures intègrent le correctif.

La NVD recense plus largement CVE-2026-13181, CVE-2026-13182, CVE-2026-13183 et CVE-2026-13184 comme affectant les versions antérieures à 2026.2.708.

L’utilisation d’une version vulnérable ne suffit pas à rendre l’exploit publié opérant. Selon TantoSec, les trois conditions suivantes doivent être réunies :

• L’application affiche un contrôle RadAsyncUpload.
• Le code applicatif côté serveur lit ou traite d’une autre manière le résultat du téléversement.
• Le contrôle utilise une clé de chiffrement configurée explicitement, différente de la valeur par défaut.

L’exigence d’une clé personnalisée est notable, car Telerik recommande les paramètres de chiffrement personnalisés comme mesure de renforcement de la sécurité. Il ne suffit pas de faire tourner cette clé ou de la remplacer par une valeur plus robuste pour bloquer l’attaque : l’oracle de padding fonctionne sans avoir à découvrir la clé elle-même.

Les applications qui ne présentent pas l’un des deux comportements applicatifs requis ne sont pas exploitables au moyen de la chaîne RadAsyncUpload publiée. Les administrateurs doivent donc examiner l’utilisation réelle des contrôles et la configuration, plutôt que de s’appuyer exclusivement sur les inventaires de paquets.

L’attaque génère également un trafic considérable. Une exécution complète en laboratoire a nécessité environ 127 000 requêtes vers l’oracle et a duré près d’une heure. Une limitation du débit ou une infrastructure de production plus lente pourrait prolonger cette durée et créer une occasion de détection.

Comment l’oracle de padding devient une exécution de code

RadAsyncUpload protège l’état côté client avec AES en mode CBC, mais n’ajoute pas de mécanisme d’intégrité capable de détecter la manipulation du texte chiffré avant son traitement.

Lorsqu’un serveur reçoit des métadonnées chiffrées modifiées, son comportement varie selon le résultat. Les données dont le padding cryptographique est invalide suivent un chemin, tandis que celles qui passent la validation du padding mais échouent lors de l’analyse JSON suivent un autre chemin.

Cette distinction crée un oracle de padding. En modifiant à plusieurs reprises le texte chiffré et en observant les réponses de l’application, un attaquant peut déduire des informations sur les métadonnées de téléversement protégées.

La désactivation des réponses d’erreur détaillées ne suffit pas nécessairement à supprimer ce signal. Des différences dans les temps de traitement peuvent encore révéler si le padding a été accepté, produisant l’oracle fondé sur le temps d’exécution suivi sous CVE-2026-13183. TantoSec a attribué cette variante à Justin Steven.

TantoSec a également mis au point une méthode exploitant la graine de chiffrement fixe du contrôle pour forger une configuration de téléversement chiffrée sans récupérer la clé de chiffrement configurée. La configuration ainsi créée peut définir un type .NET choisi par l’attaquant.

RadAsyncUpload résout ce type sans appliquer de liste blanche. L’objet est ensuite désérialisé en un gadget qui récupère et charge une DLL depuis un emplacement contrôlé par l’attaquant.

Les charges utiles publiées sont des assemblys en mode mixte contenant des composants managés et natifs. Le code natif s’exécute au chargement de la DLL, avec l’identité et les permissions du pool d’applications IIS. L’attaquant peut ainsi accéder aux fichiers de l’application, aux secrets et aux autres ressources accessibles au processus worker.

Quatre CVE composent la chaîne RadAsyncUpload publiée

Les faiblesses divulguées couvrent l’oracle cryptographique, la falsification des métadonnées et l’étape finale d’exécution de code.

Vulnérabilité	Rôle dans l’attaque	CVSS
CVE-2026-13181	Le traitement de AsyncUploadTypeName contrôlé par l’attaquant permet une résolution dangereuse de type .NET et une RCE	8.1
CVE-2026-13182	Des erreurs distinctes lors du déchiffrement et du traitement JSON exposent un oracle de padding AES-CBC	7.5
CVE-2026-13183	Les différences de temps de réponse préservent l’oracle lorsque les erreurs détaillées sont masquées	7.5
CVE-2026-13184	Une clé d’intégrité par défaut prévisible peut permettre la falsification de métadonnées dans un autre mode d’attaque	7.5

CVE-2026-13181 possède le vecteur CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Son niveau élevé de complexité de l’attaque reflète les conditions de déploiement nécessaires, et non un besoin d’authentification ou d’interaction de l’utilisateur.

CVE-2026-13182 et CVE-2026-13183 possèdent toutes deux le vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Elles fournissent des primitives de divulgation d’informations facilitant les manipulations ultérieures.

CVE-2026-13184 possède le vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. Elle s’applique lorsque Telerik.Upload.ConfigurationHashKey est absent et que machineKey n’a pas été configuré explicitement, ce qui peut laisser l’intégrité des métadonnées de téléversement dépendre d’une clé par défaut prévisible. Cette autre voie n’a pas été utilisée dans la démonstration publiée.

Une autre chaîne de RCE Telerik a également été corrigée

Le bulletin publié par Progress en juillet traitait également d’une voie indépendante d’exécution de code à distance sans authentification affectant les applications qui utilisent un stockage fondé sur les cookies dans RadPersistenceManager ou RadDockLayout.

Cette chaîne comprend CVE-2026-13185, CVE-2026-13186 et CVE-2026-13190. Toutes trois ont un score CVSS de 8.1 et le vecteur CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.

CVE-2026-13185 concerne la désérialisation de contenu de cookie contrôlé par l’attaquant. Les informations précises sur les versions affectées, les classifications CWE et les détails techniques de CVE-2026-13186 et CVE-2026-13190 ne sont pas connus.

La découverte a été attribuée à Markus Wulftange, chercheur chez CODE WHITE, et à Progress. Aucun exploit public visant cette seconde chaîne n’a été publié.

Appliquer le correctif, puis rechercher les indicateurs au niveau d’IIS

La recommandation officielle de Progress consiste à installer Telerik UI for ASP.NET AJAX 2026.2.708 ou une version ultérieure. L’implémentation corrigée remplace la construction CBC vulnérable par un chiffrement authentifié et ferme l’ensemble de la voie d’attaque RadAsyncUpload.

Lorsqu’un déploiement immédiat est impossible, Progress préconise plusieurs mesures temporaires :

1. Définir customErrors d’ASP.NET sur RemoteOnly ou On. Cela masque les différences explicites entre les erreurs, même si les attaquants peuvent toujours exploiter l’oracle fondé sur des différences de temps, plus lentes.
2. Définir Telerik.Web.DisableAsyncUploadHandler sur true si RadAsyncUpload n’est pas nécessaire.
3. Supprimer la clé de chiffrement personnalisée des téléversements afin de laisser le contrôle utiliser une clé machine ASP.NET avec AES et HMAC.
4. Autre possibilité : configurer manuellement des clés machine robustes au lieu de les générer à l’exécution.

Ces mesures doivent être considérées comme une réduction temporaire du risque, et non comme un substitut à l’installation de la version corrigée.

Les journaux d’erreurs ASP.NET classiques peuvent ne pas fournir de preuves claires d’une exploitation réussie. Les équipes de défense doivent examiner la télémétrie des points de terminaison, du système de fichiers et des requêtes web à la recherche des éléments suivants :

• w3wp.exe lançant cmd.exe ou d’autres processus enfants inattendus.
• De nouveaux fichiers .aspx ou des fichiers .aspx modifiés sous la racine web d’une application.
• Des DLL en mode mixte apparaissant dans les répertoires temporaires de RadAsyncUpload.
• La création inattendue de DLL sous App_Data.
• Des requêtes malformées persistantes vers le gestionnaire RadAsyncUpload.
• De longues séquences de requêtes correspondant à environ 127 000 sondes de l’oracle.
• Des échecs répétés liés aux métadonnées chiffrées ou des tentatives d’expérimentation fondées sur les temps de réponse.

Une charge utile exécutée en mémoire peut laisser moins de traces sur le système de fichiers, ce qui rend particulièrement importante l’analyse du comportement des processus worker et de la télémétrie réseau.

Aucune exploitation confirmée en 2026, mais un historique KEV pour Telerik

Au 7 septembre, aucune des vulnérabilités Telerik de 2026 décrites ici ne figurait dans le catalogue Known Exploited Vulnerabilities de la CISA. Aucun signalement confirmé n’indique non plus que la nouvelle chaîne ait été utilisée avec succès dans le cadre d’attaques réelles.

La société de gestion de la surface d’attaque IONIX affirme suivre des tentatives d’exploitation, mais n’a fourni ni dates, ni volumes, ni éléments techniques permettant de distinguer une exploitation ciblée d’un balayage courant. Cette affirmation n’est pas vérifiée.

Le composant de téléversement de Telerik possède néanmoins un historique d’exploitation documenté. CVE-2019-18935, une faille critique de désérialisation de RadAsyncUpload notée 9.8, a intégré le catalogue KEV de la CISA le 3 novembre 2021. Les agences fédérales américaines avaient jusqu’au 3 mai 2022 pour y remédier et devaient appliquer les mises à jour du fournisseur.

Cette ancienne vulnérabilité a été utilisée dans des campagnes de rançongiciel et par des acteurs liés à des États, notamment lors d’une compromission d’une agence fédérale américaine en 2022. L’exploitation se serait poursuivie jusqu’en 2025. Ces incidents ne démontrent pas l’exploitation des nouvelles CVE, mais montrent que les gestionnaires Telerik exposés restent des cibles privilégiées.

Une autre vulnérabilité associée à Telerik et Progress, CVE-2026-8037, a intégré le catalogue KEV le 7 août 2026. La publication d’un exploit complet visant RadAsyncUpload fournit désormais aux défenseurs une raison supplémentaire d’inventorier les contrôles exposés et d’installer 2026.2.708 sans attendre.