Wheels Framework EUVD-2026-102607

Requires an authenticated low-privilege session (PR:L) in a Wheels 4.0.0-4.1.2 application that relies on scope conditions for ownership or tenant authorization AND passes request-supplied keys into findByKey(), exists(key=), updateByKey(), or deleteByKey(). The exists(key=) information-leak path additionally requires production mode with error information disabled, where it returns true for an out-of-scope key instead of throwing. LIMITING FACTORS: applications that perform explicit ownership checks rather than depending on scoped finders are not exploitable; the unaffected methods (other scope-aware finders, aggregates, updateAll(), deleteAll()) provide no path; and the attacker must already hold a valid authenticated account on the target tenant-aware application.

This is a genuine access-control (IDOR/broken object-level authorization) flaw, not merely a high-CVSS-but-low-risk issue, though its real-world urgency is tempered by prevalence and exploitation conditions. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N = 8.1) indicates a network-reachable, low-complexity attack requiring only low privileges (PR:L) and no user interaction, yielding high confidentiality and integrity impact - fully consistent with an authenticated tenant user reading, modifying, or deleting another tenant's record. No EPSS score, CISA KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the risk is therefore driven by the inherent ease of abuse rather than observed in-the-wild activity. One nuance to verify: the input tag labels this 'Information Disclosure,' but the description explicitly includes modify and delete of out-of-scope records (via updateByKey()/deleteByKey()), so the integrity impact is real and the issue is broader than pure disclosure - treat it as broken access control. Exploitation is gated on an application design pattern (reliance on scopes for ownership/tenant authorization plus request-supplied keys), so not every Wheels deployment is affected.

In a multi-tenant Wheels application that enforces ownership by chaining scope conditions onto findByKey()/exists(key=)/updateByKey()/deleteByKey(), an authenticated low-privilege user alters a record identifier in a request (e.g., /orders/edit?key=1042) to one belonging to another tenant. Because the finder replaces the scope condition with a bare primary-key condition, the framework loads the out-of-scope record and the application then displays, updates, or deletes the victim's data. No public exploit code was identified, but abuse requires only a modified request parameter against a vulnerable authorization pattern.