LORIS EUVD-2026-114516

Requires (1) a valid authenticated LORIS account - the attacker is already logged in, but lacks the imaging_browser edit permission that the frontend enforces (PR:L), and (2) the LORIS API to be enabled on the deployment. When both hold, the attacker can edit imaging data through the API regardless of the imaging_browser edit restrictions, against versions 22.0.0 through 28.0.1 (fixed in 27.0.4 and 28.0.2). Limiting factors that reduce real-world risk: valid credentials are mandatory (no unauthenticated path), the impact is confined to imaging_browser data editing, and deployments that no longer use the API can disable it per the vendor workaround to remove the endpoint entirely. The vendor fix (upgrading to 27.0.4/28.0.2) is the complete remediation.

This is a missing-authorization flaw (CWE-862) in the LORIS imaging_browser API: the API path does not enforce the frontend edit-permission checks, so any authenticated API caller can modify imaging data they should not be able to edit. The supplied CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L, 6.3 Medium) indicates network-reachable, low-complexity exploitation requiring low privileges (PR:L) and no user interaction - consistent with an authenticated-user authorization gap rather than a remote-unauthenticated issue. The vuln.today decision label is 'this_month' (not act_now/emergency), and no EPSS score, no CISA KEV listing, and no working exploit code were provided, so there is no signal of active or widespread exploitation. The references are patch/commit/advisory links (a fix PR and commit), not a proof-of-concept exploit. Net: a genuine but moderate access-control issue whose real-world risk is bounded by the requirement for an existing authenticated account and an enabled API; it is a scheduled-remediation priority, not a drop-everything emergency. Note the mechanism is well-described (authorization not checked on the API editing path), so there is no conflict between the vector and the description; the main unknowns are exploitation probability (no EPSS) and in-the-wild activity (no KEV).

An attacker holding a legitimate but under-privileged LORIS account - one without imaging_browser edit rights - authenticates to the API and issues requests to the imaging_browser editing endpoint to alter imaging data (e.g., QC status or imaging records) that the web UI would have blocked. Because AC:L and no user interaction are required, the request succeeds directly once authenticated. No public exploit code was identified; only the vendor fix commit and PR are public.