The Back-Office Break-In: Nine Dolibarr Findings

By CodeAnt AI · Security Research

We went hunting for the security flaws that matter in the software real businesses run every day. In Dolibarr, the open-source ERP behind the invoices, payroll and bank files of thousands of small companies, we found nine. Most of them turned out to be the same mistake, wearing different clothes. All nine are fixed in Dolibarr 24.0.0.

Our security research combined source-code review with hands-on API security testing against a running Dolibarr instance, so we could validate not just whether a vulnerability existed, but what an attacker could actually do with it.

The pattern: one building, two ways into every room

Picture the office that runs a small company: a room for invoices, a room for payroll, a room for the member list. Almost every room has a locked door, and the lock works. Walk up without the right key and it stops you cold.

The trouble is that most rooms have a second way in: a service window, a side hatch, somewhere a different clerk handles the same paperwork and nobody remembered to put the same lock on that one. Eight of our nine findings are exactly this shape.

We call it split-brain authorization: two parts of the app write to the same records, and they disagree about who's allowed.

In security testing terms, these included authorization vulnerabilities, broken object-level authorization, mass assignment issues, and other API access-control flaws.

What made them interesting was not simply that a check was absent. In several cases, the application had the right security control in one path and failed to apply the same control in another.

The nine findings, one page each

Each finding has its own page, with the attack broken into three illustrated beats: the Setup, the Break, and the Impact.

CVE-2026–71503 · One link, opened once, mints a second admin

CVE-2026–71504 · The membership desk that could reset the admin's password

CVE-2026–71505 · The read desk checks your ID. The write desk doesn't.

CVE-2026–71506 · The wrong key on the lock

CVE-2026–71507 · Change one number, and the payroll run pays you

CVE-2026–71508 · Set your own salary — and the receipt hides it

CVE-2026–71509 · Approve your own expenses — and your whole team's

CVE-2026–71510 · Ask enough yes/no questions and you know everyone's salary

CVE-2026–71511 · Read a member's card, receive their password hash

The wall that was missing from all of them

Every one of these bugs passed a check. The link opened a page an admin is allowed to open. The membership key was allowed to add members. The search box was safe from the injection everyone worries about. What was missing sat one step further in: the question of which fields a request may write, and whose data those writes reach.

That is the part of application security that can be easy to miss when testing individual endpoints in isolation. A permission can be technically present and still protect the wrong action, the wrong object, or the wrong fields.

The lesson we keep writing down: when one door to a room is locked, go find every other door to the same room and check it too.

Want to know where your own app disagrees with itself? We combine reading the source with testing the running application, so a finding isn't "this line looks risky," it's "here's the request, and here's what it took over."

That's the approach we use in API penetration testing and security assessments to validate vulnerabilities in real application behavior. → Start with a free CodeAnt pentest

The fix. All nine are fixed in Dolibarr 24.0.0. If you run an affected build (through 25.0.0-alpha), upgrading closes every finding at once.

All testing was performed against an isolated local Dolibarr instance with synthetic data. No live or third-party system was ever contacted, and no generated payment file was ever sent. Findings were responsibly disclosed and fixed before publication.