LORIS EUVD-2026-114517

Exploitation requires an authenticated LORIS account that already has some access to the Issue Tracker module (PR:L), and requires the attacker to call the issue_tracker backend edit endpoint directly, bypassing the frontend scope restriction. The flaw is only reachable where the Issue Tracker module is enabled; the official workaround is that deployments no longer using Issue Tracker can disable the module to remove endpoint access. Impact is limited to unauthorized modification of issue records (no data disclosure, no availability loss), and the attacker must hold valid credentials - limiting this to malicious or compromised insiders rather than anonymous internet attackers.

This is a moderate, low-priority access-control weakness (CWE-862, Missing Authorization) rather than a critical threat. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, base 4.3) shows the only consistent signals: network reachable, low complexity, but requiring an authenticated low-privilege account (PR:L), and impacting only integrity at a low level (C:N/I:L/A:N) - the attacker can alter issue data they shouldn't, but cannot read protected data or affect availability. The vuln.today decision label is 'this_month', not act_now or emergency, which aligns with the low impact. No EPSS score was supplied, the CVE is not in CISA KEV (no confirmed active exploitation), and the supplied references are all fix artifacts (advisory, PR #10531, patch commit, release tags) rather than exploit code. The signals are internally consistent - there is no CVSS/description conflict - and all point to a genuine but limited integrity flaw usable only by already-authenticated users with some issue-tracker access. Note the 'Authentication Bypass' tag is imprecise: this is an authorization/access-control failure for an authenticated user, not an authentication bypass.

An authenticated LORIS user who has legitimate access to the Issue Tracker but is scoped (via the frontend) to only certain issues crafts a direct backend edit request against the issue_tracker edit endpoint for an issue outside their permitted scope - for example an issue belonging to another site or project. Because the backend did not re-verify edit permissions, the change (status, assignee, center, comment, etc.) is accepted. No public exploit code identified at time of analysis; the available references are the patch and advisory, not working exploit tooling.