Live › vulnerability › CVE-2026-111447
Go to dashboardWheels (a CFML framework) resolves nestedProperties() records by the primary key a user posts, without checking they belong to the parent being saved. An authenticated user who can submit a nested form for their own parent can update, reassign, or (with allowDelete=true) delete another parent's child rows.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Applications running Wheels 1.1 through 4.1.2 that use nestedProperties() to save hasMany, hasOne or belongsTo associations from user-submitted forms. The risk is highest where a logged-in user can submit a nested form for a parent they own. Applications without nestedProperties() usage, or where only trusted staff submit nested forms, are less exposed.
No product ranges from the sources yet.
4.1.2 or earlier is affected, 4.2.0 is fixed.nestedProperties( and check whether allowDelete is set to true.4.2.0 or later.allowDelete=true on nested associations.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-111447")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.