CVE-2024-23118

What it actually does

The flaw is an authenticated SQL injection in Centreon’s updateContactHostCommands function. User-controlled input is inserted into SQL queries without sufficient validation or parameterization, allowing a privileged authenticated attacker to alter query logic. Because the vulnerable code path can be leveraged beyond data access, successful exploitation may result in arbitrary code execution in the context of the Centreon service account, with full confidentiality, integrity, and availability impact to the Centreon application and its underlying data store.

Why it matters to the business

A compromised Centreon instance can undermine monitoring, alerting, and operational visibility across infrastructure. An attacker with sufficient Centreon privileges could access or alter monitoring configuration, disable or manipulate alerts, tamper with host and service definitions, steal sensitive operational data, or execute code from the application context. Although exploitation requires authentication with high privileges and the vulnerability is not currently listed in CISA KEV, the EPSS score is elevated and the issue has been public for a long period, so exposed or unpatched deployments should be treated as a meaningful risk.

How an attack unfolds

An attacker first obtains or already possesses a privileged Centreon account capable of reaching the vulnerable host-command contact management functionality. The attacker submits crafted input to the updateContactHostCommands workflow that is incorporated into a backend SQL statement without proper sanitization. By manipulating the resulting query, the attacker can read or modify Centreon database content and, depending on database permissions and application behavior, pivot from SQL injection to command or code execution under the Centreon service account. After execution, the attacker may establish persistence, modify monitoring objects to hide activity, harvest configuration and credentials accessible to the application, or disrupt monitoring services.

How to fix it

Upgrade Centreon to a version containing the upstream fix for this issue. For source-based deployments, ensure the codebase includes commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f or a later release that incorporates it. Remove duplicate or stale application code, restart affected Centreon web/application services after patching, and verify that all web nodes in clustered or load-balanced deployments run the fixed code. If immediate patching is not possible, restrict Centreon access to trusted administrative networks, enforce strong authentication and least privilege for Centreon users, review and reduce accounts with high administrative privileges, monitor the vulnerable workflow closely, and consider temporarily limiting access to contact/host command administration functions.

How to confirm the fix worked

Confirm the installed Centreon version or source revision includes commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f or a later vendor release containing the fix. Review application code or vendor release notes to ensure updateContactHostCommands no longer builds SQL queries from unsanitized user-controlled strings and instead uses safe query construction. Validate that every Centreon web node has been updated, caches have been cleared where applicable, and services have been restarted. From a defensive test perspective, authenticated requests containing benign SQL metacharacters to the affected workflow should not produce SQL syntax errors, database errors, abnormal HTTP 500 responses, or changes outside the intended update action.

Typical attack path

1. Gain authenticated access to Centreon with sufficient privileges to invoke the vulnerable contact host command update functionality.
2. Identify a reachable Centreon interface or request path that calls updateContactHostCommands.
3. Submit crafted input that changes the structure or behavior of the SQL query generated by the application.
4. Use the SQL injection to access or modify Centreon data, application configuration, or database-resident control paths.
5. Escalate the database manipulation into arbitrary code execution in the context of the Centreon service account where the deployment permits it.
6. Cover tracks by altering monitoring configuration, deleting application evidence, or changing alerts and host command assignments.

How to detect it

To assess whether exploitation has already occurred, review Centreon web access logs, Centreon application logs, database logs, authentication logs, and operating system process/audit logs for the period before patching. Focus on authenticated requests invoking updateContactHostCommands, especially requests followed by SQL errors, HTTP 500 responses, unusual configuration changes, or unexpected command execution. Correlate suspicious requests with Centreon user sessions and source IP addresses. Examine database logs for malformed queries, stacked-query attempts, unusual writes to contact, host, command, or configuration-related tables, and unexpected use of database features that can write files or execute external programs. On the host, look for unexpected child processes spawned by the web server, PHP-FPM, or Centreon service account, new or modified files in web-accessible directories, unexplained cron entries, reverse-shell tooling, and unauthorized changes to Centreon monitoring configuration. Because no specific public exploitation campaign or KEV entry is provided, detections should emphasize behavior: SQL injection syntax in authenticated Centreon requests, anomalous administrative changes, and post-exploitation execution artifacts.

• updateContactHostCommands
• b0c74f195b1b48c7af9ec168db3cfbcade99da7f
• /var/log/centreon/centreon-web.log
• /var/log/centreon/centreontrapd.log
• /var/log/httpd/access_log
• /var/log/httpd/error_log
• /var/log/apache2/access.log
• /var/log/apache2/error.log
• /var/log/mysql/mysql.log
• /var/log/mariadb/mariadb.log
• SQL syntax
• You have an error in your SQL syntax
• mysqli_sql_exception
• PDOException
• UNION SELECT
• SLEEP(
• BENCHMARK(
• INTO OUTFILE
• LOAD_FILE(
• information_schema
• xp_cmdshell

What your security team should do

• Prioritize patching Centreon instances, especially internet-accessible systems, systems reachable from broad internal networks, and systems used for enterprise-wide monitoring.
• Inventory all Centreon deployments, including source-based installations, and verify whether each includes fixed commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f or a later corrected release.
• Review Centreon administrative accounts and remove unnecessary high-privilege users because exploitation requires authenticated high-privilege access.
• Search historical web, application, database, and OS logs for suspicious use of updateContactHostCommands, SQL errors, unexpected configuration changes, and post-exploitation process activity from the Centreon service account.
• Harden access to Centreon with network allowlisting, MFA where supported, centralized authentication controls, and session monitoring.
• Create detections for SQL injection patterns in Centreon requests and for unexpected child processes spawned by web or Centreon service accounts.
• Back up Centreon configuration and database content before patching, then compare critical monitoring objects after patching for unauthorized changes.