Chaîne de lecture de fichiers vers RCE dans Telerik UI for ASP.NET AJAX (CVE-2026-18672)

TL;DR

• Une lecture de fichiers non authentifiée dans Progress Telerik UI for ASP.NET AJAX, CVE-2026-18672, permet à tout attaquant pouvant atteindre une page avec RadImageEditor ou RadEditor de lire des fichiers sous la racine de l'application, web.config compris. Tanto Security a publié la chaîne complète, requêtes fonctionnelles à l'appui, le 27 octobre 2026.
• La lecture s'enchaîne avec CVE-2026-19219, une faille de falsification des paramètres de dialogue, pour une exécution de code à distance non authentifiée sous l'identité du pool d'application quand web.config contient un machineKey statique ou un DialogParametersEncryptionKey personnalisé. Progress note la lecture High à 7,5 et la falsification High à 8,1, et son bulletin de chaîne est intitulé « Critical Security Bulletin ».
• Toutes les versions de 2011.2.712 à 2026.2.708 sont concernées. Aucune exploitation n'est connue, aucun des deux CVE ne figure au catalogue KEV du CISA au 3 novembre 2026, et le CISA ADP a enregistré Exploitation « none » le 2 septembre 2026.
• Mettez à niveau vers 2026.3.812 ou plus. Aucune configuration ne mitige entièrement la lecture de fichiers avant la mise à niveau : considérez tout site non corrigé exposant les contrôles comme exposé. « Comment corriger ? » détaille les mesures provisoires de l'éditeur.

Suis-je concerné ?

Vous êtes exposé à la lecture de fichiers lorsque toutes ces conditions sont réunies :

• Votre application exécute Progress Telerik UI for ASP.NET AJAX de 2011.2.712 à 2026.2.708, toute version d'une plage de quinze ans.
• Une page atteignable par des visiteurs non authentifiés affiche RadImageEditor, en contrôle autonome ou via l'outil Image Editor intégré de RadEditor, qui héberge un RadImageEditor en interne. Les handlers de la chaîne sont enregistrés une fois pour toute l'application, donc toute page affichant RadEditor fait entrer la machinerie de dialogues.
• L'attaquant n'a besoin que de cette page. La publication reproduit la lecture en deux requêtes non authentifiées et un __VIEWSTATE rejoué tel quel, signé seul et ne couvrant pas les autres champs cachés.

Vous êtes en plus exposé à la moitié RCE lorsque ces deux conditions tiennent :

• RadEditor est utilisé avec ses dialogues de navigateur de fichiers intégrés activés, et l'application définit un Telerik.Web.UI.DialogParametersEncryptionKey personnalisé dans web.config ou un machineKey statique plutôt que le défaut AutoGenerate. Progress recommande de configurer ces clés, mais aucune n'est présente dans une installation par défaut, et Progress indique que les déploiements AutoGenerate ne sont pas falsifiables à distance par ce vecteur.
• L'attaquant a récupéré la clé en lisant web.config via la lecture de fichiers ou par d'autres moyens.

Vérifiez l'assembly déployé et les clés de web.config :

# File version of the assembly the application deploys
Get-Item .\Bin\Telerik.Web.UI.dll |
  Select-Object -ExpandProperty VersionInfo |
  Format-List FileVersion, ProductVersion

# The two keys that turn the file read into RCE, if present
Select-String -Path .\web.config -Pattern "machineKey",
  "DialogParametersEncryptionKey"

L'absence d'élément machineKey dans web.config signifie que le défaut AutoGenerate s'applique, selon l'avis de l'éditeur. Un machineKey statique ou un DialogParametersEncryptionKey personnalisé est ce dont le chemin RCE a besoin, et une clé présente est un élément à confirmer, pas une compromission en soi.

Comment corriger ?

Mettez à niveau vers la version 2026 Q3, puis confirmez que les clés n'ont pas été exposées pendant l'attente :

