CVE-2026-85182 is a high severity authorization flaw in vhr, an open source Java HR system. The PUT /hr/pass endpoint takes the account ID from the request body and never checks it belongs to the caller. No fixed release is confirmed, so teams running vhr should add the check themselves.
What's affected
- Product: vhr (lenve/vhr),
HrInfoControllerandHrService. - Affected: commit 03abbd3 and earlier.
- Fixed version: none confirmed. The public issue (#350) was still open when read, and the reporter noted that the maintainers had not responded to an earlier email.
- Condition in the record: the caller needs the target account's current password, which is why the record rates attack complexity High.
Severity in the record: High, CVSS 7.5 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). VulnCheck scores it 7.7 under CVSS v4, against 7.5 under v3.1 in the record.
Weakness class: CWE-639 (Authorization Bypass Through User-Controlled Key).
How to check if you're exposed
- Confirm which commit of vhr you deployed. In a git checkout,
git log -1 --format=%hprints it. - Search the application and your gateway logs for PUT requests to
/hr/passwhere the account ID in the body differs from the session user. - Check whether the password change route sits behind any role mapping. The issue says it does not, so every logged in user can reach it.
- List accounts that share passwords with others, since the flaw needs a known current password.
What to do now
- Patch your copy of the code so the service uses the authenticated principal's ID and ignores the ID in the request body.
- Add a test that a user cannot change another account's password.
- Until patched, limit who can log in to vhr and put the application on a private network.
- Force password changes on administrator accounts and review recent password change events.
- Watch the vhr repository for an official fix.
Why it matters
This is the pattern called insecure direct object reference, listed as CWE-639. The controller trusts an identifier the client sends, then the service looks up that account and checks the old password against it. The caller's own identity is never compared. It takes one line to fix, and it is easy to miss because the feature works for honest users.
Authorization must come from the session, not from the request. A good code review rule is that no endpoint that changes a user record may read the user ID from the body. The same repository has a sibling issue covering profile edits, covered in another post in this series. The record does not claim exploitation in the wild.
Quick check
Does the attacker need to know the victim's password?
Yes. The request must supply the target account's current password, which is why attack complexity is rated High in the record.
Sources
Last reviewed: 18 October 2026.
