CVE-2022-35914

Falha de execução remota de código não autenticada no GLPI, causada por um script de exemplo (htmLawedTest.php) da biblioteca de terceiros htmlawed que é distribuído junto com o pacote de release do GLPI e fica acessível publicamente por padrão. Qualquer pessoa com acesso HTTP à instância, sem login, consegue executar comandos no sistema operacional do servidor. Está no catálogo KEV da CISA, com PoC pública, módulo Metasploit e template Nuclei — exploração trivial e em massa.

O problema não está no código-fonte do GLPI em si, mas na biblioteca de terceiros htmlawed, empacotada dentro de /vendor/htmlawed/htmlawed/ nas releases do GLPI baixadas do GitHub (releases via composer puro, sem o pacote completo, não incluem o arquivo). O arquivo htmLawedTest.php é um script de demonstração da biblioteca, feito para testar configurações do htmLawed() interativamente, e não deveria nunca ficar exposto em produção.

O script monta um array de configuração ($cfg) a partir de qualquer parâmetro POST cuja chave comece com a letra 'h' (ex.: hhook, htext), removendo o prefixo 'h' e usando o restante como nome da opção — controle total do atacante sobre a configuração passada à função htmLawed(). Dentro de htmLawed(), a opção 'hook' é validada apenas com function_exists() e, se existir, a função é invocada como callback: $C['hook']($t, $C, $S), onde $t é o texto enviado pelo usuário (parâmetro 'text').

Essa assinatura de chamada coincide, por coincidência de tipos do PHP, com a assinatura de exec(string $command, array &$output, int &$result_code). Ao definir hook=exec e text=, o atacante faz o PHP interpretar $t como o comando a executar e $C/$S como os parâmetros de saída por referência — execução arbitrária de comando do sistema. A classe é CWE-94 (Improper Control of Generation of Code / Code Injection), materializada como chamada dinâmica de função com nome controlado pelo atacante.

O detalhe crítico: qualquer função PHP que aceite os mesmos tipos de parâmetro (array_map, call_user_func e variantes) também serve como hook, então restringir apenas exec() via disable_functions no php.ini não neutraliza a falha — o vetor de código genérico continua aberto.

Vetor: uma única requisição HTTP POST para /vendor/htmlawed/htmlawed/htmLawedTest.php, sem autenticação no GLPI, sem sessão válida — o script cria e valida a própria sessão localmente a partir dos parâmetros enviados pelo atacante (sid via POST e cookie). Não exige configuração não padrão: o arquivo vem junto do pacote de release oficial do GLPI e é servido normalmente pelo servidor web, salvo se o administrador tenha removido explicitamente o vendor folder do acesso público.

Complexidade de exploração é mínima (a CVSS AC:L reflete isso corretamente): basta enviar hhook=exec e text= no corpo da requisição. O resultado do exec() é refletido na própria resposta HTML do script, funcionando como um webshell instantâneo — o atacante lê a saída do comando diretamente na página retornada. Não há PR (privilégio) nem UI (interação de usuário) envolvidos.

A CISA confirma exploração ativa em campo (KEV), há PoC pública (inclusive script shell simples publicado por pesquisadores) e módulo Metasploit pronto — o que reduz drasticamente a barreira até para atacantes automatizados fazendo varredura em massa de instâncias GLPI expostas à internet.

Atualizar para GLPI 10.0.3 ou superior (ramo 10.0.x) ou 9.5.9 ou superior (ramo 9.5.x antigo) resolve a falha — essas versões removem o script vulnerável do pacote de release. A própria biblioteca htmlawed, upstream, também foi corrigida (o hook/hook_tag do script de exemplo passou a ser explicitamente unset antes de chamar a função), então atualizar a dependência isoladamente também mitiga, se possível.

Se a atualização não for viável de imediato, o paliativo real e eficaz é remover o arquivo /vendor/htmlawed/htmlawed/htmLawedTest.php do servidor — ele não é necessário para o funcionamento do GLPI. Complementar bloqueando acesso HTTP direto a todo o diretório /vendor (nenhum arquivo ali deveria ser servido publicamente) fecha a classe inteira de risco de scripts de exemplo/teste de dependências de terceiros.

O que NÃO funciona: desabilitar apenas exec() via disable_functions no php.ini. Como o mecanismo de exploração aceita qualquer função PHP com assinatura compatível (array_map, call_user_func e outras), bloquear só exec() deixa o vetor de código genérico aberto — o atacante troca de função e mantém RCE.

Buscar em logs de acesso web (access log do servidor HTTP) qualquer requisição — especialmente POST — para o caminho /vendor/htmlawed/htmlawed/htmLawedTest.php. Como esse script nunca é usado em operação normal do GLPI, qualquer acesso a ele é indicador forte de tentativa de exploração ou reconhecimento; presença de parâmetros como hhook, htext ou hspec no corpo da requisição confirma a tentativa. Não há assinatura de payload única a procurar no corpo além desse padrão de nomes de parâmetro, já que o comando executado é livre — o sinal confiável é o próprio acesso ao endpoint, não o conteúdo do comando.