CVE-2026-111445 in Wheels
Summary
by MITRE • 10/16/2026
Wheels 4.0.0 through 4.1.2 before 4.2.0 replaces incoming scope conditions with a primary-key condition in findByKey() and exists(key=). For exists(key=), production with error information disabled returns true for an out-of-scope key instead of throwing. Applications relying on scopes for ownership or tenant authorization can therefore load and subsequently modify or delete another user's or tenant's record when the key comes from a request. The 4.2.0 fix combines key conditions with incoming scope, query-builder or where conditions in findByKey(), exists(key=), updateByKey() and deleteByKey(). Other scope-aware finders, aggregates, updateAll() and deleteAll() are not affected.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in Wheels framework versions 4.0.0 through 4.1.2 represents a critical failure in access control logic, specifically within the methods findByKey(), exists(key=), updateByKey(), and deleteByKey(). This flaw stems from an incorrect implementation of scope-based filtering mechanisms that are intended to enforce data isolation between tenants or users. In these affected versions, when a request includes both a primary key identifier for record retrieval and a predefined scope condition designed to limit the query results to authorized entities, the framework erroneously discards the incoming scope conditions entirely. Instead, it replaces them with a simple equality check against the provided primary key. This behavior fundamentally undermines the security model of multi-tenant applications or systems relying on scopes for ownership verification, as it allows any valid primary key from an external request to bypass tenant-specific restrictions.
The operational impact of this vulnerability is severe and directly leads to broken access control scenarios where attackers can perform unauthorized data manipulation. For instance, in the exists(key=) method, if error information is disabled in production environments, the function returns true for a key that falls outside the authorized scope rather than throwing an exception or returning false. This silent failure makes detection difficult during runtime testing and allows downstream logic to proceed under the assumption that the record belongs to the current user or tenant. Consequently, applications can load records belonging to other users, which may then be modified or deleted via subsequent calls to updateByKey() or deleteByKey(). Since these methods also suffer from the same scope replacement flaw, an attacker with knowledge of a target resource's primary key can directly alter or destroy data that they should not have access to, leading to potential data breaches and integrity violations.
From a technical perspective, this issue aligns with CWE-284 Improper Access Control and CWE-601 URL Redirection to Untrusted Site (if the key is derived from user input without validation), though it is more accurately categorized under CWE-918 Server-Side Request Forgery principles applied to internal data access or simply as a logic flaw in authorization checks. In terms of the MITRE ATT&CK framework, this vulnerability facilitates lateral movement within an application's data layer and can be exploited for Data Exfiltration (T1530) or Impact via Data Manipulation (T1485). The root cause lies in how the query builder constructs SQL statements; by stripping out the scope-based WHERE clauses that enforce tenant isolation, the database engine executes queries against a broader dataset than intended. This is particularly dangerous because it affects core data access methods used frequently throughout application logic, increasing the attack surface significantly for any developer relying on these convenience functions without implementing additional manual checks.
The resolution provided in Wheels version 4.2.0 addresses this by modifying the query construction process to combine key conditions with incoming scope conditions and other where clauses. This ensures that even when a specific primary key is requested, the database engine still applies all necessary filters defined by the current scope before returning results or executing updates. It is important for developers to note that while findByKey(), exists(key=), updateByKey(), and deleteByKey() were directly impacted, other scope-aware finders, aggregate functions, as well as bulk operations like updateAll() and deleteAll() remain unaffected because they do not rely on the same flawed key-replacement logic. Organizations using affected versions must upgrade to 4.2.0 or later immediately to restore proper data isolation guarantees. Until an upgrade is performed, developers should avoid relying solely on these methods for security-critical operations and instead implement explicit manual scope checks in their application code to verify ownership before processing any request-derived identifiers.