CVSS 6.5 · Sensitive data exposure (CWE-200) · Fixed in Dolibarr 24.0.0
Every reply is supposed to pass a redactor that blacks out secrets. The Users redactor blacks out the password. The Members redactor, same job, next desk, forgot that one line, and hands the password verifier out with the card.
The attack in six steps
- Every API reply runs through a "cleaner". Its job is to strip secrets before anything is sent back.
- Line the two cleaners up side by side. The one for users against the one for members. (this is the break)
- The Users cleaner removes the stored password hash. Exactly as it should.
- The Members cleaner doesn't. One missing line, doing the identical job one desk over.
- A "read members" key receives every member's password verifier. And from the list route, all of them at once.
- Confirmed live, not a placeholder. Matched to the database, and it validated the real password. → credential exposure.
Before an application sends any record back to a caller, something has to decide what to leave out. Passwords, keys, the private machinery of an account, all of it is supposed to be stripped on the way out, by a step whose only job is redaction. When that step is thorough, you never think about it. When it isn't, secrets walk out in plain sight.
This is the story of two of those redactors, doing the same job for two similar kinds of record, where one remembered to black out the password and the other simply didn't, and how that one missing line handed every member's password verifier to anyone allowed to read a member card.
It is a simple example of how sensitive data exposure can happen inside an otherwise legitimate API response. The endpoint itself works as designed. The problem is that the Dolibarr security check responsible for removing sensitive credential data was incomplete.
Found by holding two things side by side
This finding didn't come from a clever attack. It came from comparison. Dolibarr redacts a user record and a member record with two separate pieces of code meant to do the same thing. So we put them next to each other and read them line for line.
The user redactor removed the stored password verifier before sending, exactly right. The member redactor, doing the identical job one desk over, didn't. One missing line, in one of two near-twin functions.
This is the kind of issue that can be missed by a straightforward application security assessment. Nothing needs to be injected or bypassed in the traditional sense. The vulnerability appears when two pieces of code responsible for protecting the same sensitive data are compared and found to enforce different rules.
What that one line leaks
The consequence is not subtle. An account holding nothing more than the right to read members, an ordinary, widely-granted permission, receives, along with each member's ordinary details, the stored verifier for that member's password. And because the same gap sits on the route that lists all members, you don't get them one at a time. You get the whole set in a single reply.
We confirmed the value was the real thing rather than a harmless placeholder by matching it back to the database and checking it corresponded to the member's actual password. It was live.
For a security researcher or penetration tester, that distinction matters. This was not simply a field that looked sensitive in a source-code review. We verified that the API returned real credential material and traced it back to the underlying application data.
The whole pattern in one line
If you want the entire theme of this research compressed into a single example, it is this one. The safe way already existed. The correct redactor was written, working, and sitting a file away. The neighbouring code that did the same job just skipped it. Not a hard problem, not a clever oversight, just a copy that wasn't quite a copy.
That is what “split-brain authorization” looks like at its smallest: two places responsible for the same rule, quietly disagreeing, with no one comparing them until someone does.
What closes it
The fix in 24.0.0 brings the member redactor in line with the user one, so the stored password material is stripped before any member record is sent, from single-record and list replies alike.
The lesson is almost embarrassingly practical: when two parts of a codebase are supposed to enforce the same rule, the highest-value test is often not an exploit at all. It is reading them side by side and asking whether they actually match. One of them got it right. Diffing it against its neighbour is how you find the one that didn't.
This is also why effective application penetration testing combines testing the running application with understanding how security controls are implemented. A response can look perfectly normal while still exposing sensitive data if one authorization or redaction path behaves differently from its counterpart.
The fix. Upgrade to Dolibarr 24.0.0. That closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest
