Dolibarr ERP/CRM EUVD-2026-102349

Exploitation requires an authenticated Dolibarr account (prior to version 23.0.4) with permissions to write one of the specific attacker-controlled sinks named in the advisory: stored extrafields, export configurations, or blocked log entries. The payload only reaches the vulnerable unserialize() call inside jsonOrUnserialize() when the stored value is NOT valid JSON (json_decode() must fail first), triggering the backward-compatibility fallback that deserializes without class restrictions. Successful code execution further depends on a usable PHP gadget chain being present in the loaded application/framework classes. Limiting factors: no unauthenticated path (PR:H), elevated write privileges on the targeted field are mandatory, and the attack complexity is high (AC:H/AT:P) because the attacker must both supply a non-JSON serialized payload and chain existing gadgets. Instances are only patched by upgrading to Dolibarr 23.0.4 or later.

This is a credible but conditional risk rather than a drop-everything emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:H/UI:N, VC:H/VI:H/VA:H) scores 7.5 and is internally consistent with the description: the vulnerability is network-reachable (it lives in a web application), but exploitation is gated behind high privileges (PR:H) and non-trivial preconditions (AC:H plus AT:P), namely the ability to write stored extrafields, export configurations, or blocked log entries - all operations that in Dolibarr require an authenticated, reasonably privileged user. The technical impact is full compromise (confidentiality, integrity and availability all High) because a successful PHP object injection can reach gadget chains for code execution or arbitrary file manipulation, which is consistent with the CWE-502 classification. Weighing the signals: no EPSS score was supplied, the CVE is NOT in CISA KEV, and no public proof-of-concept is referenced, so there is no evidence of active or imminent widespread exploitation. The dominant real-world limiter is the PR:H requirement combined with the need to reach an unserialize() path that only triggers when json_decode() fails - this is a classic post-authentication privilege-to-RCE escalation, most dangerous in multi-tenant or lower-trust-user Dolibarr deployments where a low-integrity authenticated account can nonetheless write the relevant fields. Net: a real priority for exposed/multi-user Dolibarr instances because a patch exists and the impact is RCE, but the authentication and complexity gates place it below an unauthenticated-RCE emergency.

An authenticated Dolibarr user with sufficient rights to edit a stored extrafield, an export configuration, or a blocked log entry writes a crafted serialized PHP object string into that field. When Dolibarr later retrieves the value and jsonOrUnserialize() runs, json_decode() fails on the non-JSON payload and the code falls back to unserialize() with no class restrictions, instantiating the attacker's object and triggering an available gadget chain for code execution or file manipulation. No public exploit code is referenced in the provided data, so weaponization effort would currently fall on the attacker.