1. Mettez à niveau chaque application utilisant la suite vers 2026.3.812 ou plus via la documentation de mise à niveau de l'éditeur. Progress a publié la version corrigée le 12 août 2026 et a invité les clients à mettre à niveau via ce bulletin de sécurité critique.
2. Renouvelez les clés exposées sur tout site ayant exécuté une version vulnérable avec un machineKey statique ou un DialogParametersEncryptionKey personnalisé et ne pouvant pas écarter la lecture. Traitez ces clés comme récupérables par un visiteur non authentifié.
3. Appliquez les mesures provisoires de l'éditeur là où la mise à niveau ne peut pas être déployée immédiatement. Elles réduisent le risque sans fermer entièrement la faille. Confirmez que l'identité du pool d'application n'a pas de droit d'écriture sur la racine web de l'application. Désactivez l'exécution de scripts sur tout dossier accessible en écriture.
4. Si le navigateur de fichiers de RadEditor n'est pas nécessaire, retirez les contrôles RadEditor concernés ou désactivez leurs dialogues de navigateur de fichiers, ou retirez le mapping DialogHandler de web.config. L'avis de l'éditeur donne les lignes <httpHandlers> et <handlers> exactes à retirer.

Filtrer la requête littérale Telerik.Web.UI.WebResource.axd?type=iec n'est pas une mitigation complète confirmée, selon l'éditeur : des mappings de handler alternatifs, des formes d'URL, des encodages et un HttpHandlerUrl personnalisé peuvent contourner un filtre écrit contre une seule route. Aucune configuration ne mitige la lecture de fichiers avant la mise à niveau.

Quelle est la cause racine ?

Le chemin d'image de RadImageEditor voyage vers le serveur dans un champ de formulaire caché ni chiffré ni signé. Le contrôle le stocke dans un cache de téléchargement qu'un second handler enregistré globalement lit ensuite sur le disque. Les paramètres de dialogue de RadEditor sont chiffrés et signés. Rien en dehors du blob ne contraint toutefois les dossiers qu'ils nomment.

RadImageEditor garde son état dans un champ caché de postback nommé <ClientID>_ClientState. La décompilation de Tanto Security, publiée avec l'analyse, montre comment la classe de base le charge :

// Telerik.Web.UI/RadWebControl.cs, decompiled by Tanto Security
// no message authentication code and no decrypt,
// so the whole dictionary is client-controlled
if ( !string . IsNullOrEmpty (text) &&
     new JavaScriptSerializer (). DeserializeObject (text)
         is Dictionary < string , object > clientState) {
    LoadClientState (clientState);
}

La redéfinition dans RadImageEditor copie la clé imageUrl de ce dictionnaire dans la propriété ImageUrl du contrôle. Le contrôle stocke ensuite ce chemin dans un cache de téléchargement pour servir le fichier lors d'une requête ultérieure. Un champ de page jamais authentifié par le serveur devient un chemin de fichier côté serveur.

La lecture repasse par Telerik.Web.UI.WebResource.axd?type=iec, l'ImageEditorCacheHandler enregistré une fois pour l'application. Le handler déchiffre le jeton _downloadKey reçu, cherche l'entrée dans le cache, mappe la chaîne stockée vers un chemin et renvoie les octets du fichier. Il déduit le type de contenu de la réponse depuis l'extension du fichier et ne restreint pas les extensions servies : web.config revient donc en image/config.

La résolution des chemins relatifs diverge entre les deux étapes : la récupération qui met le chemin en cache le résout depuis le dossier de la page, tandis que le handler le résout depuis la racine de l'application. Aucun chemin relatif ne satisfait les deux. Un chemin relatif à l'application le fait : ~/web.config désigne le même fichier aux deux étapes, il passe donc le contrôle d'existence de la récupération et le confinement à la racine du handler.

Pour la moitié RCE, les dialogues de RadEditor portent un blob de paramètres chiffré et authentifié, SerializedParameters, qui inclut les ViewPaths, UploadPaths et DeletePaths du navigateur de fichiers. La protection d'intégrité du blob prouve que le détenteur de la clé l'a produit, pas qu'un développeur a configuré ces dossiers, comme le conclut l'analyse. Quiconque détient la clé de chiffrement forge un blob valide qui pointe les envois vers la racine web.

Comment la faille est-elle exploitée ?

La preuve de concept publique est la séquence de requêtes publiée dans l'analyse de Tanto Security le 27 octobre 2026. Les étapes ci-dessous la suivent.

1. L'attaquant envoie un GET non authentifié vers une page affichant RadImageEditor et conserve le __VIEWSTATE et le nom du champ d'état client de la réponse.
2. L'attaquant renvoie un POST vers la même page, rejouant le __VIEWSTATE tel quel pour que son MAC passe, avec le champ d'état client portant le chemin empoisonné :

