Steeltoe vulnerable to management-port isolation bypass via spoofed Host header
Description
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. When Steeltoe management endpoints versions 3.2.2 through 3.3.0 and 4.1.0 are configured to listen on an alternate port (Management:Endpoints:Port is configured), the middleware responsible for restricting access to the endpoints uses the Host HTTP header rather than the actual network socket port. Versions 3.4.0 and 4.2.0 patch the issue. If an immediate upgrade to a patched version is not possible, add explicit ASP.NET Core authorization (RequireAuthorization) to all sensitive actuator endpoints as a defense-in-depth measure independent of port isolation and/or configure the reverse proxy or load balancer to enforce the Host header value and prevent clients from setting an arbitrary port.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
1- Range: >=3.2.2,<3.4.0 || =4.1.0
Patches
Vulnerability mechanics
Root cause
"The middleware used the attacker-controlled `Host` header port instead of the actual network socket port to enforce management port isolation."
Attack vector
An attacker sends an HTTP request to the application's default port (e.g., port 5000) but sets the `Host` header to include the management port number (e.g., `Host: anything:9090`). Because the middleware compared `context.Request.Host.Port` against the configured management port, the spoofed header made the request appear to come from the management port, granting access to sensitive actuator endpoints that should only be reachable on the isolated management port [CWE-290]. The attacker does not need authentication; they only need network access to the application's default listener.
Affected code
The vulnerability resides in `ManagementPortMiddleware.cs` in both the `EndpointCore` and `Endpoint` projects. The `IsRequestAllowed` method (and the inline logic in the older middleware) used `context.Request.Host.Port` to determine whether a request arrived on the management port, rather than `context.Connection.LocalPort`. This allowed an attacker to bypass port-based access control by spoofing the `Host` header. The patches also add a port-range validation (`< 65536`) in `ManagementPortStartupFilter.cs` and `PrometheusExtensions.cs`.
What the fix does
Both patches replace `context.Request.Host.Port` with `context.Connection.LocalPort` in the port-comparison logic. `Connection.LocalPort` reflects the actual TCP port the server accepted the connection on, which cannot be spoofed by the client. The patches also add a port-range sanity check (`managementPort is > 0 and < 65536`) in `ManagementPortStartupFilter.cs` and `PrometheusExtensions.cs` to reject invalid port configurations. The new test `IgnoresSpoofedHostHeader` confirms that a request with a forged `Host` header is correctly denied.
Preconditions
- configThe application must have `Management:Endpoints:Port` configured to a non-zero value, enabling port-based isolation.
- networkThe attacker must be able to send HTTP requests to the application's default listener port.
- inputThe attacker can set an arbitrary `Host` header in the HTTP request.
Generated on Jun 18, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3- github.com/SteeltoeOSS/Steeltoe/commit/4cbc352fe89ac2e6c609554e435ab28996fec5e9mitrex_refsource_MISC
- github.com/SteeltoeOSS/Steeltoe/commit/b7ca93c510aaa08d7e4ebec40ce20c5811c2c4b6mitrex_refsource_MISC
- github.com/SteeltoeOSS/security-advisories/security/advisories/GHSA-58f6-6rj2-3v8rmitrex_refsource_CONFIRM
News mentions
0No linked articles in our index yet.