Wheels 4.x uses scope rules to restrict data operations to the owning tenant. The library replaces the incoming scope condition with a primary-key condition in the helper functions findByKey() and exists(key=). For exists(key=), when error information is disabled a request for a key that is outside the current scope will incorrectly return true instead of throwing an error. This allows an application that relies on these scope checks for tenant or ownership authorization to load, update, or delete a record belonging to another tenant or user. The flaw arises from improper handling of query conditions and is a classic example of an Authorization Bypass rooted in faulty input validation (CWE‑669).

The Wheels library versions 4.0.0 through 4.1.2 are affected. Version 4.2.0 implements a fix that combines key conditions with the incoming scope, as well as updates related finders and mutator functions. No other scope‑aware methods are impacted.

The CVSS score of 8.1 indicates a high severity vulnerability. The EPSS score is < 1% (0.00278), indicating a very low exploitation probability, but this does not eliminate risk given the severe impact potential. The flaw is not listed in the CISA KEV catalog, suggesting no confirmed large‑scale attacks yet. The likely attack vector is a crafted request that supplies an out‑of‑scope key; the application accepts the result of exists(key=) or findByKey() and performs data operations without proper authorization checks. The 4.2.0 release resolves the issue by ensuring key constraints are enforced together with scope constraints.