Falha no Telerik UI permite RCE sem autenticação; exploit público é divulgado

7 de Setembro de 2026

Uma prova de conceito da TantoSec transforma uma *padding oracle* em AES-CBC no Telerik UI for ASP.NET AJAX em execução remota de código sem autenticação, mas apenas contra aplicações em uma configuração específica e fora do padrão. A Progress corrigiu a cadeia em julho, e não há relatos confirmados de exploração em ambiente real.

A empresa de segurança TantoSec publicou uma cadeia de exploração funcional que mira vulnerabilidades no Telerik UI for ASP.NET AJAX e pode permitir que um atacante sem autenticação execute código remoto no servidor que hospeda a aplicação vulnerável.

A Progress Software corrigiu as falhas em julho, e a exploração exige uma configuração fora do padrão. Ainda assim, a divulgação veio acompanhada de uma análise detalhada, uma ferramenta pronta para uso e dois payloads, colocando pela primeira vez em mãos públicas um caminho completo de ataque.

As falhas de base não são novas. A Progress disponibilizou a correção na versão 2026.2.708 (2026 Q2 SP1) em 8 de julho e publicou os CVEs e o comunicado em 22 de julho.

O que mudou em 7 de setembro foi a divulgação do método e das ferramentas. Marcio Almeida, da TantoSec, detalhou a cadeia completa e liberou a ferramenta de linha de comando telerik-rau-exploit, além de dois payloads DLL em modo misto, um que grava uma web shell em disco e outro que executa tudo inteiramente em memória.

A cadeia afeta o controle de upload de arquivos RadAsyncUpload nas versões de 2010.1.309 até 2026.2.519, segundo o comunicado da Progress. A partir da 2026.2.708, a falha está corrigida.

A mais grave das falhas, uma fraqueza de resolução de tipo sem proteção, rastreada como CVE-2026-13181 , recebeu nota CVSS 8.1 e foi classificada como alta. O nível de complexidade alto reflete os pré-requisitos de configuração descritos abaixo, e não uma dificuldade real de exploração depois que essas condições são atendidas.

Executar uma versão afetada não basta para tornar o sistema explorável. A TantoSec afirma que a cadeia tem “pré-condições que não são atendidas por uma instalação padrão”: é preciso que uma página renderize um controle RadAsyncUpload cujo handler no servidor leia o resultado do upload, e que a aplicação esteja configurada com uma chave de criptografia explícita e fora do padrão para esse controle. Em um paradoxo, trata-se de uma configuração que a própria Telerik recomenda como medida de fortalecimento. Sites em versão afetada que não cumpram as duas condições não são exploráveis por essa cadeia.

Quando esses requisitos estão presentes, o resultado é execução de código com os privilégios do pool de aplicativos do IIS. O ponto de entrada é uma *padding oracle* ( CVE-2026-13182 ). Como o controle criptografa seu estado do lado do cliente com AES-CBC e sem verificação de integridade, o servidor responde de forma diferente a dados adulterados, dependendo de os bytes descriptografados terem *padding* válido ou apenas falharem ao serem interpretados como JSON.

Essa diferença permite que um atacante decripte e, com uma técnica desenvolvida pela TantoSec com base na semente fixa de criptografia do controle, falsifique a configuração criptografada do upload sem nunca conhecer a chave.

A mesma falsificação permite ao atacante informar um tipo arbitrário de .NET, que o controle resolve sem lista de permissões na CVE-2026-13181 , e desserializa em um gadget que carrega uma DLL de um local sob controle do invasor.

A DLL enviada é um assembly em modo misto que executa código nativo assim que é carregada. O processo não é instantâneo. A execução ponta a ponta da TantoSec levou cerca de 127.000 requisições à *oracle*, algo em torno de uma hora contra um alvo de laboratório e mais tempo contra um servidor com limitação de taxa.

Se a aplicação ocultar mensagens detalhadas de erro, a *oracle* ainda pode ser observada pelo tempo de resposta, em uma variante rastreada como CVE-2026-13183 .

Não há relatos confirmados de exploração das falhas de 2026 em ambiente real, e nenhuma delas aparece no catálogo Known Exploited Vulnerabilities da CISA até 7 de setembro.

Um fornecedor de gestão de superfície de ataque, a IONIX, afirma em seu site que está “monitorando tentativas contínuas de exploração”, mas não informa datas, volumes nem outros detalhes, além de não distinguir exploração de simples varreduras de internet no handler.

O componente, no entanto, tem histórico longo de ataques reais, ainda que por meio de falhas antigas, e não destas novas. Uma falha de desserialização de 2019 no mesmo handler, CVE-2019-18935 , foi combinada com uma fraqueza de criptografia de 2017 e explorada por grupos de ransomware e atores estatais, inclusive em uma invasão de 2022 contra uma agência federal dos Estados Unidos. Casos de exploração ainda foram registrados em 2025.

Esse histórico explica por que um caminho de execução de código sem autenticação nesse handler chama atenção, mesmo sem confirmação de exploração das novas falhas.

Há ainda dois pontos importantes. O comunicado de julho da Progress cobre, na verdade, duas cadeias de ataque separadas: a cadeia do RadAsyncUpload detalhada pela TantoSec e uma cadeia distinta de execução remota de código nos componentes RadPersistenceManager e RadDockLayout, rastreada como CVE-2026-13185 , CVE-2026-13186 e CVE-2026-13190, atribuída a Markus Wulftange, da CODE WHITE, e à Progress, para a qual não foi divulgado exploit público.

Além disso, dentro da cadeia do RadAsyncUpload, uma quarta falha envolvendo uma chave padrão previsível, CVE-2026-13184 , só se aplica a um modo alternativo de ataque que a demonstração divulgada não utilizou.

O que fazer

Atualize para o Telerik UI for ASP.NET AJAX 2026.2.708 (2026 Q2 SP1) ou posterior. Essa versão substitui o esquema falho de AES-CBC por criptografia autenticada e encerra toda a cadeia.

A Progress diz que a atualização é sua única recomendação oficial e alerta que uma chave personalizada mais forte não ajuda, porque a *oracle* nunca precisa da chave.

Para sites que não podem ser atualizados imediatamente, a Progress sugere algumas medidas temporárias:

Definir customErrors como RemoteOnly ou On, o que força o atacante a usar a variante mais lenta baseada em tempo.
Desativar totalmente o handler de upload, com Telerik.Web.DisableAsyncUploadHandler definido como true, se o RadAsyncUpload não for necessário.
Remover qualquer chave de criptografia personalizada para que o controle volte a usar a machine key do ASP.NET com AES e HMAC, ou gerar machine keys fortes manualmente, em vez de criá-las em tempo de execução.

Como a Progress alerta que uma exploração bem-sucedida “não deixa vestígios óbvios nos logs de erro padrão do ASP.NET”, as equipes de defesa devem buscar sinais comportamentais, e não assinaturas de erro: o processo de trabalho do IIS (w3wp.exe) iniciando cmd.exe, um novo arquivo .aspx inesperado na raiz da aplicação web, ou uma DLL em modo misto gravada na pasta temporária do controle de upload ou em App_Data.

A TantoSec informou os problemas à Progress em 22 de maio. A correção saiu em 8 de julho, e os CVEs foram publicados em 22 de julho. Almeida atribuiu a variante de *timing oracle* ao colega Justin Steven.

Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...