Wheels Framework EUVD-2026-102600

Exploitable only against Wheels applications (versions 1.1 through 4.1.2) that use the framework's nestedProperties() feature with nested forms for hasMany, hasOne, or belongsTo associations; the flaw is that nestedProperties() resolves records by posted primary key without verifying ownership by the parent being saved. Requires an authenticated low-privileged user (PR:L) who can legitimately submit a nested form for their own parent. Deletion of other users' rows additionally requires allowDelete=true on the association; creation of attacker-chosen identities requires child models with composite primary keys not composed of foreign keys. Limiting factors: authentication is required, the application must actually employ nested properties/forms, and destructive deletion is gated on the allowDelete configuration - apps not using nestedProperties() are unaffected.

This is a genuine but conditionally-scoped authorization flaw (CWE-472, broken object-level authorization in Wheels' nestedProperties()), not an inflated high-CVSS issue. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N = 8.1 High) is internally consistent and aligns with the description: a low-privileged authenticated user working over the network can read, reassign, modify, or delete other tenants' hasMany/hasOne/belongsTo records by posting a primary key they do not own. The high I:H and C:H are justified because the attacker both discloses (reads via reassignment/editing) and tampers with other users' data. However, key prioritization signals are MISSING: no EPSS score, no CISA KEV listing, and no public POC were provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is therefore 'elevated where deployed' rather than 'urgent for everyone' - exploitation requires an application that actually uses nestedProperties() with nested forms, and deletion specifically requires allowDelete=true, so real-world impact depends heavily on how each Wheels app is built. The 'Information Disclosure' tag understates the issue, which is primarily unauthorized modification/reassignment/deletion (an IDOR-class authorization bypass) with disclosure as a secondary effect.

A multi-tenant application built on Wheels lets authenticated users edit their own parent record through a nested form. A logged-in attacker submits the nested form for their own parent but substitutes the primary key of a child row (or belongsTo record) belonging to another user, causing the framework to resolve and update, reassign, or (if allowDelete=true) delete that victim's record. No public exploit code was identified at time of analysis, but the attack requires only a crafted form submission with an altered primary-key value.