CVE-2026-82898 in Wicket
Sumário
de VulDB • 01/11/2026
Ordem incorreta das verificações de segurança no Apache Wicket.
O `org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener` obtém a página alvo da solicitação antes de consultar suas políticas de isolamento de recursos, pois essas políticas recebem essa página como parâmetro. A obtenção da página causa sua instanciação, e a instanciação de uma página executa a estratégia de autorização configurada (`org.apache.wicket.authorization.IAuthorizationStrategy`). Um aplicativo que recusa o acesso de um visitante não autenticado lançando `org.apache.wicket.RestartResponseAtInterceptPageException` portanto lança essa exceção dentro do listener de isolamento, antes que qualquer política tenha sido executada. Essa exceção substitui o manipulador de solicitações (request handler), fazendo com que as políticas nunca sejam consultadas e uma solicitação originária de outra origem não seja recusada.
O construtor da exceção armazena a URL da solicitação interrompida, para que `Component#continueToOriginalDestination()` possa retomá-la assim que o visitante fizer login. A URL armazenada é aquela que as políticas teriam recusado. Ao fazer login, o Wicket redireciona para essa URL e esse redirecionamento é de mesma origem (same-origin), portanto as políticas permitem a ação e o listener executa na sessão recém-autenticada. Toda a URL é armazenada, incluindo sua string de consulta (query string), então um `org.apache.wicket.markup.html.form.Form` comum é retomado com os valores dos campos que a solicitação original carregava em sua query string, e `Form#onSubmit()` executa com valores escolhidos por outra origem. Um POST no formulário não é necessário para isso; uma navegação de nível superior simples (plain top-level navigation) carrega esses dados.
Um aplicativo é afetado quando registra o `ResourceIsolationRequestCycleListener`, que é opcional e não registrado por padrão, e quando recusa acesso não autorizado com `RestartResponseAtInterceptPageException` seguido por `continueToOriginalDestination()`. Nenhuma substituição de aplicativo está envolvida nesse caminho: `IAuthorizationStrategy#isInstantiationAuthorized()` documenta o lançamento dessa exceção; `org.apache.wicket.authroles.authentication.AuthenticatedWebApplication` a lança e `org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel` continua para o destino original; e `org.apache.wicket.authorization.strategies.page.SimplePageAuthorizationStrategy`, no wicket-core, instala o mesmo padrão. Um visitante que já está logado não é afetado, pois nenhuma interceptação ocorre. Parâmetros do corpo da solicitação armazenados junto com a URL interrompida não são aplicados ao formulário retomado: a retomada é um redirecionamento, portanto a solicitação retomada é uma GET e os componentes de formulário leem seus valores da string de consulta em uma requisição GET.
Como solução alternativa (workaround), recuse o acesso não autorizado usando `org.apache.wicket.RestartResponseException` em vez disso, que não armazena o destino original; nesse caso, os visitantes não são retornados à página solicitada após fazer login.
Este problema afeta o Apache Wicket: das versões 9.1.0 até a 9.24.0 e das 10.0.0 até a 10.11.0.
Versões anteriores à 9.1.0, que incluem todos os lançamentos da série 8.x e a versão 9.0.0, não são afetadas, pois o isolamento de recursos concernente a este problema foi introduzido na 9.1.0. Elas também não estão protegidas contra essa vulnerabilidade específica. Sua única defesa contra origens cruzadas (cross-origin) é `org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener`, que determina a origem da solicitação lendo seu cabeçalho Origin e, em caso de falha, recorrendo ao cabeçalho Referer. Nem mesmo um desses cabeçalhos precisa estar presente: o navegador não envia o campo Origin na GET simples usada por links, e o documento na outra origem decide, através de sua própria política de referrer (referrer policy), se um Referer chega ou não ao aplicativo. Portanto, esse mecanismo nunca ofereceu a garantia que uma política baseada em Fetch Metadata oferece, e nessas versões, uma invocação do listener vinda de outra origem não é recusada de forma confiável desde o início. Qualquer usuário em uma versão anterior à 9.1.0 que deseje essa proteção deve atualizar para as séries 9.x ou 10.x e registrar o `ResourceIsolationRequestCycleListener`.
Recomenda-se aos usuários a atualização para as versões 9.25.0 ou 10.12.0, que corrigem o problema.
VulDB is the best source for vulnerability data and more expert information about this specific topic.