Cadeia de falhas no Telerik transforma padding oracle em RCE sem login — 4 CVEs, versões desde 2010

Introdução

Uma cadeia de quatro vulnerabilidades no Telerik (fornecedora de componentes de interface para .NET) UI for ASP.NET AJAX — mais especificamente no componente RadAsyncUpload (componente de upload de arquivos do Telerik) — permite que um atacante remoto, sem autenticação, transforme uma falha criptográfica em execução de código no servidor IIS (servidor web da Microsoft). A cadeia foi divulgada em 07/09/2026 pela Cyber Security News, com PoC público assinado pelo pesquisador TantoSec, e afeta todas as versões de 2010.1.309 até 2026.2.519 — dezesseis anos de instalações. A correção foi liberada pela Progress Software (empresa de software, dona do Telerik) na versão 2026.2.708 (Q2 SP1).

A gravidade vem da combinação dos elos: nenhuma credencial é necessária, e o resultado final é um web shell (arquivo colocado no servidor que dá acesso remoto pela web) rodando dentro do processo de trabalho do IIS. No centro da história está uma ironia de engenharia: a chave de criptografia recomendada pelo próprio fornecedor para "proteger" o estado do upload é exatamente o que transforma a cadeia em um vetor de execução remota.

Contexto: por que isso importa

O Telerik UI for ASP.NET AJAX está em produção há mais de quinze anos em aplicações WebForms (plataforma web da Microsoft para a linguagem .NET) — ERPs, portais de governo, sistemas bancários e intranets corporativas, no Brasil e no mundo. O RadAsyncUpload, componente de upload assíncrono de arquivos, é onipresente nesse tipo de aplicação: formulários de documentos, anexos, importação de planilhas. Uma falha nele não atinge apenas sites marginais — atinge a espinha dorsal de sistemas legados que muitas vezes já passaram por dezenas de ciclos de manutenção.

Não é a primeira vez que esse componente vira alvo. O RadAsyncUpload já foi o ponto de entrada de cadeias graves de RCE no passado: o CVE-2017-11317 e o famoso CVE-2019-18935, ambos explorados em ataques reais contra servidores com Telerik UI, usavam desserialização insegura no mesmo fluxo de upload. O precedente histórico faz com que administradores experientes tratem qualquer aviso envolvendo o componente com prioridade máxima — e desta vez o ataque é mais sofisticado: ele começa onde as versões anteriores terminavam, na criptografia do estado do cliente.

A cadeia de exploração: do estado cifrado ao web shell

A exploração combina duas falhas independentes em uma única cadeia de sete estágios, começando pelo estado cifrado que a aplicação devolve ao navegador e terminando em um web shell no processo do IIS. Abaixo apresentamos o diagrama da cadeia e detalhamos cada estágio em seguida.

O oráculo dentro do upload (CVE-2026-13182)

O primeiro elo é um padding oracle (oráculo de preenchimento: comportamento que revela, pelas respostas de erro, se o preenchimento de um bloco cifrado está correto) no estado cifrado do componente. Para manter a configuração de upload — incluindo a lista de extensões permitidas — o RadAsyncUpload serializa esse estado e o cifra com AES-CBC (modo de operação em cadeia da cifra de blocos AES, no qual cada bloco cifrado se mistura ao próximo antes da cifragem), usando uma chave do servidor.

O problema está no que acontece quando o servidor tenta decifrar um valor adulterado: as respostas de erro são distintas conforme o motivo da falha — preenchimento inválido, formato corrompido, conteúdo inesperado. Essa diferença sutil é o oráculo. Um atacante que manipula o estado cifrado e observa qual erro o servidor devolve consegue, sem conhecer a chave, recuperar o conteúdo cifrado byte a byte — técnica clássica de ataque de padding oracle, descrita por Serge Vaudenay em 2002 e presente em incontáveis CTFs. No Telerik, o oráculo vaza o suficiente para o passo seguinte, muito mais grave.

Forjando a configuração sem a chave

Com o oráculo em mãos, o atacante não precisa se limitar a ler: ele pode forjar valores cifrados arbitrários. A técnica é conhecida como CBC forgery — montagem de blocos cifrados que, ao serem decifrados pelo servidor, produzem exatamente o valor escolhido pelo atacante. Para isso, um bloco anterior é deliberadamente corrompido e vira o bloco sacrificial (bloco cujo conteúdo decifrado vira lixo, "absorvendo" a manipulação para permitir controlar os blocos seguintes) — o servidor ignora o lixo desse bloco e processa o resto do estado.

