Zinxhiri i shfrytëzimit të Telerik RadAsyncUpload lejon ekzekutim të kodit nga distanca

Studiuesit e sigurisë në TantoSec kanë publikuar një zinxhir të plotë shfrytëzimi për paketën e zhvillimit Telerik UI për ASP.NET AJAX që mund të lejojë një sulmues të paautentikuar të ekzekutojë kod arbitrar në një server pritës. Sulmi synon kontrollin e ngarkimit të skedarëve RadAsyncUpload, dhe Progress Software, që zotëron Telerik, rregulloi dobësitë themelore në versionin 2026.2.708 më 8 korrik. Publikimi publik më 7 shtator përfshin një përshkrim të detajuar teknik, një mjet të linjës së komandës të quajtur telerik-rau-exploit, dhe dy skedarë payload, duke vënë një rrugë të plotë sulmi në duart e publikut për herë të parë. Megjithatë, zinxhiri funksionon vetëm kundër aplikacioneve që plotësojnë dy kushte specifike jo të paracaktuara, dhe nuk ka raportime të konfirmuara për shfrytëzim aktiv në natyrë që nga 7 shtatori.

Versionet e prekura janë 2010.1.309 deri në 2026.2.519, sipas njoftimit të Progress. Thjesht ekzekutimi i një versioni të prekur nuk mjafton për t'u bërë i shfrytëzueshëm. TantoSec thotë se zinxhiri ka parakushte që nuk plotësohen nga një instalim i paracaktuar. Së pari, një faqe duhet të shfaqë një kontroll RadAsyncUpload, trajtuesi i të cilit në anën e serverit lexon rezultatin e ngarkimit. Së dyti, aplikacioni duhet të konfigurohet me një çelës enkriptimi të qartë, jo të paracaktuar, për kontrollin. Ky kusht i dytë është i papërshtatshëm sepse Telerik në fakt rekomandon vendosjen e një çelësi personalizuar enkriptimi si masë forcimi, duke nënkuptuar se disa konfigurime me qëllim të mirë mund të jenë të prekshme. Kur të dyja kushtet janë të pranishme, shpërblimi është ekzekutimi i kodit me privilegjet e grupit të aplikacioneve IIS, që është pjesa e softuerit të serverit web të Microsoft që ekzekuton kodin e faqes.

Pika e hyrjes është një orakull i mbushjes, i gjurmuar si CVE-2026-13182. Kontrolli enkripton gjendjen e tij në anën e klientit duke përdorur AES-CBC, një metodë e zakonshme enkriptimi, por nuk shton një kontroll integriteti. Si rezultat, serveri përgjigjet ndryshe ndaj të dhënave të manipuluara në varësi të faktit nëse bajtet e deshifruara kanë mbushje të vlefshme ose thjesht dështojnë të analizohen si JSON. Një sulmues mund ta përdorë këtë ndryshim për të deshifruar konfigurimin e ngarkimit dhe, duke përdorur një teknikë që TantoSec ndërtoi rreth farës fikse të enkriptimit të kontrollit, ta falsifikojë atë pa mësuar kurrë çelësin e enkriptimit. Konfigurimi i falsifikuar më pas i lejon sulmuesit të emërojë një lloj arbitrar .NET. Për shkak se kontrolli e zgjidh atë lloj pa një listë të lejuar, dobësia CVE-2026-13181 mban një rezultat CVSS prej 8.1, që është në rangun e lartë të ashpërsisë. Lloji i zgjidhur deserializohet në një gadget që ngarkon një DLL nga një vendndodhje që kontrollon sulmuesi. Ai DLL i ngarkuar është një asamble me modalitet të përzier, që do të thotë se përmban si kod të menaxhuar .NET ashtu edhe kod amë makine, dhe ekzekuton kodin amë sapo të ngarkohet.

Demonstrimi nga fillimi në fund i TantoSec mori afërsisht 127,000 kërkesa orakulli, që zgjati rreth një orë kundër një objektivi laboratori dhe më shumë kundër një serveri me kufizim shpejtësie. Nëse aplikacioni fsheh mesazhet e detajuara të gabimit, orakulli i mbushjes mund të lexohet ende përmes kohës së përgjigjes, një variant i gjurmuar si CVE-2026-13183. Dy payload-et e publikuara tregojnë qëllime të ndryshme: njëri shkruan një guaskë web në disk, dhe tjetri ekzekutohet tërësisht në memorie. Një guaskë web është një skedar i vogël i vendosur në një server që i jep sulmuesit një panel kontrolli përmes shfletuesit. Versioni në memorie nuk lë asnjë skedar pas në atë vendndodhje.

