Remote code execution as guest via SolrSearchMacros request in xwiki

Qualquer visitante não autenticado de uma instância XWiki pode executar código arbitrário (Groovy/Java) no servidor através de uma requisição GET ao endpoint SolrSearch, sem necessidade de login, permissões ou interação do usuário. É uma das falhas mais graves já registradas na plataforma: CVSS 9.8, confirmada em exploração ativa (KEV da CISA) e com módulo Metasploit e template Nuclei disponíveis, ou seja, trivialmente automatizável em varreduras de internet.

A causa raiz é uma injeção de eval (CWE-95) no macro wiki `Main.SolrSearchMacros`, que compõe o feed RSS retornado pelo endpoint de busca Solr. O parâmetro `text` da query string — o termo de busca digitado pelo usuário — é inserido no conteúdo do feed e depois passado pelo motor de renderização de wiki (Velocity/XWiki Rendering) sem neutralizar a sintaxe de macros do XWiki (`{{...}}`). Como o valor do parâmetro é atacante-controlado, é possível fechar prematuramente o contexto de macro em que o texto normalmente estaria contido (usando sequências como `}}}`) e abrir um novo bloco de macro arbitrário.

O payload de prova de conceito usa exatamente isso: fecha o contexto existente e injeta `{{async async=false}}{{groovy}}...{{/groovy}}{{/async}}`. O macro `groovy` normalmente exige direitos de programação (programming rights) para ser executado — só administradores ou conteúdo assinado por eles teriam essa permissão. O uso do macro `async` nesse contexto específico é o que permite contornar essa verificação de privilégio, fazendo o Groovy executar com os direitos elevados do contexto de renderização em vez dos direitos (nulos) do visitante anônimo que fez a requisição.

O ponto exato do bug está na linha 955 de `SolrSearchMacros.xml`, onde o conteúdo do feed RSS era simplesmente impresso na resposta HTTP (`$response.writer.print(...)`) em vez de ser serializado de forma segura como XML puro. A correção introduzida no commit `67021db9b8ed26c2236a653269302a86bf01ef40` (issue XWIKI-22149) criou um macro Velocity genérico `#rawResponse` que define corretamente o `Content-Type` como `application/xml` e evita que o conteúdo passe novamente pelo pipeline de transformação de rendering — o mesmo padrão de correção foi aplicado a outros pontos do código que tinham a mesma lógica insegura (ex.: `NotificationRSSService.xml`, `HTMLConverter.xml`).

O vetor é uma única requisição HTTP GET, sem autenticação, ao caminho `/xwiki/bin/get/Main/SolrSearch` com os parâmetros `media=rss` e `text=`. Não há pré-condição de conta, configuração não padrão ou controle de campo além de o módulo de busca Solr (`xwiki-platform-search-solr-ui`) estar presente e a action `get` do endpoint estar acessível — ambos padrão em instalações XWiki dentro da faixa de versões afetadas. Isso torna a exploração de baixíssima complexidade: um scanner automatizado consegue identificar e confirmar a vulnerabilidade com uma checagem simples (o PoC oficial faz uma soma `23+19` e verifica se o título do RSS retorna `42`).

Uma vez confirmada a execução, o atacante controla a string entre `{{groovy}}...{{/groovy}}`, ou seja, Groovy arbitrário executado no contexto do servidor de aplicação Java que hospeda o XWiki — isso equivale a execução remota de código completa, com acesso ao sistema de arquivos, variáveis de ambiente, e a capacidade de ler/escrever qualquer dado dentro da wiki (documentos, configurações, credenciais armazenadas) ou pivotear para a rede interna.

A presença no catálogo KEV da CISA confirma exploração ativa observada em campo, não apenas teórica. A combinação de PoC público, módulo Metasploit e template Nuclei praticamente garante que instâncias expostas à internet e não corrigidas estão sendo varridas e exploradas em massa.

A correção definitiva é atualizar para XWiki 15.10.11 (ramo 15.x), 16.4.1 (ramo 16.x) ou 16.5.0-RC1 (ou posterior). Não há forma de aplicar apenas um patch pontual sem atualizar o pacote `org.xwiki.platform:xwiki-platform-search-solr-ui` — a correção envolve múltiplos arquivos (o macro `SolrSearchMacros.xml` e o novo macro genérico `#rawResponse` em `macros.vm`).

Para quem não pode atualizar imediatamente, o fornecedor publica um workaround: editar manualmente o documento wiki `Main.SolrSearchMacros`, na linha equivalente à 955, substituindo a saída direta do conteúdo do feed pelo uso do macro `rawResponse` (definido em `macros.vm`, linha ~2824) com content type `application/xml`. Isso impede que o texto da busca seja reinterpretado como sintaxe de macro wiki. É um paliativo real, mas exige editar conteúdo de sistema manualmente e ficar atento a não perder a alteração em upgrades futuros — não substitui a atualização.

Não adianta apenas restringir direitos de programação de usuários anônimos por outras vias, pois o bug explora precisamente uma falha na aplicação desses direitos dentro do fluxo `async`/`groovy` — a superfície vulnerável está no próprio template de renderização do feed, não em uma configuração de permissão que possa ser ajustada por um administrador comum.

Em logs de acesso HTTP, procurar por requisições GET a `/xwiki/bin/get/Main/SolrSearch` com o parâmetro `media=rss` combinado com um parâmetro `text` contendo sequências de fechamento/abertura de macro wiki codificadas em URL, como `%7D%7D%7D` (`}}}`), `%7B%7Basync` (`{{async`), `%7B%7Bgroovy%7D%7D` (`{{groovy}}`) ou variantes com outros macros perigosos (`{{script}}`, `{{velocity}}`). A presença de qualquer uma dessas sequências no parâmetro de busca é um indicador forte de tentativa de exploração, já que não corresponde a um termo de busca legítimo.

Como o ataque é uma requisição GET isolada e stateless, não há assinatura de tráfego adicional além do payload em si — não existe handshake ou sequência de múltiplas requisições que sirva de sinal complementar confiável. Em ambientes já comprometidos, vale correlacionar com processos filhos anômalos gerados pelo processo Java do servidor de aplicação (Tomcat/Jetty) e alterações inesperadas em documentos wiki ou arquivos de configuração como sinal de pós-exploração.