CVE-2026-110874 in Dolibarr
Summary
by MITRE • 10/15/2026
Dolibarr before 23.0.4 contains a PHP object injection vulnerability in jsonOrUnserialize() in functions.lib.php, which calls unserialize() without class restrictions when json_decode() fails. Attackers able to write stored extrafields, export configurations or blocked log entries can plant serialized objects that trigger gadget chains for code execution or file manipulation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Dolibarr versions prior to 23.0.4 represents a critical PHP object injection flaw located within the jsonOrUnserialize function found in functions.lib.php. This specific implementation error arises from an insecure deserialization pattern where the application attempts to decode data using json_decode first, and if that process fails or returns null, it falls back to calling unserialize without any restrictions on which classes can be instantiated. In secure software design, untrusted input should never be passed directly to a deserialization function unless strict allowlisting of permitted classes is enforced. By relying solely on the failure of JSON parsing as a trigger for PHP serialization processing, the application inadvertently exposes its internal object graph to manipulation by any actor who can inject crafted serialized strings into accessible data fields.
The operational impact of this vulnerability is severe because it allows authenticated attackers with specific write privileges to achieve remote code execution or arbitrary file manipulation on the target server. The attack vector relies on the ability to plant these malicious serialized objects within stored extrafields, export configurations, or blocked log entries. Extrafields in Dolibarr are custom fields that can be added to various entities such as invoices, third parties, and products, making them a common storage location for user-defined data. If an attacker has permission to create or modify these fields, they can embed a serialized PHP object containing a gadget chain—a sequence of existing application classes whose methods, when invoked during deserialization, perform unintended actions like executing system commands or writing files to the filesystem. Similarly, export configurations and blocked log entries provide additional entry points for injecting this malicious payload into the application's data stream.
This vulnerability aligns with CWE-502, which describes Deserialization of Untrusted Data, a category of weaknesses where an application deserializes untrusted data without sufficiently verifying that the resulting data will be valid. The exploitation technique also maps to MITRE ATT&CK techniques related to Command and Scripting Interpreter execution via object injection or file manipulation through stored payloads. Because the vulnerability depends on the failure of JSON decoding, it may bypass certain input validation mechanisms that only check for malformed JSON structures rather than inspecting the content for serialized PHP objects. This makes detection by standard web application firewalls more difficult unless they are specifically configured to detect PHP serialization patterns in POST or GET parameters and stored database fields.
Mitigation strategies must focus on immediate patching as well as architectural improvements to deserialization practices. The primary remediation is to upgrade Dolibarr to version 23.0.4 or later, where the jsonOrUnserialize function has been corrected to enforce class restrictions during unserialization. For environments that cannot immediately update, administrators should restrict access to extrafield management and log entry modification to only those users who absolutely require such privileges. Additionally, implementing a strict allowlist of permitted classes for any deserialization operation is essential. Developers should avoid using unserialize on user-supplied data entirely; instead, they should validate input formats strictly before processing or use safe alternatives that do not involve instantiating arbitrary PHP objects. Regular security audits and code reviews focusing on serialization functions can help prevent similar vulnerabilities in future development cycles.