CVE-2026-85214 is a high severity authorization flaw in vhr, an open source Java HR system. The PUT /hr/info endpoint accepts a profile ID in the request body, so any logged in user can overwrite someone else's profile or disable an administrator account. No fix is confirmed.
What's affected
- Product: vhr (lenve/vhr),
HrInfoControllerandHrMapper.xml. - Affected: commit 03abbd3 and earlier.
- Fixed version: none confirmed. Issue #349 was open when read, and the reporter said earlier emails got no reply.
- Privilege needed: any authenticated session, regardless of role, according to the issue.
Severity in the record: High, CVSS 8.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H). VulnCheck scores it 7.2 under CVSS v4. The record has 8.1 under CVSS v3.1.
Weakness class: CWE-639 (Authorization Bypass Through User-Controlled Key).
How to check if you're exposed
- Confirm the commit you deployed with
git log -1 --format=%h. - Search application logs for PUT requests to
/hr/infowhere the profile ID in the body differs from the session user. - Check recent changes to names, addresses and the enabled flag on accounts, especially administrators.
- Review whether a disabled administrator account could lock you out, and keep a documented recovery path.
What to do now
- Change the update handler to use the ID of the authenticated user and ignore any ID in the request body.
- Add a regression test with two users so one cannot edit the other.
- Put vhr on a private network or behind a VPN until patched.
- Audit HR profile records for unexpected edits and re-enable any accounts disabled by mistake.
- Watch the vhr repository for an official fix.
Why it matters
The update passes the object sent by the client straight to a mapper that writes by primary key. The key comes from the body, so the caller picks which row changes. The authenticated user's identity is never compared with it. This is CWE-639, insecure direct object reference, and it is one of the most common web flaws.
The impact is integrity and availability. Overwriting names and addresses damages HR data, and disabling an administrator account can deny access to the whole system. A related issue in the same project covers password changes. The record does not claim exploitation in the wild.
Quick check
What is the quickest fix for vhr users?
Make the controller use the logged in user's ID for the update and drop the ID from the request body, then add a test for it.
Sources
Last reviewed: 18 October 2026.