O alvo da forja é a configuração de upload: o atacante altera o campo AllowedFileExtensions para liberar arquivos .dll — que antes eram bloqueados pela própria lista. A lição técnica aqui é direta: criptografar o estado do cliente não é autenticá-lo. A chave esconde o conteúdo, mas não prova que ele foi escrito pelo servidor — e, com um oráculo, nem esconde.

O gadget que instala a DLL (CVE-2026-13181)

O segundo elo mora no processamento do resultado do upload: a resolução de tipo .NET usada pelo componente, controlada pelo campo AsyncUploadTypeName, é feita sem allowlist (lista de permissões) — o servidor aceita qualquer nome de tipo. Isso abre uma porta para desserialização insegura (reconstrução de objetos a partir de dados serializados, como XML ou binário, sem validar o que está sendo reconstruído).

O atacante encadeia uma gadget chain — sequência de trechos de código legítimos da própria aplicação que, executados durante a desserialização, produzem um efeito arbitrário — que termina na classe System.Configuration.Install.AssemblyInstaller, um instalador de assemblies do .NET. A DLL enviada no upload é um assembly mixed-mode (arquivo que combina código gerenciado e código nativo no mesmo binário): no momento em que o AssemblyInstaller a carrega, o Windows executa a função DllMain (ponto de entrada executado automaticamente quando uma DLL é carregada em um processo), e é ali que o código nativo do atacante roda — sem precisar "executar" a DLL como um programa.

O resultado é execução arbitrária de código dentro do w3wp.exe (processo de trabalho do IIS, onde a aplicação ASP.NET roda) — o suficiente para gravar um web shell em disco ou, em uma variante mais furtiva, manter tudo in-memory, sem arquivos no sistema de arquivos.

Requisitos e a nota honesta

A cadeia não é incondicional: exige uma página que use o RadAsyncUpload com um handler FileUploaded que leia o UploadResult, e a chave Telerik.AsyncUpload.ConfigurationEncryptionKey configurada no web.config — a mesma chave que a documentação do fornecedor recomendava como proteção.

Nota honesta. Até a publicação desta matéria, não há relato confirmado de exploração da cadeia em ataques reais. A mecânica detalhada vem da análise de pesquisadores — com destaque para o PoC público publicado pelo TantoSec — e a exploração depende dos requisitos de configuração descritos acima. O risco é real, mas a probabilidade de uma instalação específica ser atingida depende de atender a esses pré-requisitos; a correção já está disponível e deve ser aplicada com urgência.

O conjunto completo de falhas corrigidas no Q2 SP1:

CVE	Componente	Tipo	Efeito
CVE-2026-13181	RadAsyncUpload — AsyncUploadTypeName	Desserialização insegura	Resolução de tipo .NET sem allowlist + gadget AssemblyInstaller → execução de código
CVE-2026-13182	RadAsyncUpload — estado cifrado	Padding oracle	Recuperação e forja do estado cifrado AES-CBC sem a chave
CVE-2026-13183	RadAsyncUpload	—	Falha adicional corrigida no Q2 SP1
CVE-2026-13184	RadAsyncUpload	—	Falha adicional corrigida no Q2 SP1

Como se proteger

Atualize para o Q2 SP1 (2026.2.708). Este é o passo inadiável: todas as versões de 2010.1.309 até 2026.2.519 são afetadas, e a correção já está disponível no portal da Progress e via NuGet. Antes de atualizar em produção, valide a compatibilidade do pacote com a aplicação — mas não adie a atualização esperando "o momento certo": a existência de PoC público significa que a janela entre divulgação e exploração em massa tende a ser curta.

Rotacione a chave de configuração. Se a aplicação usa a chave Telerik.AsyncUpload.ConfigurationEncryptionKey, troque-a após atualizar — qualquer estado cifrado antigo forjado ou vazado antes do patch perde validade. Se o componente não depende do estado cifrado, avalie com a documentação oficial se a chave é necessária: removê-la, quando o recurso não é usado, elimina o próprio oráculo.

Valide as extensões no servidor, não no cliente. A lista AllowedFileExtensions viaja cifrada no estado do cliente e, como esta cadeia demonstra, pode ser forjada. Reforce o handler FileUploaded com uma allowlist de extensões verificada no servidor, independente do que chega cifrado — e bloqueie explicitamente .dll, .exe e .aspx no fluxo final de gravação.

Monitore o IIS em busca de sinais de web shell. Procure processos filhos de w3wp.exe (cmd.exe, powershell.exe), DLLs recém-criadas em diretórios temporários ou App_Data e arquivos .aspx fora do esperado em disco. Para análise estática de binários suspeitos, o pestudio (ferramenta de análise estática de arquivos executáveis) ajuda a inspecionar DLLs sem executá-las; um SIEM como o Wazuh (plataforma open source de monitoramento e detecção) correlaciona criação de processos e de arquivos em escala. Lembre-se de que cadeias desse tipo costumam terminar com a implantação de um segundo estágio — RATs e infostealers como o XWORM — então investigue downloads e execuções posteriores ao incidente.

