CVE-2026-58376: Dolibarr SQL Injection in REST API Endpoints

Technical summary

The vulnerability stems from inadequate input sanitization in api_setup.class.php and api_multicurrencies.class.php. The sqlfilters query parameter is validated only for balanced parentheses, and matched triplets are rewritten, but any text outside the expected pattern—such as a UNION SELECT statement—passes through unmodified into the SQL WHERE clause. This classic second-order injection allows authenticated API consumers to compose queries that retrieve unauthorized data. The flaw affects Dolibarr versions through 23.0.3 and was corrected in commit 14db36e. The CWE classification (CWE-89: SQL Injection) confirms the core vulnerability type.

Business impact

Compromise of an API account can lead to unauthorized exfiltration of sensitive business data: customer information, financial records, credentials, and internal API keys. Stolen credentials may enable lateral movement or privilege escalation within connected systems. The risk is heightened in multi-tenant deployments where a single API breach could expose data across customer boundaries. For organizations using Dolibarr for order management, invoicing, or accounting, data loss and regulatory compliance violations (GDPR, PCI DSS) may ensue.

Affected systems

Dolibarr versions through 23.0.3 are affected. The fix is available in commit 14db36e and will be included in the next patched release; verify the exact version in the official Dolibarr advisory and release notes. Organizations running REST API integrations—particularly those exposing the setup or multicurrencies endpoints to external systems or delegating API token access—face the highest risk.

Exploitability

Exploitation requires valid API credentials, which restricts the attack surface to authenticated users or accounts whose tokens have been compromised. However, API tokens are often long-lived and may be embedded in integrations or third-party applications, increasing the likelihood of token disclosure over time. Once a token is obtained, the attack requires no special tools—a simple HTTP request with a malicious sqlfilters parameter suffices. Active exploitation is not known to be widespread (the vulnerability is not listed on CISA's KEV catalog), but the straightforward injection technique and high sensitivity of exposed data make it an attractive target for insiders or supply-chain attackers.

Remediation

Upgrade Dolibarr to a patched version released after commit 14db36e. If immediate patching is not feasible, restrict API token distribution, audit existing tokens for signs of misuse, and monitor REST API traffic for suspicious sqlfilters patterns (e.g., UNION, SELECT, SLEEP). Consider temporary disable of the setup and multicurrencies endpoints if they are not essential to operations. Rotate all API keys and database credentials as a precaution.

Patch guidance

Apply the patch from commit 14db36e or a subsequent official release. Test the patch in a non-production environment first to ensure compatibility with existing integrations. Review any scripts or applications that interact with the affected REST API endpoints to confirm they do not rely on the old validation behavior. After patching, invalidate and reissue API tokens to all consumers as a precautionary measure.

Detection guidance

Monitor REST API logs for suspicious sqlfilters parameters containing SQL keywords: UNION, SELECT, DROP, INSERT, UPDATE, SLEEP, BENCHMARK, or semicolons. Establish baseline API usage patterns and alert on unusual query complexity or volume. Enable database query logging to detect anomalous SELECT statements targeting sensitive tables (users, roles, credentials). Consider implementing a Web Application Firewall (WAF) rule to block sqlfilters input that does not conform to expected benign patterns. Audit API token creation, rotation, and revocation events.

Why prioritize this

Although the vulnerability requires prior authentication, the simplicity of exploitation and the high value of exposed data (credentials, keys, financial records) justify immediate attention. Organizations with public-facing or loosely-controlled API access, or those that have shared API tokens across multiple vendors or teams, should prioritize patching to reduce the window for token-based attacks. The CVSS score of 7.6 (HIGH) reflects moderate confidentiality impact offset by the authentication prerequisite.

Risk score, explained

The CVSS 3.1 score of 7.6 is driven by a High confidentiality impact (C:H), limited integrity impact (I:L), and limited availability impact (A:L). The attack vector is network-based (AV:N) with low complexity (AC:L), requiring login privileges (PR:L) but no user interaction (UI:N). The HIGH severity designation reflects the real-world risk to sensitive business data, though the authentication requirement prevents a critical score. Organizations handling PII or financial data should treat this as a priority despite the authentication gate.

Frequently asked questions