Falha no apache struts permite execução remota de código em mapeador legado

3 минут чтения

Falha no Apache Struts pode permitir execução remota de código em mapeador legado

O Apache Struts corrigiu quatro vulnerabilidades, incluindo uma falha de injeção OGNL capaz de permitir execução remota de código sem autenticação. Identificada como CVE-2026-104711, a brecha depende de uma condição específica: a aplicação precisa estar configurada para usar o antigo mapeador RESTful do framework.

O risco, portanto, não se aplica automaticamente a todos os sistemas que utilizam Struts. Aplicações que recorrem ao mapeador padrão, ao `restful2` ou ao plugin REST do próprio framework não são afetadas por essa vulnerabilidade. Na série 7.x, o problema também exige que a lista de permissões do OGNL esteja desativada.

O mapeador legado é responsável por interpretar partes da URL para identificar ações e parâmetros da aplicação. De acordo com a falha, uma expressão maliciosa pode ser introduzida nesse processo e explorada para executar código no servidor. Como não é necessário estar autenticado, uma aplicação exposta e configurada de forma vulnerável pode ficar sujeita a ataques remotos.

Estão entre as versões afetadas as séries 2.0.0 a 2.3.37, 2.5.0 a 2.5.33, 6.0.0 a 6.11.0 e 7.0.0 a 7.3.0. As correções foram incluídas na versão 7.4.0 e posteriores. Para quem utiliza a linha 6, a atualização indicada é a 6.12.0.

Além da falha de execução de código, o pacote de correções trata outros três problemas. Dois podem comprometer a disponibilidade dos serviços. Um deles permite que requisições pequenas provoquem respostas muito maiores, aumentando o consumo de processamento e largura de banda. O outro pode levar ao esgotamento de memória porque aceita corpos de requisição sem um limite adequado.

Para reduzir esse segundo risco, foi estabelecido um limite padrão de 2.097.152 caracteres para o corpo da requisição. Essa é a única das quatro vulnerabilidades classificada como importante; as demais receberam severidade moderada. A classificação, porém, não elimina a necessidade de avaliar o impacto no ambiente específico, sobretudo em sistemas acessíveis pela internet.

A quarta falha tem um comportamento diferente: não depende de uma requisição especialmente construída. Formatadores de mensagem compartilhados podem interferir uns nos outros durante solicitações simultâneas. Sob tráfego normal, isso pode causar erros na apresentação do conteúdo ou expor dados que não deveriam aparecer naquela resposta.

A primeira medida recomendada é identificar quais aplicações utilizam Apache Struts, levantar a versão instalada e confirmar qual mapeador está ativo. A simples presença do framework não confirma a exposição à CVE-2026-104711, mas a combinação de uma versão vulnerável com o mapeador legado exige atenção imediata.

Quando possível, equipes responsáveis devem atualizar o Struts para uma das versões corrigidas. A migração precisa incluir testes: mudanças de versão podem afetar integrações, validações e fluxos de negócio. É importante verificar se a aplicação continua funcionando corretamente antes de concluir a implantação em produção.

Se a atualização não puder ser realizada de imediato, convém avaliar a possibilidade de desativar o mapeador antigo ou substituí-lo por uma alternativa não afetada. Também é recomendável revisar a configuração do OGNL, especialmente nas aplicações da série 7.x, e manter controles de acesso e monitoramento ativos. Essas medidas podem reduzir a exposição, mas não substituem a aplicação da correção.

A investigação não deve se limitar à vulnerabilidade de execução remota. Os problemas de consumo de recursos e de tratamento de mensagens também podem afetar a estabilidade e a confidencialidade. Monitorar picos incomuns de processamento, uso de memória, volume de tráfego e erros de renderização pode ajudar a identificar sinais de exploração ou efeitos colaterais.

Por fim, organizações com aplicações críticas devem registrar os sistemas afetados, priorizar aqueles expostos à internet e documentar as versões corrigidas. Uma verificação posterior à atualização é essencial para confirmar que o mapeador vulnerável deixou de ser usado e que os limites de requisição estão aplicados como esperado.