CVE-2026-111445
8.1HighPublished 16 Oct 2026 · NVD status: Deferred · AI triage by gemini-3.8-flash
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- Low
- User interaction
- None
- Impact
- High impact on confidentiality, integrity
- Weakness
- CWE-669
Impact
Authenticated attackers can view, modify, or delete other users' or tenants' records by submitting out-of-scope primary keys to affected endpoints. This requires an account or access to supply key inputs to scoped finder operations.
Root cause
The findByKey() and exists(key=) methods replace incoming scope conditions with the primary-key lookup instead of combining them.
Affected systems
Wheels 4.0.0 through 4.1.2 before 4.2.0
CVSS v3.1 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Fix & remediation
Upgrade to Wheels 4.2.0 or later. If patching immediately is not possible, explicitly validate that the target record belongs to the current tenant or user before calling findByKey(), exists(key=), updateByKey(), or deleteByKey().
$ box install wheels@4.2.0AI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
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.