FreePBX Administration GUI is Vulnerable to Authenticated Command Injection

Falha de injeção de comando de SO (CWE-78) no módulo filestore do FreePBX Endpoint Manager, explorável por qualquer usuário autenticado com acesso ao painel administrativo (ACP), permitindo execução arbitrária de comandos como usuário asterisk. É pré-condição real — não é RCE não-autenticado — mas está na lista KEV da CISA com exploração ativa confirmada, incluindo uma campanha documentada de web shell persistente (EncystPHP) atribuída ao grupo INJ3CTOR3.

A vulnerabilidade está na função check_ssh_connect() do arquivo drivers/SSH/testconnection.php, parte da funcionalidade 'testconnection' do filestore, usada pela interface administrativa para validar conexões SSH ao configurar armazenamento remoto de gravações/arquivos. A função recebe os parâmetros $host, $port, $user, $key e $path — todos originados de entrada do usuário via o painel administrativo — e os concatena diretamente em chamadas exec(), como exec("mkdir -p $keypath") e exec("ssh-keygen -t ecdsa -b 521 -f $key -N \"\" && chown asterisk:asterisk $key && chmod 600 $key"), sem sanitização ou escaping de metacaracteres de shell.

Como $key (e o $keypath derivado via dirname($key)) e $path chegam ao shell sem filtragem, um atacante que controle esses campos pode inserir metacaracteres (;, &&, |, backticks, etc.) para encadear comandos arbitrários que serão executados no contexto do processo web/Asterisk. O código foi introduzido por volta de março de 2025, segundo o próprio advisory do FreePBX, o que situa a janela de exposição em vários meses antes da divulgação em novembro de 2025.

O CVSS 4.0 base (8.6) reflete o pior caso teórico — comprometimento total de confidencialidade, integridade e disponibilidade do sistema vulnerável — mas o próprio FreePBX publicou no advisory uma pontuação com Threat Environment Supplemental que reduz drasticamente a severidade percebida (CVSS-BTES 6.1 Medium, ou 0.9 Low sob CVSS 4.1), argumentando que o requisito de autenticação prévia via ACP muda substancialmente o perfil de risco em ambientes bem configurados.

O vetor exige que o atacante já possua credenciais válidas de acesso ao FreePBX Administration Panel (ACP) — o advisory fala em 'autenticação com um usuário conhecido' e a CVSS marca Privileges Required como High. Não há bypass de autenticação documentado nesta CVE: a exploração depende de o painel estar acessível na rede (ou exposto à internet) e de o atacante ter, ou obter, login válido. Uma vez autenticado, basta acionar a função de teste de conexão SSH do módulo filestore com valores manipulados nos campos de caminho/chave para injetar comandos que rodam como o usuário asterisk.

Há exploração ativa confirmada e catalogada no KEV da CISA. A FortiGuard Labs documentou incidentes desde início de dezembro (referenciados em relatório de janeiro de 2026) associados ao grupo INJ3CTOR3 — mesmo grupo ligado historicamente a CVE-2019-19006 (FreePBX) e CVE-2021-45461 (Elastix). Nesses casos, após a injeção de comando, os atacantes baixam um dropper que instala o web shell 'EncystPHP', disfarçado de ajax.php dentro da própria estrutura do FreePBX; o dropper apaga usuários e cron jobs legítimos, remove outros web shells concorrentes, cria um usuário root persistente (newfpbx), injeta chave SSH e garante que a porta 22 permaneça aberta — um padrão de comprometimento total e persistente, não um simples RCE pontual.

Existem módulo Metasploit, template Nuclei e PoC pública, o que reduz a barreira técnica para quem já tem credenciais — a etapa de descoberta e weaponização do payload de injeção está automatizada; o obstáculo real é obter acesso autenticado ao ACP.

Atualizar o módulo filestore para a versão 17.0.3 ou superior é a correção definitiva — o vendor fixou a falha diretamente no código de check_ssh_connect(). Não há indicação de patch parcial ou flag de configuração que neutralize a injeção sem atualizar o módulo.

Se a atualização não for imediatamente viável, o próprio advisory do FreePBX lista dois controles compensatórios: garantir que apenas usuários autorizados tenham acesso ao FreePBX Administrator Control Panel (revisar contas, remover credenciais compartilhadas ou de terceiros) e bloquear acesso ao ACP a partir de redes não confiáveis, por exemplo restringindo a interface a IPs de gestão via firewall de borda ou o módulo de firewall do próprio FreePBX. Nenhuma dessas medidas corrige a vulnerabilidade — apenas reduz a superfície de quem pode chegar até o ponto de exploração, então continuam vulneráveis a qualquer credencial de ACP comprometida (phishing, reuso de senha, credential stuffing).

Dado o histórico documentado pela FortiGuard de webshells persistentes instalados após exploração (EncystPHP), sistemas que rodaram versões no intervalo vulnerável (17.0.2.36 até antes de 17.0.3) e tiveram o ACP exposto devem ser tratados como potencialmente comprometidos, não apenas patcheados — vale auditar contas de usuário criadas fora do processo normal, chaves SSH autorizadas não reconhecidas, e arquivos PHP como ajax.php/model.php com permissões ou conteúdo alterados.

Nos logs do FreePBX/Asterisk e do servidor web, procurar acessos à funcionalidade de teste de conexão do filestore (rota associada a testconnection/check_ssh_connect) com parâmetros de host, caminho ou nome de chave contendo metacaracteres de shell (;, |, &&, backticks, $()). Em nível de sistema, sinais de comprometimento pós-exploração documentados pela FortiGuard incluem: criação do usuário 'newfpbx' com UID/GID 0, alterações de senha em massa em contas de sistema, chaves SSH públicas injetadas em authorized_keys, presença de arquivo ajax.php modificado fora do padrão de atualização do FreePBX, permissão 000 aplicada a ajax.php/model.php, remoção do módulo endpoint, e conexões de saída para o IP 45.234.176.202 ou o domínio crm.razatelefonia.pro.

Não há um único indicador de rede confiável para a tentativa de exploração em si, já que o tráfego malicioso é indistinguível de uso legítimo do painel administrativo sem inspeção do conteúdo dos parâmetros enviados — a detecção depende de monitorar o payload da requisição ou os artefatos pós-exploração no host, não apenas volume ou origem de tráfego.