OpenHealth EUVD-2026-102476

Requires that the three /api/health-data/[id] route handlers (GET, PATCH, DELETE) are reachable, which the referenced middleware.ts omits from authentication coverage, and that the attacker possesses a valid HealthData record id - the sole gating prerequisite captured by CVSS AT:P. No authentication is required (PR:N) and no user interaction (UI:N) against a default OpenHealth deployment through version 0.2.0. The realistic limiting factor is id knowledge: if record ids are sequential or otherwise enumerable, exploitation scales to mass data theft/tampering; if they are high-entropy UUIDs, an attacker must first leak a valid id (e.g., via shared links, logs, or referrer leakage), narrowing exploitation to targeted abuse.

This is a genuine high-priority issue, not a CVSS-inflated paper risk. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VC:H/VI:H/VA:L) and CWE-306 (Missing Authentication) align tightly with the description: the /api/health-data/[id] handlers query by id with no session or authorId check, so a remote unauthenticated attacker can read, overwrite, or delete another user's medical records. The one meaningful brake is AT:P (Attack Requirements: Present), which reflects that the attacker must first know a valid HealthData record id - this is the IDOR prerequisite and the single factor separating this from trivial mass exploitation. No EPSS score, KEV listing, or explicit POC flag was supplied in the input, so exploitation probability cannot be quantified and active exploitation cannot be asserted. Signals are therefore consistent rather than conflicting: a confirmed, structurally simple auth-bypass against sensitive health data, tempered only by id-knowledge and the niche footprint of the product. The exploitability hinges on whether record ids are enumerable/predictable (sequential) versus high-entropy (UUID) - the input does not specify, so treat mass exploitation as plausible-but-unverified.

A remote unauthenticated attacker learns or guesses a valid HealthData record id and issues a GET to /api/health-data/[id] to read another patient's medical records and file metadata, then a PATCH to overwrite that record with arbitrary JSON or a DELETE to destroy it. Because the handlers skip session and authorId validation entirely (CWE-306), no login or user interaction is needed - the only prerequisite (reflected in CVSS AT:P) is possession of a valid id. A third-party technical write-up detailing the flaw exists, but no packaged public exploit code was indicated in the input.