CVE-2026-111450 in Wheels
Summary
by MITRE • 10/16/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in Wheels framework versions through 4.1.1 stems from an insecure default configuration mechanism that relies on untrusted input for sensitive operational settings. Specifically, the application derives its default production error-email recipient address directly from the Host header of the HTTP request used to initiate the application instance. This design choice introduces a critical flaw because it assumes that the Host header is always trustworthy and controlled by legitimate administrators rather than end-users or attackers. In web server architectures where virtual hosts are configured, clients can manipulate the Host header in their requests unless strict validation is enforced at the reverse proxy or load balancer level. By accepting an attacker-chosen value for this header during a cold start event, the application binds its internal error reporting mechanism to that malicious input for the duration of the server instance's lifecycle.
The operational impact of this vulnerability is significant due to the nature of production error emails in web applications. These messages typically contain detailed stack traces, request metadata, and sometimes sensitive configuration data depending on the specific engine or version running the application. When an attacker triggers a cold start with a malicious Host header, they effectively hijack the destination for all subsequent unhandled exceptions generated by that server instance. This allows the attacker to receive error reports containing internal logic details, database query structures, and potentially authentication tokens if scope dumps are rendered in the error output. On engines such as Lucee prior to version 7, these scope dumps expose configuration secrets and other users' session or cookie data, leading to a severe confidentiality breach that can facilitate further attacks like session hijacking or privilege escalation.
Even on newer versions of the Lucee engine where scope dumps are disabled by default, limiting disclosure primarily to header fields, the vulnerability remains problematic because it enables phishing campaigns and social engineering attacks using authentic-looking error notifications from the victim's domain. Furthermore, this behavior violates fundamental security principles regarding input validation and secure defaults. The flaw aligns with CWE-20 Improper Input Validation as the application fails to validate that the Host header corresponds to an expected set of values before using it for critical configuration purposes. It also relates to CWE-16 Configuration which highlights how insecure default configurations can lead to security breaches. From a tactical perspective, this vulnerability supports ATT&CK technique T1589 Gather Victim Identity Information as attackers collect internal system details through the intercepted error emails, and potentially T1078 Valid Accounts if session data is exposed.
To mitigate this risk, organizations running Wheels framework versions prior to 4.1.2 must immediately upgrade to version 4.1.2 where the issue has been resolved by removing reliance on the Host header for default email configuration. For environments that cannot update immediately due to compatibility constraints or other operational reasons, administrators should explicitly configure a static error-email recipient address in the application settings rather than relying on defaults. Additionally, web servers and reverse proxies such as Nginx or Apache should be configured to enforce strict validation of the Host header against an allowlist of valid domain names associated with the service. This ensures that even if an attacker attempts to manipulate the request headers during a cold start, the application will either reject the invalid host or fall back to a safe default configuration rather than binding to malicious input. Regular security audits and penetration testing should also be conducted to verify that no other components rely on unvalidated HTTP headers for critical operational functions.