Wheels
Monthly
Broken object-level authorization in the Wheels CFML framework (versions 1.1 through 4.1.2) allows an authenticated low-privileged user to tamper with other users' associated records through nested forms. The nestedProperties() helper resolves nested hasMany, hasOne, and belongsTo records by the primary key posted in the request without verifying that those rows belong to the parent record being saved, so an attacker who can legitimately submit a nested form for their own parent can reassign, edit, or - when allowDelete=true is configured - delete another parent's rows, and can also create new child rows with attacker-chosen identities when the child model uses a composite primary key that is not composed of foreign keys. The issue carries an assessed CVSS of 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), requires authentication and actual use of nestedProperties() with nested forms, and is fixed in Wheels 4.2.0; no public exploit identified at time of analysis.
Remote, unauthenticated attackers can access password-less development tools under /wheels/* in Wheels 4.0.0 through 4.1.2 when enablePublicComponent=true (the default in development mode), exposing application settings, environment and datasource details, and routes, and allowing them to start test runs that may write to the real application database. This incorrect authorization flaw (CWE-863) does not affect production-mode deployments by default, and the separately protected migrator and CLI endpoints are not impacted. No public exploit identified at time of analysis.
Broken object-level authorization in the Wheels (CFML) framework 4.0.0 through 4.1.2 lets an authenticated low-privilege attacker supply a record key to findByKey(), exists(key=), updateByKey(), or deleteByKey() and have the framework drop the application's scope condition (such as a tenant or owner filter), enabling read, modification, or deletion of another user's or tenant's record. The flaw is remotely exploitable (AV:N, PR:L, no user interaction) with high confidentiality and integrity impact but no availability impact, and the exists(key=) variant additionally leaks record existence by returning true for an out-of-scope key when the application runs in production mode with error information disabled. No public exploit code or CISA KEV entry is identified at time of analysis, and exploitation requires an application that relies on Wheels scopes for ownership or tenant authorization and passes request-supplied keys into the affected methods.
SQL injection in the Wheels CFML framework through 4.1.2 lets remote attackers manipulate SQL statements when an application feeds request data into inline-literal query paths - opt-in parameterize=false queries, IN lists, and developer-written where strings at positions the parser does not bind, such as BETWEEN bounds, function arguments and LIKE ESCAPE literals. The flaw is reachable unauthenticated over the network (CVSS 3.1 9.8, PR:N) but only materialises on MySQL or MariaDB backends running with the default backslash-escaping behaviour (NO_BACKSLASH_ESCAPES absent), and only where the developer has constructed the vulnerable query form; bound/parameterized queries and whereBetween() as of 4.1.2 are not affected. No public exploit code or confirmed active exploitation was identified at time of analysis. The issue is fixed in Wheels 4.2.0.
SQL injection in the Wheels CFML framework versions 1.1.8 through 4.1.1 can let unauthenticated remote attackers alter SQL queries when applications pass caller-supplied string values into dynamic finders such as findOneByEmail, query-builder where(property, value) and where(property, operator, value), string/UUID-key lookup paths like findByKey, updateByKey, deleteByKey, findOrCreateBy..., or validatesUniquenessOf. The parser mishandles a doubled single quote by treating it as the end of a string literal, potentially exposing authentication, password-reset, and token lookups; the whereBetween() variant in 4.0.0 through 4.1.1 is additionally gated on MySQL/MariaDB running with backslash escaping enabled, and numeric-column values are not affected. The issue is fixed in 4.1.2, and no public exploit was identified at time of analysis.
Information disclosure in the Wheels CFML framework through 4.1.1 allows an unauthenticated remote attacker who wins a cold-start race to redirect the application's production error-email recipient to an address they control, because the default recipient is derived from the attacker-supplied Host header instead of a configured value. Once the attacker's request initializes the application, error emails silently flow to that address for the application's lifetime, disclosing error and request metadata and - on engines and versions where scope dumps render (Lucee 7 does not render them, limiting exposure to header fields) - configuration secrets and other users' session and cookie data. Exploitation is highly conditional: it requires no explicitly configured error recipient, a configured mail server, an upstream server that accepts an arbitrary Host value, and the attacker's request coinciding with the cold start; no public exploit identified at time of analysis, and the flaw is fixed in 4.1.2.
Exception-detail disclosure in the Wheels CFML framework (versions 3.0.0 through 4.1.1) lets a remote, unauthenticated client receive full stack/exception details when the non-default setting allowIPBasedDebugAccess=true is enabled. Because error and debug-display flags live in shared application scope, an administrator request that changes those settings can race with an unauthorized client's erroring request, so that client may receive tag context or a serialized exception and any sensitive data inside it - confidentiality only (CVSS 5.9, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N). Practical risk is well below what the network vector suggests: exploitation requires both the explicitly enabled non-default configuration and a narrow timing window, the race does not bypass the production gate that protects developer tools, and there is no public exploit identified at time of analysis. The issue is fixed in 4.1.2.
Wheels 4.0.0 through 4.1.2 performs case-insensitive path-containment checks on case-sensitive filesystems, so a pre-existing symlink pointing to a case-distinct sibling directory can bypass canonical-path validation for zip entries, package mappings, development assets/docs, guide images, and image tags. This permits limited unauthorized file disclosure outside the intended root; a separate CLI database-dump write path can write outside the application root only when the CLI POST action, loopback access, and password gate are all satisfied, and only to an existing writable case-distinct sibling directory. The issue is fixed in Wheels 4.2.0; exploitation of the primary flaw depends on deployment on a case-sensitive filesystem with the necessary pre-existing symlink, and no public exploit was identified at time of analysis.
Unauthenticated request-context confusion in Wheels 4.0.6 through 4.1.2 lets any remote client push a normal request into a separate test application context by supplying an X-Wheels-Test-Context header, a WHEELS_TEST_CONTEXT cookie with any value, or a test-runner path anywhere in the URL - including the query string. Because the alternate context reuses the same configuration, environment, datasource and debug settings, there is no confidentiality or privilege gain; the realistic impact is limited to bypassing maintenance mode when it was enabled only at runtime, obtaining a second independent set of in-memory rate-limit counters, and triggering extra application-startup side effects and memory consumption under repeated requests. No public exploit code has been identified at time of analysis, and the vulnerability is fixed in Wheels 4.2.0.
Reload-password and code disclosure, plus unintended state-changing operations against a foreign local server, affect developers using the Wheels CLI through 4.1.0. Because the CLI never verifies that the local development server it contacts on a targeted port actually belongs to the current project, any process listening on that port - or, for `wheels console`, on one of the common ports it probes when the project's own server is down - can capture the reload password and code sent via `wheels reload` or `wheels console`, while other commands can be induced to perform state-changing operations against another local application's server and database. Exploitation is local only (CVSS AV:L, PR:L, UI:R) and requires the developer to actively run an affected command, making this a genuine but bounded developer-workstation risk rather than a mass-exploitation priority; no public exploit was identified at time of analysis, and the vendor addresses the flaw in 4.1.1.
Broken object-level authorization in the Wheels CFML framework (versions 1.1 through 4.1.2) allows an authenticated low-privileged user to tamper with other users' associated records through nested forms. The nestedProperties() helper resolves nested hasMany, hasOne, and belongsTo records by the primary key posted in the request without verifying that those rows belong to the parent record being saved, so an attacker who can legitimately submit a nested form for their own parent can reassign, edit, or - when allowDelete=true is configured - delete another parent's rows, and can also create new child rows with attacker-chosen identities when the child model uses a composite primary key that is not composed of foreign keys. The issue carries an assessed CVSS of 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), requires authentication and actual use of nestedProperties() with nested forms, and is fixed in Wheels 4.2.0; no public exploit identified at time of analysis.
Remote, unauthenticated attackers can access password-less development tools under /wheels/* in Wheels 4.0.0 through 4.1.2 when enablePublicComponent=true (the default in development mode), exposing application settings, environment and datasource details, and routes, and allowing them to start test runs that may write to the real application database. This incorrect authorization flaw (CWE-863) does not affect production-mode deployments by default, and the separately protected migrator and CLI endpoints are not impacted. No public exploit identified at time of analysis.
Broken object-level authorization in the Wheels (CFML) framework 4.0.0 through 4.1.2 lets an authenticated low-privilege attacker supply a record key to findByKey(), exists(key=), updateByKey(), or deleteByKey() and have the framework drop the application's scope condition (such as a tenant or owner filter), enabling read, modification, or deletion of another user's or tenant's record. The flaw is remotely exploitable (AV:N, PR:L, no user interaction) with high confidentiality and integrity impact but no availability impact, and the exists(key=) variant additionally leaks record existence by returning true for an out-of-scope key when the application runs in production mode with error information disabled. No public exploit code or CISA KEV entry is identified at time of analysis, and exploitation requires an application that relies on Wheels scopes for ownership or tenant authorization and passes request-supplied keys into the affected methods.
SQL injection in the Wheels CFML framework through 4.1.2 lets remote attackers manipulate SQL statements when an application feeds request data into inline-literal query paths - opt-in parameterize=false queries, IN lists, and developer-written where strings at positions the parser does not bind, such as BETWEEN bounds, function arguments and LIKE ESCAPE literals. The flaw is reachable unauthenticated over the network (CVSS 3.1 9.8, PR:N) but only materialises on MySQL or MariaDB backends running with the default backslash-escaping behaviour (NO_BACKSLASH_ESCAPES absent), and only where the developer has constructed the vulnerable query form; bound/parameterized queries and whereBetween() as of 4.1.2 are not affected. No public exploit code or confirmed active exploitation was identified at time of analysis. The issue is fixed in Wheels 4.2.0.
SQL injection in the Wheels CFML framework versions 1.1.8 through 4.1.1 can let unauthenticated remote attackers alter SQL queries when applications pass caller-supplied string values into dynamic finders such as findOneByEmail, query-builder where(property, value) and where(property, operator, value), string/UUID-key lookup paths like findByKey, updateByKey, deleteByKey, findOrCreateBy..., or validatesUniquenessOf. The parser mishandles a doubled single quote by treating it as the end of a string literal, potentially exposing authentication, password-reset, and token lookups; the whereBetween() variant in 4.0.0 through 4.1.1 is additionally gated on MySQL/MariaDB running with backslash escaping enabled, and numeric-column values are not affected. The issue is fixed in 4.1.2, and no public exploit was identified at time of analysis.
Information disclosure in the Wheels CFML framework through 4.1.1 allows an unauthenticated remote attacker who wins a cold-start race to redirect the application's production error-email recipient to an address they control, because the default recipient is derived from the attacker-supplied Host header instead of a configured value. Once the attacker's request initializes the application, error emails silently flow to that address for the application's lifetime, disclosing error and request metadata and - on engines and versions where scope dumps render (Lucee 7 does not render them, limiting exposure to header fields) - configuration secrets and other users' session and cookie data. Exploitation is highly conditional: it requires no explicitly configured error recipient, a configured mail server, an upstream server that accepts an arbitrary Host value, and the attacker's request coinciding with the cold start; no public exploit identified at time of analysis, and the flaw is fixed in 4.1.2.
Exception-detail disclosure in the Wheels CFML framework (versions 3.0.0 through 4.1.1) lets a remote, unauthenticated client receive full stack/exception details when the non-default setting allowIPBasedDebugAccess=true is enabled. Because error and debug-display flags live in shared application scope, an administrator request that changes those settings can race with an unauthorized client's erroring request, so that client may receive tag context or a serialized exception and any sensitive data inside it - confidentiality only (CVSS 5.9, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N). Practical risk is well below what the network vector suggests: exploitation requires both the explicitly enabled non-default configuration and a narrow timing window, the race does not bypass the production gate that protects developer tools, and there is no public exploit identified at time of analysis. The issue is fixed in 4.1.2.
Wheels 4.0.0 through 4.1.2 performs case-insensitive path-containment checks on case-sensitive filesystems, so a pre-existing symlink pointing to a case-distinct sibling directory can bypass canonical-path validation for zip entries, package mappings, development assets/docs, guide images, and image tags. This permits limited unauthorized file disclosure outside the intended root; a separate CLI database-dump write path can write outside the application root only when the CLI POST action, loopback access, and password gate are all satisfied, and only to an existing writable case-distinct sibling directory. The issue is fixed in Wheels 4.2.0; exploitation of the primary flaw depends on deployment on a case-sensitive filesystem with the necessary pre-existing symlink, and no public exploit was identified at time of analysis.
Unauthenticated request-context confusion in Wheels 4.0.6 through 4.1.2 lets any remote client push a normal request into a separate test application context by supplying an X-Wheels-Test-Context header, a WHEELS_TEST_CONTEXT cookie with any value, or a test-runner path anywhere in the URL - including the query string. Because the alternate context reuses the same configuration, environment, datasource and debug settings, there is no confidentiality or privilege gain; the realistic impact is limited to bypassing maintenance mode when it was enabled only at runtime, obtaining a second independent set of in-memory rate-limit counters, and triggering extra application-startup side effects and memory consumption under repeated requests. No public exploit code has been identified at time of analysis, and the vulnerability is fixed in Wheels 4.2.0.
Reload-password and code disclosure, plus unintended state-changing operations against a foreign local server, affect developers using the Wheels CLI through 4.1.0. Because the CLI never verifies that the local development server it contacts on a targeted port actually belongs to the current project, any process listening on that port - or, for `wheels console`, on one of the common ports it probes when the project's own server is down - can capture the reload password and code sent via `wheels reload` or `wheels console`, while other commands can be induced to perform state-changing operations against another local application's server and database. Exploitation is local only (CVSS AV:L, PR:L, UI:R) and requires the developer to actively run an affected command, making this a genuine but bounded developer-workstation risk rather than a mass-exploitation priority; no public exploit was identified at time of analysis, and the vendor addresses the flaw in 4.1.1.