CVE-2024-23117

What it actually does

The flaw is an authenticated SQL injection in Centreon’s updateContactServiceCommands function. A highly privileged authenticated user can supply crafted input that is concatenated into SQL queries without sufficient validation, allowing manipulation of database statements. Because Centreon configuration data can influence command execution paths, successful exploitation can progress from database control to arbitrary code execution in the context of the Centreon service account. Impact includes confidentiality loss through database reads, integrity loss through modification of monitoring configuration and commands, and availability loss through service disruption or destructive database changes.

Why it matters to the business

A compromised Centreon instance can give an attacker control over a central monitoring platform, which often has visibility into critical infrastructure, credentials, hosts, services, and operational alerts. An attacker could suppress monitoring, alter alerts, steal configuration data, run commands through the monitoring service context, or use the server as a pivot point into managed environments. Although exploitation requires authentication with high privileges and the issue is not listed in CISA KEV, the EPSS score is elevated, the vulnerability has been public for a long period, and internet-facing or broadly accessible Centreon consoles should be treated as priority remediation targets.

How an attack unfolds

An attacker first obtains valid Centreon credentials with sufficient privileges to access contact or service command configuration functionality. They then submit crafted input to the vulnerable updateContactServiceCommands workflow. Because the input is not safely parameterized before being used in SQL construction, the attacker can alter the intended query logic. From there, they may read or modify Centreon database content, change monitoring configuration, inject or alter command definitions, or otherwise abuse database-backed configuration to cause command execution under the Centreon service account. After code execution, the attacker commonly attempts persistence, credential harvesting, lateral movement, and cleanup of obvious application or web logs.

How to fix it

Upgrade Centreon to a version or build containing the upstream fix. For source-based deployments, ensure the Centreon codebase includes commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f or a later vendor release that incorporates it. After upgrading, restart required Centreon web, application, broker, engine, and PHP services as directed by vendor documentation. If immediate patching is not possible, restrict access to the Centreon web interface to trusted administrative networks, enforce MFA for administrative accounts, review and reduce Centreon privileges, disable or tightly control contact/service command modification rights, and monitor for suspicious SQL-like input and unexpected command/configuration changes. Also rotate credentials that may be stored in or accessible from Centreon if compromise is suspected.

How to confirm the fix worked

Confirm the running Centreon version or source revision includes commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f or a later fixed release. Review deployed application files against the patched upstream code and verify that updateContactServiceCommands no longer builds SQL queries from unsanitized user-controlled strings. Confirm access controls are restricted so only intended administrators can modify contact service command settings. In a non-production test environment, use safe negative testing with benign SQL metacharacters to confirm the application rejects, escapes, or parameterizes input without SQL errors or behavior changes. Review web, application, and database logs after validation to ensure no SQL errors, unexpected configuration changes, or command executions occurred during testing.

Typical attack path

1. Acquire or compromise a privileged Centreon account.
2. Access the Centreon configuration area that updates contact service command settings.
3. Submit crafted SQL metacharacters or injected SQL expressions through the vulnerable updateContactServiceCommands input path.
4. Use SQL injection to read, modify, or corrupt Centreon database records.
5. Abuse modified monitoring configuration or command definitions to execute code as the Centreon service account.
6. Establish persistence, collect credentials or configuration secrets, and pivot to monitored assets if network permissions allow.
7. Remove or alter logs and configuration changes to reduce forensic visibility.

How to detect it

Investigate whether exploitation already occurred by correlating Centreon web access logs, Centreon application logs, PHP-FPM logs, Apache or Nginx logs, database logs, command history, process execution telemetry, and Centreon configuration audit records. Look for authenticated requests to contact or service command update workflows containing SQL metacharacters, SQL comments, stacked-query separators, time-delay functions, file read/write functions, or unusually encoded payloads. Review database logs for syntax errors, UNION-based probes, SLEEP or BENCHMARK calls, LOAD_FILE or INTO OUTFILE usage, unexpected updates to contact/service command tables, and changes made by administrative accounts at unusual times. Examine Centreon configuration for newly created or modified commands, notification commands, poller commands, macros, or service command mappings that invoke shells, download tools, scripting interpreters, reverse shells, or unexpected binaries. On hosts, hunt for child processes spawned by the web server, PHP-FPM, Centreon engine, Centreon broker, or Centreon service accounts, especially shells or network utilities. Also review authentication logs for suspicious privileged logins preceding configuration changes, and check whether monitoring alerts were disabled or modified around the same time.

• updateContactServiceCommands
• UNION SELECT
• UNION ALL SELECT
• INTO OUTFILE
• LOAD_FILE(
• SLEEP(
• BENCHMARK(
• --
• #
• /*
• */
• ; SELECT
• ; UPDATE
• ; INSERT
• ; DELETE
• information_schema
• /bin/sh
• /bin/bash
• bash -c
• sh -c
• curl http
• wget http
• nc -e
• ncat -e
• python -c
• python3 -c
• php -r
• perl -e
• socat TCP
• /var/log/centreon/
• /var/log/httpd/
• /var/log/apache2/
• /var/log/nginx/
• /var/log/php-fpm/

What your security team should do

• Inventory all Centreon deployments, including source-based or containerized installations, and identify instances reachable from untrusted networks.
• Patch or upgrade to a build containing commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f or later vendor-fixed releases.
• Prioritize internet-facing, shared-administration, or high-privilege monitoring deployments because Centreon often has broad operational visibility and trusted network access.
• Restrict Centreon administrative access using VPN, allowlists, MFA, and least-privilege role assignments.
• Audit Centreon users with privileges to modify contact, service, command, notification, or configuration objects.
• Review recent configuration changes for unauthorized command definitions, altered notification commands, disabled alerts, or suspicious contact/service mappings.
• Hunt historical logs for SQL injection patterns and unexpected command execution by Centreon, web server, PHP-FPM, or database service accounts.
• Rotate Centreon administrative credentials and any secrets stored in Centreon if exploitation cannot be ruled out.
• Enable database query logging or application-level audit logging temporarily where feasible to support post-patch validation and threat hunting.
• Document compensating controls if patching is delayed, and track remediation to closure despite the vulnerability not currently being listed in CISA KEV.