{"currentCommand": null, "imageUrl": "~/web.config", "imageKey": null,
 "height": null, "width": null, "enableResize": null,
 "toolBarPosition": null, "isf": null}

1. La réponse apporte un _downloadKey frais, le GUID chiffré de l'entrée de cache empoisonnée. Sur une page RadEditor, l'attaquant atteint le même contrôle via le dialogue ImageEditor, en récoltant le blob de paramètres généré par le serveur dans la page et en fournissant le chemin dans le champ de formulaire OriginalImageLocation.
2. L'attaquant envoie la clé à Telerik.Web.UI.WebResource.axd?type=iec&dkey=3, et le handler renvoie les octets de ~/web.config, la cible du PoC de l'analyse, en image/config.
3. Si le web.config récupéré contient un machineKey statique, l'attaquant forge un __VIEWSTATE signé portant une chaîne de gadget de désérialisation. C'est la technique ViewState ASP.NET standard construite par ysoserial.net, que l'analyse a reproduite pour écrire un webshell dans la racine web.
4. S'il contient un DialogParametersEncryptionKey, l'attaquant forge à la place le blob de paramètres de dialogue avec des UploadPaths sur la racine web. Le webshell passe ensuite par le navigateur de fichiers de RadEditor, le chemin que Progress a affecté à CVE-2026-19219.
5. Le code du webshell s'exécute sous l'identité du pool d'application IIS, et l'attaquant le contrôle dès ce point.

Comment se déroule l'attaque ?

Une séquence non authentifiée lit web.config, et les clés qu'il contient, lorsqu'elles sont configurées, transforment la lecture en exécution de code dans la racine web.

Que peut faire un attaquant ?

Le bulletin de chaîne de l'éditeur énonce l'impact combiné sans détour. Un attaquant distant non authentifié qui exploite la chaîne peut exécuter du code arbitraire sur le serveur web avec les privilèges de l'identité du pool d'application. Le bulletin évalue que cela peut aboutir à une compromission totale du serveur, une exfiltration de données ou un mouvement latéral dans l'environnement d'hébergement.

• La seule lecture de fichiers, CVE-2026-18672, expose chaque fichier sous la racine de l'application, et web.config est là où vivent les chaînes de connexion et les deux clés. Elle fonctionne sur les installations par défaut ; aucune clé n'est nécessaire pour lire.
• La chaîne RCE, via CVE-2026-19219, exige le matériel de clé : un machineKey statique ou un DialogParametersEncryptionKey personnalisé présent dans web.config. Un site resté sur le défaut AutoGenerate sans clé de dialogue personnalisée n'est pas falsifiable à distance par ce vecteur, selon l'avis de l'éditeur.
• L'exploitation est silencieuse. Le bulletin de l'éditeur note qu'il n'y a aucun symptôme visible et aucune trace évidente dans les journaux d'erreurs ASP.NET standards. Les deux chemins RCE de l'analyse se terminent chacun par un webshell fonctionnel plutôt que par un plantage.

Les conditions sont l'accessibilité réseau d'une page affichant les contrôles et, pour l'exécution de code, la présence des paramètres de clés. Aucune interaction utilisateur ni authentification n'est requise à aucune étape.

Pourquoi le correctif fonctionne-t-il ?

Progress distribue un assembly à code fermé, aucun diff de correctif n'est donc public à citer. Le comportement du correctif, tel que l'analyse l'a vérifié contre 2026.3.812, ferme les deux moitiés :

• Le handler de cache vérifie désormais le chemin déchiffré contre les répertoires d'images configurés du contrôle et applique une liste blanche d'extensions d'images : jpg, jpeg, png, gif et bmp. L'un ou l'autre contrôle arrête la lecture de web.config, et l'entrée OriginalImageLocation du dialogue passe désormais par les mêmes contrôles.
• RadImageEditor stocke désormais l'emplacement de son image dans l'état client sous forme chiffrée avec une clé serveur, donc un client ne peut plus y substituer son propre chemin sans cette clé.
• Le chemin d'envoi des dialogues applique une liste noire codée en dur d'extensions dangereuses à l'écriture des fichiers, rejetant .aspx, .ashx, .config, .exe et une longue liste d'autres types, et ajoute un paramètre Telerik.Web.UI.FileBrowserAllowedPaths opt-in qui restreint les dossiers que le navigateur de fichiers peut lister et utiliser pour l'envoi.

