CVE-2019-25710 is a SQL injection in Dolibarr ERP/CRM 8.0.4, scored 8.2 (high). The rowid parameter of the admin dict.php page reaches a database query unsafely. The record names no fixed release, so move to a currently supported Dolibarr version and confirm the details on the project site.
What's affected
The record lists Dolibarr ERP/CRM 8.0.4. The vulnerable code is the dict.php endpoint in the admin area, and the parameter is rowid, sent as a POST value. The record says error based extraction is possible.
The CVSS vector is AV:N/AC:L/PR:N/UI:N, but the described endpoint sits in the admin area, so check carefully how your instance protects that path. The record does not name a fixed version. Dolibarr 8.0.4 is an old release, so a supported current version is the sensible target in any case.
How to check if you're exposed
If you run Dolibarr, find your version.
- Sign in as an administrator and open the About page, or read the version constant in the file htdocs/filefunc.inc.php on the server.
- If the version is 8.0.4, you are in scope. Older and newer releases are not named in the record, so check the project advisories for them.
- Look in web server logs for POST requests to the admin dict.php page from unfamiliar addresses.
- Check whether the admin path is reachable from the internet.
What to do now
- Identify every Dolibarr installation and its version.
- Back up the database and documents directory.
- Upgrade to the latest supported release, following the project upgrade notes, and test the upgrade on a copy first.
- Restrict the admin area by IP address or VPN while you upgrade.
- Review administrator accounts and rotate their passwords, since the database holds credentials and business data.
Why it matters
The weakness is CWE-89, SQL injection. The application builds a database query by putting request data straight into the query text. The database cannot tell which part is the developer's instruction and which part came from the visitor, so crafted input can change what the query does.
Dolibarr stores customer records, invoices and supplier data. Even a flaw that mainly exposes information is serious for an ERP system, because the data in it is commercially sensitive and often regulated.
The fix for this class is well understood. Use parameterized queries or prepared statements so that input is always treated as data, validate values against an allowlist where only a few are valid, and give the application database account only the rights it needs. None of this is complicated, but it has to be applied to every query in the code base, which is why one reported parameter is often a sign of others.
Quick check
Is this fixed in a later release?
The record does not say. Upgrade to a current Dolibarr version and check the project advisories to confirm.
Sources
Last reviewed: 19 October 2026.
