Commvault Command Center Innovation Release <= 11.38.25 Unathenticated Install Package Path Traversal

Falha de path traversal (CWE-22) no mecanismo de upload de pacotes de instalação do Commvault Command Center (Innovation Release 11.38), que permite a um atacante não autenticado enviar um arquivo ZIP malicioso e fazer o servidor extraí-lo fora do diretório pretendido, depositando um arquivo JSP em local servido publicamente pelo Tomcat. O resultado é execução remota de código sem nenhuma credencial, no contexto do serviço da aplicação — por isso o CVSS 9.3 é justificado e a falha está confirmada em exploração ativa (KEV da CISA).

O Command Center roda sobre um processo Tomcat que expõe múltiplos contexts (ex.: /commandcenter, /reports, /console), cada um mapeado a um docBase no disco conforme configurado no server.xml. Um dos endpoints associados ao contexto de relatórios/métricas (ex.: rotas sob /reports/MetricsUpload/) aceita upload de arquivos ZIP representando 'pacotes de instalação' sem exigir autenticação prévia.

Ao processar o ZIP, o servidor extrai as entradas do arquivo para um diretório de destino, mas não sanitiza corretamente nomes de entrada contendo sequências de travessia de diretório (../). Isso permite que o atacante controle o caminho final de extração de arquivos dentro do ZIP, escapando do diretório temporário de upload e escrevendo arquivos em locais acessíveis via HTTP pelo próprio Tomcat — inclusive dentro de subpastas do webapp Reports que são servidas publicamente.

Como o Tomcat compila e executa arquivos .jsp colocados em qualquer diretório dentro do webroot da aplicação, o atacante inclui no ZIP um arquivo JSP com código Java arbitrário. Após a extração, basta uma requisição HTTP GET ao caminho resultante para o servidor compilar e executar o JSP, entregando execução de código no contexto da conta de serviço do Commvault (nos testes do watchTowr, a conta de serviço Windows do processo Tomcat).

A causa raiz é a falta de validação de path traversal na rotina de expansão de ZIP do subsistema de deploy de pacotes — o mesmo padrão clássico de 'zip slip' aplicado a um endpoint de instalação que deveria ser restrito a uso interno, mas está exposto sem autenticação na interface web pública.

O vetor é uma única sequência HTTP: upload do ZIP malicioso para o endpoint de upload de métricas/relatórios (observado publicamente como algo como /reports/MetricsUpload//), seguido por uma requisição GET ao caminho onde o JSP foi depositado após a extração com travessia de diretório. Não há necessidade de autenticação, de configuração não padrão nem de interação do usuário — apenas acesso de rede à interface HTTPS do Command Center (porta 443 no ambiente analisado pelo watchTowr). Isso coincide com o vetor CVSS4 (AV:N/AC:L/AT:N/PR:N/UI:N).

O PoC público do watchTowr Labs demonstra o fluxo completo: verifica a presença do Commvault, envia o ZIP contendo um shell.jsp, e recupera a propriedade de sistema 'user.name' da máquina via resposta HTTP do próprio JSP, provando execução de código no processo Tomcat. Um atacante malicioso substituiria esse JSP de prova de conceito por um webshell completo para obter execução arbitrária persistente.

A vulnerabilidade está no catálogo KEV da CISA desde 02/05/2025 (prazo de correção 23/05/2025), confirmando exploração ativa observada, além de PoC público no GitHub e template Nuclei disponível — o que reduz drasticamente a barreira técnica para exploração em massa via scanners automatizados.

A correção do fornecedor exige atualização para 11.38.20 OU 11.38.25, mas apenas instalar essas versões base não é suficiente: é necessário aplicar também as atualizações adicionais específicas — SP38-CU20-433 e SP38-CU20-436 para quem fica no ramo 11.38.20, ou SP38-CU25-434 e SP38-CU25-438 para quem migra para 11.38.25. O próprio advisory recomenda verificar, na página de listagem de servidores do Command Center, se essas 'Additional Updates' aparecem listadas em cada instalação — presumir que a versão numérica já resolve o problema é o erro mais provável aqui.

Se a atualização não for viável imediatamente, o fornecedor recomenda isolar a instalação do Command Center de acesso externo à rede — ou seja, remover a exposição da interface web à internet até o patch ser aplicado. Não há menção de mitigação via WAF ou hardening de configuração que substitua o patch; dado que o endpoint vulnerável é pré-autenticação e faz parte da funcionalidade central de deploy de pacotes, bloqueio de rede é o único controle compensatório real documentado.

Clientes do Commvault SaaS não precisam agir: o fornecedor aplicou o patch automaticamente em toda a base SaaS, segundo o advisory.

Nos logs de acesso do Tomcat/IIS, procure requisições POST/PUT para caminhos sob /reports/MetricsUpload/ (ou variações do contexto Reports) seguidas, em curto intervalo, por requisições GET a caminhos incomuns contendo segmentos como '.tmp/dist-cc/dist-cc/' ou arquivos .jsp fora dos locais esperados dentro do webapp de Reports/Metrics — esse padrão de upload seguido de GET ao artefato extraído é o rastro mais direto de exploração. Também vale inspecionar o diretório do webapp Reports no disco por arquivos .jsp não reconhecidos, criados fora de deploys legítimos.

Como há PoC público e template Nuclei em circulação, scanners automatizados tendem a gerar tentativas em lote; user-agents genéricos de ferramentas de varredura ou múltiplos uploads de ZIP com nomes de diretório aleatórios em curto período são indicadores adicionais, mas não há assinatura de rede oficialmente publicada pelo fornecedor — a detecção depende de correlação de logs de aplicação, não de uma assinatura única confiável.