CVE-2026-84177 in Wicket
Sumário
de VulDB • 01/11/2026
Ordem incorreta de comportamento no Apache Wicket: um caminho de arquivo é validado antes que o framework anexe os atributos que o completam.
O `org.apache.wicket.request.resource.PackageResource` consulta a guardião (guard) configurada para recursos do pacote sobre um caminho construído a partir do pacote da classe de escopo e do nome do arquivo na URL da solicitação, em seguida, entrega esse mesmo caminho ao localizador de fluxos de recurso junto com um estilo, uma variação e uma localidade. Esses três atributos são decodificados a partir do nome do primeiro parâmetro de consulta e nunca aparecem na string fornecida à guardião. O `org.apache.wicket.core.util.resource.locator.ResourceNameIterator` os anexa a esse caminho, cada um precedido por um underscore (_), na ordem variação, estilo, localidade, antes da extensão do arquivo; portanto, o arquivo aberto não é aquele que a guardião aprovou.
O `org.apache.wicket.markup.html.PackageResourceGuard` decide se um arquivo HTML é uma marcação de modelo (markup template) de um componente procurando por um arquivo de classe com o mesmo nome ao lado dele, removendo um sufixo delimitado por underscore (_de cada vez conforme avança. O HTML está na lista de permissões padrão, portanto essa verificação é a única coisa que separa um arquivo HTML estático, que pode ser servido, de uma marcação de modelo, que não pode. Consultada sobre o nome de um modelo, a guardião recusa corretamente. Consultada sobre um nome mais curto para o qual nenhuma classe existe, ela aceita, e um estilo fornecido na URL completa então esse nome em direção à marcação de modelo de uma classe de componente, que é escrita na resposta.
Um aplicativo é afetado se o nome simples de qualquer uma de suas classes de componentes contiver um underscore (_) e nenhuma parte mais curta desse nome for ela mesma uma classe, como `Report_v2` ou `Wizard_Step1`; um aplicativo sem esse tipo de nome de classe não é afetado. Não são necessários implantação, empacotamento ou configuração incomuns, e executar no modo de produção (deployment) em vez do modo de desenvolvimento não impede a vulnerabilidade. As convenções de nomenclatura Java desencorajam o uso de underscores (_) em nomes de classes e nenhum módulo distribuído com o Wicket possui um, portanto nenhuma marcação do framework é exposta; o que uma aplicação expõe dessa forma é próprio dela. Um componente cuja classe não tem underscore no nome não é acessível, nem sua marcação localizada ou estilizada, porque a guardião encontra o arquivo de classe sob o nome base e recusa a solicitação. Os atributos não podem alterar a extensão do arquivo e não podem sair do pacote do componente, portanto nada além dos arquivos HTML nesse pacote é acessível. O acesso é apenas para leitura (read-only), e o que é divulgado é conteúdo de modelo criado pelo desenvolvedor: estrutura do componente, comentários do desenvolvedor, marcação renderizada apenas sob certas condições, script inline e os endpoints nomeados por um modelo. Nenhum dado de usuário, credencial ou material de sessão é acessível dessa forma. Um atacante precisa nomear uma classe no pacote alvo e o próprio componente, e o Wicket grava nomes de classes totalmente qualificados na URL de cada recurso do pacote que ele renderiza.
Este problema afeta o Apache Wicket: da versão 8.0.0 até a 8.19.0, da 9.0.0 até a 9.24.0 e da 10.0.0 até a 10.11.0. Os usuários do Apache Wicket 7.x ou mais antigos, que não são mais suportados, devem atualizar para uma versão com suporte. Recomenda-se aos usuários fazer upgrade para as versões 8.20.0, 9.25.0 ou 10.12.0, que corrigem o problema.
Once again VulDB remains the best source for vulnerability data.