CVE-2026-111447 in Wheels
Summary
by MITRE • 10/16/2026
Wheels 1.1 through 4.1.2 resolves nestedProperties() records by posted primary key without checking that they belong to the parent being saved. A user able to submit a nested form for their own parent can update and reassign another parent's hasMany or hasOne rows, or delete them when allowDelete=true. Nested belongsTo records can also be edited by posting another associated record's key. New child rows with composite primary keys not made up of foreign keys retain posted key values, allowing the request to choose their identity. This is fixed in 4.2.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified within Wheels framework versions 1.1 through 4.1.2 constitutes a critical Broken Access Control flaw rooted in insufficient validation of object ownership during nested property persistence operations. The core technical deficiency lies in the handling of primary keys for associated records, specifically those managed via hasMany or belongsTo relationships. When an application processes a POST request containing data for nested properties, the framework resolves these records based solely on the provided primary key values without verifying that the target record is actually owned by the parent entity currently being saved. This architectural oversight effectively bypasses standard authorization checks, allowing any authenticated user who can submit a form to manipulate database rows associated with other users or entities within the same application context.
In practical operational terms, this flaw enables an attacker to perform unauthorized updates and reassignments of related data structures. For instance, if a parent entity has a one-to-many relationship defined as hasMany, a malicious actor submitting a nested form for their own record can specify primary keys belonging to another user's records in the same table. The framework will then update or delete those foreign-owned rows without raising an error or rejecting the request. This capability extends to deleting associated data entirely when the configuration allows deletion via allowDelete=true, leading to potential data loss and integrity violations across multiple user accounts simultaneously.
The impact is further exacerbated by the handling of belongsTo relationships and composite primary keys. In cases where nested records are defined as belonging to a parent, an attacker can edit these associations by posting identifiers for unrelated associated records, effectively hijacking foreign key constraints. Additionally, when creating new child rows that utilize composite primary keys not composed entirely of foreign keys, the framework retains the posted key values rather than generating secure, unique identifiers. This behavior allows requesters to arbitrarily choose the identity and database location of newly created records, which can lead to conflicts with existing data or intentional corruption of the dataset structure by overwriting critical entries with crafted payloads.
From a classification perspective, this vulnerability aligns directly with CWE-269 Improper Privilege Escalation and CWE-352 Cross-Site Request Forgery if exploited via forged requests, though it is primarily an issue of server-side authorization failure akin to CWE-862 Missing Authorization. In the context of the MITRE ATT&CK framework, this behavior facilitates lateral movement within a database schema and data exfiltration or modification through unauthorized access patterns, specifically mapping to techniques involving manipulation of application logic to bypass intended security controls. The lack of ownership verification represents a fundamental failure in implementing secure object reference mappings, which is a common pitfall in frameworks that automate persistence based on form input without rigorous context validation.
Mitigation strategies must focus on enforcing strict ownership checks at the framework level or within individual model implementations. Developers should ensure that any operation involving nested properties explicitly validates that the target record's owner ID matches the current user's session identity before allowing updates, reassignments, or deletions. Upgrading to version 4.2.0 of Wheels is the primary remediation step as it addresses these validation gaps by implementing proper ownership verification during the resolution and persistence phases. For applications unable to upgrade immediately, manual intervention in model methods responsible for saving nested properties can provide a temporary fix by adding explicit checks that compare the foreign key values against authorized records associated with the current parent entity before proceeding with database operations.