CVE-2026-111312 is a High severity (CVSS 7.7) missing authentication flaw in OpenHealth through 0.2.0. The per-record health data route has no login or owner check, so a known record ID can be read, overwritten or deleted. We could not confirm a fix.
What's affected
The record says OpenHealth through 0.2.0 is affected. The researcher write-up says the review was of the default branch, that no release tag had been published when it was written, and that the affected route is the per-record health data route in the API. We found no fixed version, so check the OpenHealthForAll/open-health repository.
The weakness is CWE-306, missing authentication for a critical function. The write-up also classes it as an insecure direct object reference. According to it, each medical record belongs to an author, but the handlers for reading, updating and deleting one record never check the session, and never limit the query to the author. The application's middleware excludes API paths from its login redirect, so the handler is the only gate, and it has none.
Severity differs by source. The record gives 7.7 (High), with high attack complexity because an attacker must know a record ID. VulnCheck lists 9.2 (Critical) on a CVSS 4.0 vector. Our title follows the record.
How to check if you're exposed
Find out whether you run OpenHealth and whether it is reachable. It is a self-hosted application, so check your own servers and containers.
docker ps --format "{{.Names}} {{.Image}}" | grep -i health
Then check the version or commit you deployed. Because the project had no release tags when the write-up was made, note the commit hash. If the application is reachable from the internet, treat it as exposed. If it is on a private network behind your own login or VPN, the risk is much smaller.
Check web server logs for requests to the health data route from clients that never logged in, and for PATCH or DELETE calls. The free in-browser dependency scan at gold.safeguard.sh/scan can match a manifest or lockfile against known CVEs without installing anything.
What to do now
- Take the application off the public internet, and place it behind a VPN or an authenticating reverse proxy.
- Check the repository for a fix and update once one is confirmed.
- Back up the database now, so records that are overwritten or deleted can be restored.
- Review health records for unexpected changes, and review access logs for requests from unknown addresses.
- If records of other people were stored, check your legal duties for reporting an exposure of health data with your counsel.
Why it matters
Medical records are among the most sensitive data a person has, and this flaw gives write and delete access as well as read. A record ID is not a secret, and even random identifiers get shared in logs and links. The check must be on the server.
This is the missing owner check that appears in the OWASP list of broken access control. Add it at the data access layer, so no handler can forget it. Self-hosted tools for personal data are usually run by individuals and small teams, who may not notice an exposed port. The record does not mark this CVE as known exploited, and none of the pages we read say it is.
Quick check
What can an attacker do?
Per the record, read another user's record and file metadata, replace it with arbitrary JSON, or delete it, if they know the record ID.
Is there a patch?
We could not confirm one, and the write-up says no release tag existed when it was written. Check the project repository.
Sources
Last reviewed: 18 October 2026.
