CVE-2024-23115

What it actually does

The flaw is an authenticated SQL injection in Centreon’s updateGroups function. A high-privileged authenticated user can supply crafted input that is concatenated into SQL queries without adequate validation, allowing arbitrary SQL execution against the Centreon database. Because the vulnerable path can be leveraged beyond data access, successful exploitation may lead to arbitrary code execution in the context of the Centreon service account, with full confidentiality, integrity, and availability impact to the application and its monitored configuration data.

Why it matters to the business

Compromise of a Centreon monitoring server can undermine visibility into infrastructure health, expose credentials or configuration data stored by the monitoring platform, allow attackers to alter monitoring rules or suppress alerts, and potentially provide a foothold into systems monitored or managed through Centreon. Although exploitation requires authentication with high privileges and the vulnerability is not listed in CISA KEV, the EPSS probability is elevated, so internet-exposed or broadly accessible Centreon instances should be treated as a priority for remediation.

How an attack unfolds

An attacker first obtains or abuses a sufficiently privileged Centreon account. They then access functionality that reaches the updateGroups code path and submit a crafted value in a group-update request. Because the application fails to safely parameterize or validate the supplied string before constructing SQL, the database interprets attacker-controlled content as SQL. The attacker can use this to read or modify Centreon data and, depending on database permissions and deployment configuration, pivot from SQL execution to operating-system command execution or file creation, resulting in code running under the Centreon service account. Post-exploitation activity may include adding or changing accounts, extracting stored secrets, writing web-accessible files, disabling or modifying monitoring configuration, and using the monitoring server as a pivot point.

How to fix it

Upgrade Centreon to a version containing the upstream fix for the updateGroups SQL injection. For source-based deployments, ensure the code includes commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f or a later vendor-maintained release containing that change. If immediate upgrade is not possible, restrict Centreon administrative access to trusted networks, enforce MFA for privileged accounts, review and minimize administrative roles, disable unused accounts, and place the application behind VPN or other access control. Also rotate Centreon administrative credentials and any secrets stored in or accessible through Centreon if exploitation is suspected.

How to confirm the fix worked

Confirm the deployed Centreon code or package level includes the fix commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f or a vendor release that incorporates it. Review the updateGroups implementation to verify user-controlled values are parameterized or otherwise safely handled rather than concatenated directly into SQL. From an exposure perspective, identify all Centreon web interfaces, confirm whether they are reachable from untrusted networks, and verify only authorized users have high-privilege access. After patching, perform authenticated application testing of the affected group-update workflow and confirm SQL metacharacters are handled as data, not executed as query syntax.

Typical attack path

1. Obtain valid high-privilege Centreon credentials through phishing, credential reuse, session theft, or prior compromise.
2. Authenticate to the Centreon web interface or API.
3. Send a crafted request that reaches the updateGroups function with SQL metacharacters or injected SQL in a user-controlled field.
4. Execute unauthorized SQL against the Centreon database to enumerate users, configuration, credentials, and monitoring objects.
5. Escalate from database control to code execution where database privileges and deployment settings permit file write, command execution, or web shell placement.
6. Persist by modifying Centreon users, permissions, configuration, or scheduled monitoring actions.
7. Cover tracks by altering monitoring state, suppressing alerts, or deleting application, web, and database logs.

How to detect it

Investigate historical exploitation by correlating authenticated Centreon web requests with application, web server, database, and operating-system telemetry. Start with Apache or Nginx access logs for requests to Centreon group-management functionality or parameters containing SQL metacharacters, comments, time-delay functions, UNION queries, stacked statements, file-write attempts, or encoded payloads. Review Centreon application logs for group update errors, SQL exceptions, unexpected account or permission changes, and configuration changes that coincide with suspicious requests. Check database logs, if enabled, for unusual queries initiated by the Centreon application account, especially queries containing UNION SELECT, SLEEP, BENCHMARK, INTO OUTFILE, LOAD_FILE, or attempts to write into web-accessible paths. On the host, examine process creation telemetry for web server, PHP-FPM, database, or Centreon service accounts spawning shells, interpreters, download tools, or network utilities. Inspect Centreon webroots, plugin directories, temporary directories, and cron locations for recently created files, web shells, unauthorized scripts, or modified monitoring commands. Because exploitation requires authentication, also review successful logins, new sessions, privilege changes, and activity from unusual source IPs or user agents.

• updateGroups
• UNION SELECT
• UNION ALL SELECT
• SLEEP(
• BENCHMARK(
• INTO OUTFILE
• LOAD_FILE(
• INFORMATION_SCHEMA
• information_schema
• --
• #
• /*
• */
• ';
• %27
• %2D%2D
• %23
• /centreon/
• /usr/share/centreon/www/
• /var/log/centreon/
• /var/log/httpd/access_log
• /var/log/apache2/access.log
• /var/log/nginx/access.log
• php-fpm: pool
• www-data
• apache
• nginx
• /bin/sh -c
• /bin/bash -c
• /tmp/
• /var/tmp/
• curl
• wget
• nc
• ncat
• php -r
• python -c
• perl -e

What your security team should do

• Patch or upgrade all affected Centreon deployments, prioritizing internet-facing or broadly reachable instances.
• Verify the deployed code includes fix commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f or a later vendor release containing the fix.
• Audit privileged Centreon accounts, remove unnecessary administrative access, enforce MFA, and reset credentials for dormant or suspicious accounts.
• Review web, application, database, and system logs for suspicious authenticated requests involving updateGroups and SQL injection patterns.
• Search Centreon web directories and plugin/script locations for recently created or modified files that could represent web shells or persistence.
• Harden network access so Centreon administration is reachable only from trusted management networks or through a controlled access gateway.
• Rotate secrets stored in Centreon or used by Centreon if there is any indication of compromise.
• Monitor for unexpected child processes spawned by web server, PHP, database, or Centreon service accounts.