CVE-2026-111450: Medium severity CFWheels Wheels vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Wheelsto a version that resolves this vulnerability.Fixed in 4.1.2
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using Wheels through 4.1.1 are exposed only when no explicit production error-email recipient is configured, a mail server is configured, and the server accepts an attacker-controlled Host header. The attacker must also be able to send the request that starts the application from a cold state.
What does an attacker need to do to exploit it?
An unauthenticated attacker needs to supply a chosen Host header in a request that triggers application startup. That header-derived value becomes the default error-email address for the application's lifetime, causing later error reports to be sent to the attacker-controlled address.
What information could be disclosed in redirected error emails?
Error emails disclose error and request metadata. On engines and versions where scope dumps render, they may also expose configuration secrets and other users' session or cookie data; on Lucee 7, scope dumps do not render, limiting disclosure to header fields.
What can be done if updating is not immediately possible?
Configure an explicit production error-email recipient and ensure the server does not accept attacker-chosen Host headers. These conditions prevent the application from deriving the recipient from the Host header.
How can I remediate the issue?
Upgrade to Wheels 4.1.2, which fixes the issue. Until then, verify that an explicit error-email recipient is configured rather than relying on the default derived at application startup.