CVE-2025-48703

Falha de OS Command Injection (CWE-78) no File Manager do CentOS Web Panel (CWP), painel usado para administrar servidores baseados em RPM. A função que troca permissões de arquivo (changePerm) monta um comando chmod via shell sem sanitizar o parâmetro t_total, e o endpoint aceita a requisição mesmo sem sessão autenticada válida — bastando saber um username não-root existente no servidor. Está no catálogo KEV da CISA com exploração confirmada e cerca de 200 mil instâncias expostas foram identificadas via Shodan em maio de 2025, o que torna a superfície de ataque real e ampla.

O CWP expõe uma interface de usuário na porta 2083 com um módulo de gerenciamento de arquivos que permite alterar permissões (chmod) através do endpoint filemanager com ação changePerm. A pesquisa da Fenrisk (via strace) mostrou que o servidor, ao processar essa requisição, executa o comando através de /bin/sh -c "chmod \"\"", onde t_total é o valor de permissão enviado pelo cliente sem qualquer sanitização de metacaracteres de shell. Isso é injeção de comando clássica (CWE-78): o atacante controla integralmente o conteúdo interpolado dentro da string passada ao interpretador de shell.

Há uma segunda falha combinada com a primeira: a verificação de autenticação do endpoint changePerm não é aplicada corretamente. Os pesquisadores demonstraram que é possível remover o identificador de usuário/sessão da URL e obter o mesmo comportamento — ou seja, a rota aceita a requisição sem cookies de sessão válidos, desde que a URL referencie um username existente e não-root (a rota tem o formato .../modulo///index.php?module=filemanager&acc=changePerm).

Pré-condições estruturais do endpoint: o parâmetro fileName precisa apontar para um arquivo que já exista, e currentPath precisa estar dentro do diretório /home/ daquele usuário (ex.: /home/myuser/.bashrc, arquivo presente por padrão na maioria das contas). Isso não é uma restrição de segurança eficaz — arquivos padrão de shell profile existem em praticamente toda conta de usuário criada pelo painel.

O código-fonte do CWP é protegido por ionCube, o que dificultou a análise estática da vulnerabilidade e provavelmente contribuiu para o tempo entre a publicação técnica (junho/2025) e a atribuição formal da CVE (setembro/2025) e entrada no KEV (novembro/2025).

O vetor é uma requisição HTTP POST multipart para o módulo filemanager com ação changePerm, na porta de usuário do CWP (2083 por padrão). O único pré-requisito de conhecimento prévio é um username válido e não-root existente no servidor alvo — não é necessário possuir credenciais, cookie de sessão ou qualquer token daquele usuário, porque a verificação de autenticação da rota pode ser contornada. Isso explica o AC:H no vetor CVSS: a complexidade não está na injeção em si (trivial), mas em descobrir/adivinhar um username válido no host de destino, o que pode ser feito por enumeração (mensagens de erro diferentes, listagem de usuários por outros meios, ou reaproveitamento de vazamentos de credenciais/usernames anteriores).

Com um username válido e um arquivo existente sob /home// (ex.: .bashrc, que existe por padrão), o atacante injeta metacaracteres de shell no campo t_total do formulário de troca de permissão. Como o valor é concatenado dentro de uma string executada via sh -c, o atacante consegue encadear comandos arbitrários que são executados com os privilégios do processo do CWP/cwpsrv — potencialmente comprometendo o servidor completo, dado que o daemon frequentemente roda com privilégios elevados para gerenciar contas de hospedagem.

Há PoC pública e template Nuclei disponíveis, o que reduz a barreira de exploração em massa a praticamente zero para quem já tem uma lista de usernames válidos ou usa técnicas de enumeração. A entrada no catálogo KEV da CISA confirma exploração ativa in-the-wild; a CISA não classifica o CVE como usado em campanhas de ransomware conhecidas até o momento do registro, mas trata como exploração confirmada o suficiente para exigir remediação com prazo.

A correção está publicada pelo fornecedor: atualizar para a versão 0.9.8.1205 ou posterior do CWP, conforme a descrição oficial da falha. O changelog público do fornecedor lista versões posteriores (a partir de 1223 em diante) com menções genéricas a "fix File Manager module" e "security fix", mas não confirma explicitamente o número 0.9.8.1205 no texto disponível — trate a versão mínima informada na descrição oficial/NVD como a referência de corte e valide a versão instalada no painel após atualizar.

Se a atualização imediata não for viável, restrinja o acesso à porta do painel de usuário (2083) e à porta administrativa (2087/2031) por IP de origem (firewall/CSF), já que o CWP normalmente não deveria estar exposto irrestritamente à internet. Monitorar e desabilitar contas não utilizadas reduz a superfície de nomes de usuário válidos que um atacante pode explorar, embora isso não elimine a falha em si — é controle compensatório, não correção.

Não existe mitigação eficaz baseada em ocultar a interface por porta não padrão ou por obscuridade de URL: a vulnerabilidade não depende de descoberta de endpoint, e usernames podem ser obtidos por outros vetores (vazamentos, engenharia social, reconhecimento). Da mesma forma, WAFs genéricos podem não bloquear o payload se não houver assinatura específica para o parâmetro t_total do módulo filemanager — regras específicas para esse endpoint e parâmetro são necessárias como paliativo, não substituto do patch.

Procurar em logs de acesso web por requisições POST ao endpoint index.php?module=filemanager&acc=changePerm contendo, no corpo multipart, o campo t_total com metacaracteres de shell (;, |, &, `, $(), >, <) em vez de um valor numérico de permissão (ex.: 644, 755). Requisições desse tipo sem cookies de sessão válidos do CWP (cwpsrv-*) reforçam a suspeita de exploração, já que a rota deveria exigir autenticação.

Em nível de sistema, auditd/execve logging pode capturar chamadas a /bin/sh -c contendo "chmod" seguido de argumentos incomuns (comandos concatenados, redirecionamentos, subshells) originadas do processo cwpsrv — esse é o sinal mais confiável de exploração bem-sucedida, já visível na análise da Fenrisk via strace. Não há assinatura de rede única e estável além dessas, já que o payload varia por atacante; ausência desses sinais não garante que não houve tentativa, apenas que não foi capturada pelos controles descritos.