Dolibarr ERP CRM EUVD-2026-95209

Requires an authenticated Dolibarr session with at least read-only access to the target object. Exploitation specifically needs the attacker to reach htdocs/core/ajax/updateextrafield.php and submit objectType, objectId, field and value POST parameters for an object (third party, product, member, project, or contact) that the account is permitted to VIEW; writes are limited to extrafields on those already-viewable records. Limiting factors: the account must be valid and authenticated (not exploitable by anonymous/unauthenticated attackers), the target object must be within the user's read scope, and affected versions are Dolibarr before 24.0.2 - deployments on 24.0.2 or later with the restrictedArea() 'write' mode fix are not vulnerable. No user interaction by a victim is required.

This is a moderate-risk, low-impact authorization flaw rather than a high-priority emergency. The vendor-assigned CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and score of 5.3 are internally consistent with the description: exploitation is network-reachable and low-complexity, but requires an authenticated session (PR:L), and impact is confined to integrity of a limited subset of data (VI:L, with VC:N and VA:N - no confidentiality or availability loss). The SSVC/real-world exploitation signals are weak: there is no CISA KEV listing and no public exploit identified, so there is no evidence of active exploitation or automatable mass-exploitation. No EPSS score was provided in the input, so exploitation probability cannot be quantified. The key limiting factor - and the reason this is not a critical issue despite being trivially triggerable - is that an attacker must already hold a valid low-privilege (read-only) account and can only modify extrafields on objects they can already view, so it is a privilege-boundary/data-tampering bug, not a path to code execution, data theft, or full account takeover. Treat as a routine-to-moderate patching priority, elevated only in multi-tenant or large-user Dolibarr deployments where read-only accounts are widely issued.

An attacker who has been granted a read-only Dolibarr account (e.g., a limited internal user, contractor, or low-trust tenant) crafts an HTTP POST to htdocs/core/ajax/updateextrafield.php supplying objectType, objectId, field and value parameters for a third party, product, member, project, or contact they can view. Because the endpoint only checked read permission before writing, the extrafield value is persistently modified despite the user lacking write rights. No public exploit code is identified at time of analysis, but the attack is a simple authenticated HTTP request requiring no special tooling.