CVE-2026-22666: Dolibarr ERP/CRM RCE Vulnerability

CVE-2026-22666 Overview

Dolibarr ERP/CRM versions prior to 23.0.2 contain an authenticated remote code execution vulnerability in the dol_eval_standard() function. The vulnerability exists because the function fails to apply forbidden string checks in whitelist mode and does not detect PHP dynamic callable syntax. Attackers with administrator privileges can inject malicious payloads through computed extrafields or other evaluation paths using PHP dynamic callable syntax to bypass validation and achieve arbitrary command execution via eval().

Critical Impact

Authenticated attackers with administrative privileges can achieve arbitrary command execution on affected Dolibarr ERP/CRM installations, potentially compromising sensitive business data and gaining full control of the underlying system.

Affected Products

• Dolibarr ERP/CRM versions prior to 23.0.2

Discovery Timeline

• 2026-04-07 - CVE CVE-2026-22666 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-22666

Vulnerability Analysis

This vulnerability is classified as CWE-95 (Improper Neutralization of Directives in Dynamically Evaluated Code / Code Injection). The dol_eval_standard() function in Dolibarr ERP/CRM is designed to safely evaluate user-controlled expressions while preventing malicious code execution. However, the implementation contains critical flaws that allow attackers to bypass security controls.

When operating in whitelist mode, the function fails to properly apply forbidden string checks, creating a gap in the validation logic. Additionally, the function does not recognize or block PHP dynamic callable syntax, which can be leveraged to invoke arbitrary functions indirectly. This combination of weaknesses allows authenticated administrators to craft payloads that pass validation checks but ultimately execute malicious code through PHP's eval() function.

The attack requires network access and authenticated administrative privileges, but once exploited, it provides complete control over the application server with the potential for data exfiltration, lateral movement, and persistent access.

Root Cause

The root cause of this vulnerability lies in incomplete input validation within the dol_eval_standard() function located in htdocs/core/lib/functions.lib.php. The function's security checks were insufficient in two key areas:

1. Missing whitelist enforcement: Forbidden string checks were not consistently applied when the function operated in whitelist mode
2. Unrecognized PHP syntax: The validator did not account for PHP's dynamic callable syntax, which allows functions to be invoked through variable references and array-based callables

Attack Vector

The vulnerability is exploitable over the network by authenticated users with administrator privileges. Attack vectors include:

• Computed extrafields: Administrators can configure computed extrafields with malicious PHP expressions that bypass validation
• Evaluation paths: Any application feature that passes user-controlled input through dol_eval_standard() becomes a potential injection point

The attacker crafts a payload using PHP dynamic callable syntax that evades the security filters, which is then executed when the expression is evaluated by the underlying eval() call.

 		}
 		*/
 
+		// Check if there is PHP comments (can be used to obfuscate code)
+		if (strpos($s, '/*') !== false || strpos($s, '//') !== false) {
+			return 'Bad string syntax to evaluate (The comment string /* and // are not allowed): ' . $s;
+		}
+
 		// Check if we found a ? without a space before and after
 		$tmps = str_replace(' ? ', '__XXX__', $s);
 		if (strpos($tmps, '?') !== false) {

Source: GitHub Commit Update

The patch adds additional validation to detect PHP comments (/* and //) which could be used to obfuscate malicious payloads and bypass existing security checks.

Detection Methods for CVE-2026-22666

Indicators of Compromise

• Unusual computed extrafield configurations containing PHP callable syntax or obfuscated code patterns
• Web server logs showing requests to extrafield configuration endpoints with encoded or suspicious payloads
• Unexpected processes spawned by the web server process (PHP-FPM, Apache, nginx)
• Evidence of unauthorized file modifications or new files created in the Dolibarr installation directory

Detection Strategies

• Monitor application logs for errors related to dol_eval_standard() function execution failures or suspicious evaluation attempts
• Implement file integrity monitoring on Dolibarr core files, particularly htdocs/core/lib/functions.lib.php
• Review administrator activity logs for unusual extrafield creation or modification patterns
• Deploy web application firewall (WAF) rules to detect PHP code injection patterns in form submissions

Monitoring Recommendations

• Enable comprehensive logging for all administrative actions within Dolibarr ERP/CRM
• Configure alerts for any modifications to computed extrafield definitions
• Monitor outbound network connections from the Dolibarr server for potential data exfiltration or command-and-control activity
• Implement behavioral analysis to detect anomalous PHP process execution patterns

How to Mitigate CVE-2026-22666

Immediate Actions Required

• Upgrade Dolibarr ERP/CRM to version 23.0.2 or later immediately
• Audit all existing computed extrafield configurations for suspicious content
• Review administrator account access and remove unnecessary privileges
• Check web server and application logs for evidence of prior exploitation

Patch Information

The vulnerability has been addressed in Dolibarr ERP/CRM version 23.0.2. The fix enhances input validation in the dol_eval_standard() function by adding checks for PHP comment syntax that could be used for code obfuscation. Organizations should upgrade immediately by following the official release documentation available at the GitHub Release 23.0.2.

Additional technical details about the vulnerability and fix can be found in the GitHub Security Advisory and the VulnCheck Advisory.

Workarounds

• Restrict administrative access to trusted users only and implement multi-factor authentication
• Disable or limit the use of computed extrafields until the patch can be applied
• Place the Dolibarr installation behind a WAF with rules to block code injection attempts
• Implement network segmentation to limit the potential impact of a compromised Dolibarr server

# Example: Restrict access to Dolibarr admin pages via nginx
location ~ ^/admin/ {
    allow 10.0.0.0/8;
    deny all;
    # Additional security headers
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options DENY;
}