Wheels vulnerabilities

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 recipient is configured, an attacker can trigger a cold start and direct later error emails to an address under their control, disclosing error and request metadata, and in some cases configuration secrets and other users' session data. This is fixed in 4.1.2.

Wheels 3.0.0 through 4.1.1 can disclose detailed exceptions when allowIPBasedDebugAccess=true (disabled by default). An allowed administrator request changes error/debug-display settings in shared application scope, and if it overlaps with an unauthorized client's request that raises an error, that client can receive full exception details, including tag context or a serialized exception, and any sensitive data they contain. This is fixed in 4.1.2.

Wheels 4.0.0 through 4.1.2 uses case-insensitive comparisons in path-containment checks on case-sensitive filesystems. Canonical-path checks for zip entries, package mappings, development assets/docs, guide images and image tags can accept paths through an existing symlink to a case-distinct sibling directory, allowing access outside the intended root, including limited file disclosure. Separately, the CLI database-dump output check can write outside the application root to an existing writable case-distinct sibling directory; that action requires the CLI POST, loopback and password gate. This is fixed in 4.2.0.

Wheels versions 1.1 through 4.1.2 resolves nestedProperties() records by posted primary key without verifying they belong to the parent being saved. A user can update, reassign, or delete another parent's hasMany or hasOne rows, and edit nested belongsTo records by posting another associated record's key.

Wheels versions 4.0.0 through 4.1.2 exposes password-less development tools under /wheels/* to remote clients when enablePublicComponent=true (default in development). In 4.1.2 the local-access restriction trusts client-supplied headers without checking the connecting peer.

Wheels versions 4.0.0 through 4.1.2 before 4.2.0 replaces incoming scope conditions with a primary-key condition in findByKey() and exists(key=). For exists(key=), production with error information disabled returns true for an out-of-scope key instead of throwing.

Wheels 4.0.6 through 4.1.2 lets an unauthenticated client switch a request into a separate test application context, including in production, by supplying an X-Wheels-Test-Context header, WHEELS_TEST_CONTEXT cookie, or a test-runner path in the URL. The alternate application uses the same configuration, environment, datasource and debug settings; this is not an authentication bypass or data/debug escalation, but it can bypass maintenance mode, provide a second set of rate-limit counters, and trigger additional startup side effects. This is fixed in 4.2.0.

Wheels through 4.1.2 allows SQL injection on MySQL/MariaDB with backslash escaping enabled (NO_BACKSLASH_ESCAPES absent) when an application supplies request data to inline-literal paths. This includes opt-in parameterize=false queries, IN lists, and positions in developer-written where strings that the parser does not bind, such as BETWEEN bounds, function arguments, and LIKE ESCAPE literals.

Wheels 1.1.8 through 4.1.1 allows SQL injection when caller-supplied quoted values are parsed again as SQL by dynamic finders (such as findOneByEmail), the query builder's where(property, value) and where(property, operator, value), string/UUID-key lookup paths (findByKey, updateByKey, deleteByKey and findOrCreateBy...), and validatesUniquenessOf. The parser incorrectly treats a doubled single quote as the end of a literal. Applications passing request data to these APIs can expose authentication, password-reset or token lookups, and data to unauthorized access; numeric-column values are not affected.