Threat database

Wheels through 4.1.1 derives its default production error-email address from the Host header of the request that starts the application. If no explicit error-email recipient is configured, a mail server is configured, and the server accepts an attacker-chosen Host, an attacker whose request triggers a cold start can direct later error emails to an address under their control for that application's lifetime. Emails disclose error and request metadata; on engines/versions where scope dumps render, they may also disclose configuration secrets and other users' session/cookie data. On the Lucee 7 engine, scope dumps fail to render, limiting disclosure to header fields. This is fixed in 4.1.2.

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.

Wheels versions 4.0.0 through 4.1.2 contain a vulnerability where scope conditions are replaced by primary-key conditions in certain methods, allowing unauthorized access to records. This can enable an attacker with limited privileges to load, modify, or delete records belonging to other users or tenants. The issue is fixed in version 4.2.0 by properly combining key and scope conditions in affected methods.

Wheels versions 1.1.8 through 4.1.1 contain a critical SQL injection vulnerability in several dynamic finder methods and query builder functions when parsing caller-supplied quoted values. This flaw allows crafted input to alter SQL queries, potentially exposing sensitive data such as authentication tokens and password reset information. Numeric columns are not affected. A related issue affects the whereBetween() function in versions 4.0.0 through 4.1.1 on MySQL/MariaDB with backslash escaping enabled. The vulnerability is fixed in version 4.1.2.