Rode a aplicação com o mínimo de privilégios. A identidade do pool de aplicações do IIS deve ter apenas as permissões estritamente necessárias, limitando o que um web shell pode fazer mesmo após a exploração. Considere também regras de WAF para o handler de upload e segmente a aplicação web de outros sistemas internos, para conter o movimento lateral.

Conclusão

A cadeia do Telerik combina dois clássicos da engenharia de segurança em uma única história: um ataque de padding oracle, conhecido há mais de duas décadas, e a desserialização insegura, o calcanhar de aquiles das plataformas .NET. O que torna o caso emblemático é a ironia estrutural — a criptografia recomendada como proteção virou o vetor — e o alcance: dezesseis anos de versões afetadas, em um componente presente em sistemas legados que raramente recebem atenção. A lição maior é dupla: criptografar o estado do cliente nunca é autenticá-lo, e dependências antigas cobram juros compostos quando ignoradas. Atualizar para o Q2 SP1, rotacionar chaves e monitorar o IIS são as três ações que separam uma aplicação corrigida de uma porta aberta.

Perguntas frequentes

O que é um ataque de padding oracle?

É uma técnica de criptoanálise em que o atacante explora respostas de erro distintas do servidor para descobrir se o preenchimento (padding) de um bloco cifrado está correto. Com essa informação, é possível recuperar o conteúdo cifrado byte a byte e, em alguns casos, forjar valores cifrados arbitrários — tudo sem conhecer a chave.

O que significa "forjar um valor cifrado" e o que é o bloco sacrificial?

Forjar um valor cifrado é construir um texto cifrado que, ao ser decifrado pelo servidor, produz exatamente o conteúdo escolhido pelo atacante. No modo CBC, isso é feito corrompendo um bloco anterior da cadeia para "absorver" a manipulação — esse bloco é o sacrificial, pois seu conteúdo decifrado vira lixo ignorado pelo servidor.

Quais versões do Telerik UI for ASP.NET AJAX são afetadas?

Todas as versões de 2010.1.309 até 2026.2.519, incluindo dezesseis anos de releases. A correção foi liberada na versão 2026.2.708 (Q2 SP1) e deve ser aplicada com urgência.

Meu site só é vulnerável se eu tiver configurado a chave Telerik.AsyncUpload.ConfigurationEncryptionKey?

Sim. A cadeia depende de uma página com RadAsyncUpload cujo handler FileUploaded leia o UploadResult e da chave de configuração presente no web.config. A ironia é que essa chave era recomendada pela própria documentação como proteção — e acabou se tornando o requisito do vetor.

A exploração já foi vista em ataques reais?

Não há relato confirmado de exploração em campo até a publicação desta matéria. Existe um PoC público do pesquisador TantoSec demonstrando a cadeia, e a mecânica foi detalhada pela Cyber Security News — o que historicamente antecede campanhas em larga escala.

O que é desserialização insegura e por que o AssemblyInstaller é perigoso?

Desserialização insegura é a reconstrução de objetos a partir de dados sem validar o que está sendo reconstruído. No .NET, certas classes executam ações durante a reconstrução — e a classe System.Configuration.Install.AssemblyInstaller, usada para instalar assemblies, pode carregar e executar uma DLL fornecida pelo atacante, disparando o código nativo dela via DllMain.

Como detecto um web shell deixado por esse ataque no IIS?

Procure processos filhos de w3wp.exe (cmd.exe, powershell.exe), DLLs recém-criadas em diretórios temporários ou App_Data e arquivos .aspx inesperados em disco. Ferramentas como pestudio ajudam na análise estática dos binários suspeitos, e um SIEM como o Wazuh correlaciona os eventos de criação de processos e arquivos.

O que devo fazer se suspeitar que fui comprometido?

Isole o servidor da rede, preserve logs e evidências e procure por web shells e contas ou processos anormais. Depois, atualize o componente, rotacione a chave de configuração e todas as credenciais do ambiente, e investigue movimentação lateral — inclusive a implantação de segundo estágio, como RATs e infostealers.

Fontes e leituras adicionais

• Cyber Security News — Telerik Flaw Chain Lets Unauthenticated Attackers Turn Padding Oracle Into Remote Code Execution — 07/09/2026
• TantoSec — Telerik Padding Oracle to Shell — 07/09/2026
• NVD — CVE-2026-13181 — 07/09/2026
• NVD — CVE-2026-13182 — 07/09/2026
• NVD — CVE-2026-13183 — 07/09/2026
• NVD — CVE-2026-13184 — 07/09/2026