CVE-2024-0637

What it actually does

CVE-2024-0637 is an authenticated SQL injection in Centreon’s updateDirectory function. The vulnerable code uses user-controlled input to construct SQL queries without sufficient validation or parameterization. A low-privileged authenticated attacker can manipulate the SQL query, potentially read or modify Centreon database contents, alter application state, and in the documented impact chain execute arbitrary code in the context of the Centreon service account. Because Centreon commonly has visibility into monitored infrastructure, compromise of the application can also expose credentials, monitoring data, configuration details, and integration secrets.

Why it matters to the business

Successful exploitation can turn a compromised Centreon account into full compromise of the monitoring platform, creating risk of operational disruption, credential theft, tampering with monitoring visibility, and pivoting into systems managed or observed by Centreon. Although this issue is not currently listed in CISA KEV and no public exploit maturity is provided, the EPSS score is high at 0.72319, indicating elevated likelihood of exploitation activity relative to most vulnerabilities. Since the issue has been public for a long period, exposed or unpatched installations should be treated as priority remediation candidates.

How an attack unfolds

An attacker first obtains valid Centreon credentials, such as through phishing, password reuse, credential theft, or abuse of an existing low-privileged account. After authentication, the attacker sends crafted input to functionality that reaches the updateDirectory code path. Because the application concatenates or otherwise embeds that input into SQL statements without adequate validation, the attacker can alter the intended SQL logic. The attacker may use this to enumerate database data, extract sensitive configuration and credential material, modify records, or stage follow-on actions. In the highest-impact scenario, the SQL injection is chained into code execution through database or application behaviors, resulting in commands or payloads running under the Centreon service account. From there, the attacker can persist, tamper with monitoring, access secrets, or pivot to connected infrastructure depending on local permissions and integrations.

How to fix it

Upgrade Centreon to a version that includes the fix for the vulnerable updateDirectory code path. For source or Git-based deployments, ensure the code includes commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f or a later trusted release containing that change. If immediate upgrade is not possible, restrict network access to the Centreon web interface, enforce multi-factor authentication, limit Centreon accounts to least privilege, review and remove unnecessary accounts, and place additional monitoring on authenticated requests to administrative or configuration-management functions. Compensating controls should not be considered a permanent substitute for applying the vendor fix because the flaw is in server-side query construction.

How to confirm the fix worked

Confirm the running Centreon code or packaged version includes the fix associated with commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f or a later vendor release. For Git deployments, verify the commit is present in the deployed branch and that the application has been redeployed or restarted as required. Review the vulnerable code path to confirm user input is handled through safe query construction, such as parameterized queries or equivalent escaping and validation. From an exposure standpoint, verify the Centreon interface is not unnecessarily internet-accessible, confirm authentication controls are enforced, and review whether any low-privileged user can still reach the relevant updateDirectory functionality. After patching, perform a controlled security test or application scan to confirm SQL metacharacters submitted to the relevant function are rejected, safely encoded, or handled without changing query behavior.

Typical attack path

1. Acquire valid Centreon credentials or compromise an existing Centreon user session.
2. Authenticate to the Centreon web application.
3. Reach the functionality that invokes the vulnerable updateDirectory function.
4. Submit crafted input containing SQL control characters or expressions that alter the backend query.
5. Use the SQL injection to enumerate data, extract secrets, or modify Centreon configuration records.
6. Chain database manipulation into application-level or service-account code execution where the environment permits it.
7. Establish persistence, tamper with monitoring visibility, or use exposed credentials and integrations for lateral movement.

How to detect it

Investigate whether authenticated users submitted suspicious input to Centreon functionality associated with updateDirectory. Useful log sources include Centreon application logs, web server access and error logs, PHP-FPM or application runtime logs, database query/error logs, authentication logs, and operating system process execution logs for the Centreon server. Look for authenticated requests containing SQL injection patterns such as single quotes, comment markers, UNION queries, boolean conditions, time-delay functions, file read/write functions, or stacked-query separators. Correlate these requests with database errors, abnormal response sizes, HTTP 500 responses, unusual delays, or follow-on changes to Centreon configuration. On the host, review for unexpected child processes spawned by web, PHP, database, or Centreon service accounts; unexpected files in web-writable directories; newly modified PHP files; unknown scheduled tasks or cron entries; and outbound connections from the Centreon server after suspicious authenticated activity. If database logging is available, search for anomalous queries referencing file operations, command-staging behavior, unexpected updates to configuration tables, or unusually broad SELECT statements. Because exploitation requires authentication, pay close attention to logins from unusual IP addresses, impossible travel, new sessions for dormant accounts, and administrative actions performed immediately after suspicious requests.

• updateDirectory
• UNION SELECT
• UNION ALL SELECT
• SLEEP(
• BENCHMARK(
• --
• #
• /*
• */
• OR 1=1
• ' OR '1'='1
• " OR "1"="1
• INTO OUTFILE
• LOAD_FILE(
• INFORMATION_SCHEMA
• HTTP 500
• SQL syntax
• mysql_fetch
• PDOException
• mysqli_sql_exception
• /var/log/centreon/
• /var/log/httpd/access_log
• /var/log/httpd/error_log
• /var/log/apache2/access.log
• /var/log/apache2/error.log
• /var/log/php-fpm/error.log
• /var/log/mysql/error.log
• /var/lib/centreon/
• /usr/share/centreon/
• /etc/cron.d/centreon
• www-data
• apache
• centreon

What your security team should do

• Prioritize patching or upgrading Centreon instances to a fixed release or to code containing commit b0c74f195b1b48c7af9ec168db3cfbcade99da7f, especially if the web interface is reachable from untrusted networks.
• Inventory all Centreon deployments, including source-built or Git-based installations, and verify whether each is running vulnerable code.
• Restrict access to the Centreon web interface through VPN, bastion access, IP allowlisting, or other administrative access controls.
• Audit Centreon user accounts for weak, reused, dormant, or overprivileged credentials; reset passwords and enforce MFA where supported.
• Review application, web server, database, and operating system logs for historical signs of authenticated SQL injection attempts or unexpected service-account activity.
• Rotate credentials and secrets stored in or accessible by Centreon if exploitation is suspected, including monitoring credentials, API tokens, database credentials, and integration secrets.
• Harden the Centreon service account so it has only the operating system and database permissions required for normal operation.
• Add SIEM detections for authenticated requests involving updateDirectory combined with SQL injection metacharacters, time-delay functions, file-write attempts, or unusual error responses.