Концептуално доказателство (PoC) от TantoSec превръща AES-CBC „padding oracle“ уязвимост в Telerik UI for ASP.NET AJAX в неавтентикирано отдалечено изпълнение на код (RCE) — но само срещу приложения със специфична нефабрична конфигурация, като Progress вече отстрани уязвимостта през юли. Няма потвърдени данни за злонамерено използване на уязвимостта.

Компанията за киберсигурност TantoSec публикува работеща верига от експлойти, насочена към уязвимости в Telerik UI for ASP.NET AJAX, която може да позволи на неавтентикиран атакуващ да изпълни отдалечен код върху сървъра, хостващ засегнатото приложение.

Progress Software отстрани уязвимостите през юли, а за тяхната експлоатация е необходима нефабрична конфигурация — но публикуваната информация комбинира подробен технически анализ с готов за използване инструмент и два зловредни кода (payloads), предоставяйки за първи път пълния път за атака в публичното пространство.

Основно заложените дефекти не са нови. Progress пусна коригираща версия 2026.2.708 (2026 Q2 SP1) на 8 юли и публикува съответните CVE и бюлетин за сигурност на 22 юли.

Това, което се промени на 7 септември, е разкриването на метода и инструментите: Марсио Алмейда от TantoSec премина през цялата верига и пусна инструмент за команден ред, telerik-rau-exploit, заедно с два смесени DLL зловредни кода — единият записва уеб шел на диска, а другият работи изцяло в паметта.

Веригата засяга компонента за качване на файлове RadAsyncUpload във версии от 2010.1.309 до 2026.2.519 според официалния бюлетин на Progress; версии 2026.2.708 и по-нови са коригирани.

Най-сериозната от грешките — незащитен дефект при дефинирането на типове (type-resolution flaw), проследяван като CVE-2026-13181, има CVSS оценка 8.1 („висока“); нейната висока сложност на атаката (attack complexity) отразява необходимите предварителни конфигурационни условия, описани по-долу, а не трудността на самата експлоатация, след като те са налице.

Използването на засегната версия сама по себе си не е достатъчно за успешна атака. TantoSec отбелязва, че веригата има „предварителни условия, които не са изпълнени при стандартна инсталация“: дадена страница трябва да визуализира контрола RadAsyncUpload, чийто сървърен обработчик чете резултата от качването, и приложението трябва да е конфигурирано с изричен, нефабричен ключ за шифроване за тази контрола — което, парадоксално, е настройка, препоръчвана от Telerik с цел повишаване на сигурността. Сайтове със засегната версия, при които липсват тези две условия, не са уязвими чрез тази верига.

Когато тези условия са налице, резултатът за атакуващия е изпълнение на код с правата на приложението в IIS (application pool). Входната точка е padding oracle уязвимост (CVE-2026-13182): тъй като контролата шифрова клиентското си състояние с AES-CBC без проверка за интегритет, сървърът отговаря различно при манипулирани данни в зависимост от това дали дешифрованите байти имат валиден padding или просто не могат да бъдат парсирани като JSON.

Тази разлика позволява на киберпрестъпника да дешифрова — и чрез техника, разработена от TantoSec около фиксирания генератор на шифровъчни ключове на контролата, да фалшифицира — шифрованата конфигурация за качване, без да разполага с самия ключ.

Същата подправка позволява на атакуващия да посочи произволен .NET тип, който контролата зарежда без списък с разрешени типове (CVE-2026-13181) и десериализира в механизъм (gadget), който зарежда DLL файл от локация под контрола на киберпрестъпника.

Каченият DLL файл е сборка със смесен режим (mixed-mode assembly), която изпълнява нативен код веднага след зареждането си. Процесът не е мигновен: пълният цикъл на експлоайта на TantoSec изисква приблизително 127 000 oracle заявки — около един час срещу тестова среда и по-дълго срещу сървър с ограничение на броя заявки (rate-limiting).

Ако приложението крие подробните съобщения за грешка, уязвимостта oracle все пак може да бъде експлоатирана чрез измерване на времето за реакция (response timing) — вариант, проследяван като CVE-2026-13183.

Няма потвърдени доклади за злонамерени атаки, използващи тези уязвимости от 2026 г., и нито една от тях не фигурира в каталога Known Exploited Vulnerabilities на CISA към 7 септември.

Един доставчик на системи за управление на повърхността за атаки (IONIX) посочва на сайта си, че „проследява текущи опити за експлоатация“, но не предоставя дати, обем или други подробности и не прави разлика между реална експлоатация и обикновено сканиране на обработчика в интернет.

Самият компонент има дълга история на реални кибератаки — но чрез по-стари грешки, а не тези. Уязвимост за десериализация от 2019 г. в същия обработчик (CVE-2019-18935) беше комбинирана със слабост в шифроването от 2017 г. и използвана от групи за рансъмуер и държавно финансирани хакери, включително при пробив във федерална агенция на САЩ през 2022 г., като продължава да се експлоатира дори през 2025 г.

Именно тази история е причината възможността за неавтентикирано изпълнение на код в този обработчик да привлече такова внимание, въпреки че за новите грешки няма потвърдени данни за използване с злонамерена цел.

Още две подробности допълват картина. Бюлетинът на Progress от юли всъщност покрива две отделни вериги от атаки: веригата RadAsyncUpload, описана подробно от TantoSec, и отделна верига за отдалечено изпълнение на код в компонентите RadPersistenceManager и RadDockLayout (CVE-2026-13185, -13186 и -13190), открита от Маркус Вулфтанге от CODE WHITE и Progress, за която не е публикуван публичен експлойт.

В рамките на веригата RadAsyncUpload четвърта уязвимост, свързана с предвидим фабричен ключ (CVE-2026-13184), се прилага само за алтернативен режим на атака, който публикуваната демонстрация не използва.

Какво да предприемете

Обновете до Telerik UI for ASP.NET AJAX 2026.2.708 (2026 Q2 SP1) или по-нова версия, която заменя дефектната AES-CBC схема с автентикирано шифроване и блокира цялата верига за атака.

Progress посочва, че инсталирането на обновяването е единствената официална препоръка и предупреждава, че използването на по-силен персонализиран ключ не помага, тъй като атаката oracle никога не се нуждае от самия ключ.

За сайтове, които не могат да инсталират корекции за сигурност веднага, Progress препоръчва няколко временни стъпки:

  • Задайте customErrors на RemoteOnly или On, което принуждава атакуващия да използва по-бавния вариант, базиран на измерване на времето.
  • Дективирайте напълно обработчика за качване (Telerik.Web.DisableAsyncUploadHandler зададено на true), ако RadAsyncUpload не се изисква.
  • Премахнете всички персонализирани ключове за шифроване, така че контролата да превключи към използване на ключа на машината в ASP.NET (machine key) с AES и HMAC, или генерирайте ръчно силни machine keys вместо по време на изпълнение.

Тъй като Progress предупреждава, че успешната експлоатация „не оставя явни следи в стандартните дневници за грешки на ASP.NET“, екипите по защита трябва да следят за подозрително поведение, а не за следи от грешки: работният процес на IIS (w3wp.exe), стартиращ cmd.exe, нов или неочакван .aspx файл в главната директория на уеб сайта, или смесен DLL файл, записан във временната папка на контролата за качване или в App_Data.

TantoSec съобщи за проблемите на Progress на 22 май; коригиращата версия беше доставена на 8 юли, а CVE идентификаторите бяха публикувани на 22 юли. Алмейда благодари на своя колега Джъстин Стивън за разкриването на варианта timing-oracle.