Le correctif resserre le problème au lieu de retirer le motif. L'analyse note que FileBrowserAllowedPaths est opt-in. Quand il n'est pas défini, le navigateur de fichiers continue de faire confiance aux chemins qu'un blob de dialogue valablement chiffré porte. Un adversaire détenant le DialogParametersEncryptionKey peut toujours envoyer des fichiers vers n'importe quel dossier du site. La section mitigation de l'éditeur va dans le même sens : les mesures réduisent le risque, seule la mise à niveau y répond entièrement. Renouvelez toute clé exposée lors de la mise à niveau, car c'est la clé, pas la version, que la seconde moitié exige.

Comment vérifier si j'ai été compromis ?

Aucun indicateur n'est publié, et l'éditeur indique que l'exploitation ne laisse aucune trace évidente dans les journaux d'erreurs ASP.NET standards. Ces vérifications cherchent les formes de requêtes de l'analyse publique dans vos propres journaux ; une correspondance est un élément à examiner, pas une preuve.

• Dans les journaux IIS, cherchez la signature en deux étapes : un POST vers une page avec RadImageEditor ou RadEditor suivi d'une requête vers Telerik.Web.UI.WebResource.axd portant type=iec et un paramètre dkey. L'édition d'images légitime utilise aussi ce handler : pondérez la paire, pas la requête seule.
• Cherchez les requêtes POST vers Telerik.Web.UI.DialogHandler.aspx depuis des sessions non authentifiées, l'endpoint de dialogue pour lequel le chemin RCE forge des paramètres.
• Comparez web.config et la racine web à une copie de référence : des fichiers .aspx inattendus, de nouveaux handlers ou des changements de machineKey sont les artefacts post-exploitation de l'analyse.
• Traitez les clés comme exposées sur tout site ayant exécuté une version vulnérable avec un machineKey statique ou un DialogParametersEncryptionKey personnalisé et ne pouvant pas écarter la lecture. Aucune empreinte ne distingue la lecture d'une image de celle de web.config dans les réponses du handler.

Chronologie

• 2026-07-28 : Tanto Security signale les résultats à Progress via son canal de divulgation sécurité, accusé de réception le jour même.
• 2026-07-31 : Progress fournit un build corrigé pour validation et revue.
• 2026-08-01 : Tanto Security confirme la correction de la lecture de fichiers et signale que l'envoi reste atteignable avec la clé de dialogue.
• 2026-08-12 : Progress publie la version corrigée, 2026.3.812 (2026 Q3), invitant les clients à mettre à niveau via le bulletin de sécurité critique.
• 2026-09-02 : Progress publie les CVE et les avis de la base de connaissances pour les deux failles.
• 2026-10-27 : Tanto Security publie l'analyse complète de la chaîne avec la séquence de requêtes.

FAQ

Le correctif est sorti en août 2026. Pourquoi est-ce important maintenant ?

La documentation publique de la chaîne est arrivée le 27 octobre 2026. Tout site encore en 2026.2.708 ou moins fait désormais face à une séquence de requêtes publiée, non authentifiée, qui lit web.config. L'analyse démontre la moitié exécution de code contre des sites avec les paramètres de clés recommandés. Les versions de la suite sont aussi difficiles à signaler par les scanners sans la version de fichier de l'assembly : l'inventaire compte.

Une installation par défaut est-elle exposée à l'exécution de code à distance ?

Non. La lecture de fichiers fonctionne sans authentification sur une installation par défaut, mais la moitié RCE exige un machineKey statique ou un DialogParametersEncryptionKey personnalisé dans web.config, qu'aucune installation par défaut ne contient. Progress recommande de les configurer, ce qui expose précisément à la chaîne un site qui a suivi les conseils de durcissement.

Quelqu'un a-t-il exploité ces failles ?

Aucune exploitation n'est connue. L'évaluation CISA ADP a enregistré Exploitation « none » pour les deux CVE le 2 septembre 2026, et aucun n'apparaît au catalogue Known Exploited Vulnerabilities du CISA au 3 novembre 2026. La ligne de produits a toutefois un historique d'exploitation : sa faille RadAsyncUpload CVE-2019-18935 figure dans ce catalogue depuis 2021.

Y a-t-il du code d'exploit public ?

