Wheels CVE-2026-111446

Requires the target to be running in DEVELOPMENT mode with enablePublicComponent=true (the default for development), exposing the password-less /wheels/* tools; the host must be network-reachable by the attacker. No authentication, user interaction, or special privileges are needed against such an instance (PR:N/UI:N). In versions before 4.1.2 there is no local-access restriction at all; 4.1.2's restriction can be defeated because it trusts client-supplied headers (e.g., spoofable locality/forwarding headers) rather than checking the connecting peer. KEY LIMITING FACTORS: production-mode deployments do not enable these endpoints by default; the database-write impact only occurs where application tests run against the primary datasource; and the separately protected migrator and CLI endpoints are NOT affected.

The vendor CVSS of 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L) describes a remote, unauthenticated, low-complexity access-control failure (CWE-863) with high confidentiality and low integrity/availability impact, which is internally consistent with the description: remote clients reach password-less /wheels/* development tools and can read settings, environment/datasource details and routes, and start test runs that may write to the real application database. The single strongest mitigating signal is NOT in the CVSS vector but in the description: exploitation requires enablePublicComponent=true, which is the default only in DEVELOPMENT mode - production deployments running in production mode do not expose these tools, so AV:N/AC:L understates a real deployment-state precondition. There is no EPSS score, no CISA KEV listing, and no public exploit code referenced (only the GHSA advisory), so there is no evidence of widespread or active exploitation. Net: this is a genuine unauthenticated exposure for any Wheels instance mistakenly running in development mode on a reachable network, but for correctly configured production deployments the real-world risk is substantially lower than the 8.6 implies - treat it as an exposure/misconfiguration-amplified issue rather than a drop-everything internet-wide threat. Note also that the 4.1.2 partial fix is itself vulnerable because it trusts client-supplied headers to judge locality without verifying the connecting peer, so '4.1.2 is patched' is misleading - only 4.2.0 is safe.

A Wheels 4.0.0-4.1.2 application is deployed (or left) in development mode with enablePublicComponent=true on a network-reachable host. A remote, unauthenticated attacker requests the /wheels/* development endpoints to enumerate application settings, datasource credentials and routes, then invokes the test runner; because the application's tests use the primary datasource, the test run writes directly to the live application database. No public exploit code is identified at time of analysis, but the endpoints are plain HTTP and require no special tooling.