Progress nuk ka parë raportime të konfirmuara për shfrytëzimin e këtyre dobësive të vitit 2026 në natyrë, dhe asnjë nuk shfaqet në katalogun e Dobësive të Njohura të Shfrytëzuara të Agjencisë së Sigurisë Kibernetike dhe Infrastrukturës së SHBA-së që nga 7 shtatori. Një shitës i menaxhimit të sipërfaqes së sulmit, IONIX, deklaron në faqen e tij se po gjurmon përpjekje të vazhdueshme shfrytëzimi, por nuk jep data, vëllime ose detaje të tjera dhe nuk bën dallim midis shfrytëzimit dhe skanimit të zakonshëm të internetit të trajtuesit. Komponenti në vetvete ka një histori të gjatë sulmesh në botën reale, por përmes defekteve më të vjetra, jo këtyre. Një defekt deserializimi i vitit 2019 në të njëjtin trajtues, CVE-2019-18935, u lidh me një dobësi enkriptimi të vitit 2017 dhe u shfrytëzua nga grupet e ransomware dhe aktorët shtetërorë, duke përfshirë një shkelje të vitit 2022 të një agjencie federale të SHBA-së, dhe ishte ende duke u shfrytëzuar deri në vitin 2025. Kjo histori është arsyeja pse një rrugë e ekzekutimit të kodit pa vërtetim në këtë trajtues tërheq vëmendje, edhe pse dobësitë e reja nuk kanë shfrytëzim të konfirmuar.

Buletini i korrikut i Progress në fakt mbulon dy zinxhirë të veçantë sulmi. Zinxhiri RadAsyncUpload që TantoSec detajoi është njëri. Tjetri është një zinxhir i veçantë i ekzekutimit të kodit nga distanca në komponentët RadPersistenceManager dhe RadDockLayout, i gjurmuar si CVE-2026-13185, CVE-2026-13186 dhe CVE-2026-13190, i kredituar Markus Wulftange nga CODE WHITE dhe Progress. Asnjë shfrytëzim publik nuk është lëshuar për atë zinxhir të dytë. Brenda zinxhirit RadAsyncUpload, një defekt i katërt që përfshin një çelës të parashikueshëm të paracaktuar, CVE-2026-13184, vlen vetëm për një mënyrë alternative sulmi që demonstrimi i publikuar nuk e përdori.

Rregullimi kryesor është përmirësimi në Telerik UI për ASP.NET AJAX 2026.2.708 (2026 Q2 SP1) ose më vonë, i cili zëvendëson skemën e dëmtuar AES-CBC me enkriptim të vërtetuar dhe mbyll të gjithë zinxhirin. Progress e quan përmirësimin rekomandimin e tij të vetëm zyrtar dhe paralajmëron se një çelës më i fortë personalizuar nuk ndihmon, sepse orakulli nuk ka nevojë kurrë për çelësin. Për faqet që nuk mund të përmirësohen menjëherë, Progress rendit disa hapa të ndërmjetëm. Vendosja e customErrors në RemoteOnly ose On e detyron sulmuesin në variantin më të ngadaltë të bazuar në kohë. Çaktivizimi i plotë i trajtuesit të ngarkimit duke vendosur Telerik.Web.DisableAsyncUploadHandler në true është i përshtatshëm nëse RadAsyncUpload nuk kërkohet. Heqja e çdo çelësi personalizuar enkriptimi e bën kontrollin të bjerë në çelësin e makinës ASP.NET me AES dhe HMAC, ose administratorët mund të gjenerojnë çelësa të fortë makine manualisht në vend që t'i lënë serverit t'i hamendësojë.

Për shkak se shfrytëzimi i suksesshëm nuk lë gjurmë të dukshme në regjistrat standardë të gabimeve ASP.NET, mbrojtësit duhet të gjuajnë në mënyrë të sjelljes dhe jo për shenja gabimi. Kjo do të thotë të kërkojnë për procesin e punës IIS (w3wp.exe) që nis cmd.exe, një skedar i ri ose i papritur .aspx në rrënjën e web-it, ose një DLL me modalitet të përzier të shkruar në dosjen e përkohshme të kontrollit të ngarkimit ose në App_Data.

Për organizatat që ekzekutojnë aplikacione më të vjetra .NET web, një partner IT dhe konsulence i fokusuar në siguri si AEU-I mund të ndihmojë në inventarizimin e kontrolleve të prekura Telerik dhe planifikimin e një përmirësimi të sigurt, por patch-i zyrtar i Progress mbetet i vetmi rregullim i plotë.

TantoSec i raportoi çështjet Progress më 22 maj; rregullimi u dërgua më 8 korrik, dhe CVE-të pasuan më 22 korrik. Almeida i kreditoi kolegun Justin Steven për variantin e orakullit të kohës.