L'analyse publie la séquence de requêtes complète de la lecture, charge utile d'état client et requête du handler de cache comprises, et décrit en entier les deux chemins d'exécution de code. Tanto Security a porté la génération du gadget ViewState dans son exploit, mais aucun script d'exploit autonome n'a été publié.

Les autres CVE Telerik de cette série comptent-ils ?

Les deux publications de la série ont rapporté douze vulnérabilités dans la suite, et Progress les a toutes corrigées au fil de 2026.2.708 et 2026.3.812. Ce billet couvre les deux CVE que Progress enchaîne en RCE non authentifiée, et la base de connaissances de l'éditeur porte un avis pour chacune des autres.

Puis-je bloquer les handlers au lieu de mettre à niveau ?

Vous pouvez réduire l'exposition ainsi, mais l'éditeur indique que filtrer la requête littérale n'est pas une mitigation complète confirmée. Des mappings de handler alternatifs, des encodages d'URL et un HttpHandlerUrl personnalisé peuvent contourner un filtre fondé sur une route. Utilisez les mesures provisoires de « Comment corriger ? » et validez tout contrôle de filtrage avec le support Telerik.

Cartographiez vos surfaces applicatives avec Ostorlab

Le Web Agentic Deep Scan d'Ostorlab parcourt vos applications web et cartographie les surfaces que leurs pages exposent, y compris les endpoints de handler et les dialogues que cette chaîne atteint. Lancez un scan avec Ostorlab pour savoir quelles applications prioriser pour la mise à niveau 2026.3.812.

Références

• Tanto Security, Marcio Almeida, « From Arbitrary File Read to Shell: Yet Another RCE in Telerik », publié le 27 octobre 2026, avec la chaîne complète, le code décompilé et la séquence de requêtes : https://tantosec.com/blog/2026/10/telerik-file-read-to-rce/ (vérifié le 3 novembre 2026)
• Avis Progress Telerik, « RadImageEditor Path Traversal Vulnerability (CVE-2026-18672) », avec la matrice des versions, l'absence de mitigation en configuration et la réserve sur le filtrage : https://www.telerik.com/products/aspnet-ajax/documentation/knowledge-base/kb-security-rie-path-traversal-cve-2026-18672 (vérifié le 3 novembre 2026)
• Avis Progress Telerik, « DialogHandler UploadPaths Tampering Vulnerability (CVE-2026-19219) », avec les conditions d'exposition, CWE-345 et CWE-434, et les mitigations provisoires : https://www.telerik.com/products/aspnet-ajax/documentation/knowledge-base/kb-security-dialoghandler-uploadpaths-tampering-cve-2026-19219 (vérifié le 3 novembre 2026)
• Progress Telerik, « Critical Security Bulletin - RadImageEditor and RadEditor CVE-2026-18672 and CVE-2026-19219 (2026 Q3) », l'impact de la chaîne et la matrice corrigée par composant : https://www.telerik.com/products/aspnet-ajax/documentation/knowledge-base/kb-security-radimageeditor-radeditor-rce-chain-bulletin-2026-q3 (vérifié le 3 novembre 2026)
• Enregistrement CVE-2026-18672, CNA Progress, avec CVSS v3.1 7.5 et le bloc SSVC du CISA ADP : https://www.cve.org/CVERecord?id=CVE-2026-18672 (vérifié le 3 novembre 2026)
• Enregistrement CVE-2026-19219, CNA Progress, avec CVSS v3.1 8.1 et le bloc SSVC du CISA ADP : https://www.cve.org/CVERecord?id=CVE-2026-19219 (vérifié le 3 novembre 2026)
• Vue d'ensemble des paramètres web.config Progress Telerik, le guide recommandant de configurer les clés de chiffrement : https://www.telerik.com/products/aspnet-ajax/documentation/general-information/web-config-settings-overview (vérifié le 3 novembre 2026)
• ysoserial.net, la boîte à outils de désérialisation .NET utilisée par l'analyse pour le gadget ViewState : https://github.com/pwntester/ysoserial.net (vérifié le 3 novembre 2026)
• Flux JSON du catalogue Known Exploited Vulnerabilities du CISA, recherché pour les deux CVE sans correspondance, et pour l'historique CVE-2019-18935 de la ligne de produits, au 3 novembre 2026 : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (vérifié le 3 novembre 2026)