Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-50194

CVE-2026-50194: Steeltoe Auth Bypass Vulnerability

CVE-2026-50194 is an authentication bypass vulnerability in Steeltoe management endpoints that allows attackers to circumvent port-based access restrictions using HTTP Host headers. This post covers technical details, affected versions, impact, and mitigation steps.

Published:

CVE-2026-50194 Overview

CVE-2026-50194 is an authentication bypass vulnerability in Steeltoe, an open source library suite for building cloud-native .NET applications. The flaw exists in the management endpoint middleware, which is intended to restrict actuator endpoints to a dedicated administrative port via the Management:Endpoints:Port setting. The middleware compares the Host HTTP header port instead of the actual network socket port, allowing remote attackers to bypass port isolation by setting an arbitrary Host header value. Affected releases include Steeltoe versions 3.2.2 through 3.3.0 and 4.1.0. The issue is classified under [CWE-288: Authentication Bypass Using an Alternate Path or Channel].

Critical Impact

Unauthenticated remote attackers can reach sensitive Steeltoe actuator endpoints intended to be isolated to a management port by manipulating the Host HTTP header.

Affected Products

  • Steeltoe management endpoints 3.2.2 through 3.3.0
  • Steeltoe management endpoints 4.1.0
  • Applications configured with Management:Endpoints:Port for port-based isolation

Discovery Timeline

  • 2026-06-17 - CVE-2026-50194 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-50194

Vulnerability Analysis

Steeltoe management endpoints expose Spring Boot-style actuators including health, environment, and configuration introspection. Operators commonly bind these endpoints to a dedicated port that is firewalled from public access. The ManagementPortMiddleware enforces this isolation by checking whether the inbound request port matches the configured management port. The middleware reads the port from context.Request.Host.Port, which is derived from the client-supplied Host HTTP header rather than the underlying TCP socket. An attacker connecting to the public application port can supply Host: target:<management-port> and pass the middleware's allow check, gaining access to actuator endpoints from outside the management boundary.

Root Cause

The middleware trusted client-controlled HTTP header data to make a security-critical authorization decision. Because Host.Port reflects the header rather than the listening socket, any attacker who can reach the application port can forge a port match against _managementOptions.Port.

Attack Vector

The vulnerability is exploitable over the network with no authentication or user interaction. An attacker sends an HTTP request to the public application port with a crafted Host header containing the configured management port. The middleware permits the request and forwards it to sensitive actuator handlers.

text
// Vulnerable check (pre-patch) — src/Management/src/EndpointCore/ManagementPort/ManagementPortMiddleware.cs
bool isManagementPath = context.Request.Path.ToString().StartsWith(contextPath, StringComparison.OrdinalIgnoreCase);

bool allowRequest = string.IsNullOrEmpty(_managementOptions.Port);
- allowRequest = allowRequest || (context.Request.Host.Port.ToString() == _managementOptions.Port && isManagementPath);
- allowRequest = allowRequest || (context.Request.Host.Port.ToString() != _managementOptions.Port && !isManagementPath);
+ allowRequest = allowRequest || (context.Connection.LocalPort.ToString() == _managementOptions.Port && isManagementPath);
+ allowRequest = allowRequest || (context.Connection.LocalPort.ToString() != _managementOptions.Port && !isManagementPath);

if (!allowRequest)
{

Source: GitHub Commit 4cbc352

The patch replaces context.Request.Host.Port with context.Connection.LocalPort, which reflects the actual TCP listener port and cannot be influenced by the client.

Detection Methods for CVE-2026-50194

Indicators of Compromise

  • HTTP requests to application listeners where the Host header port does not match the listening socket port.
  • Access log entries for actuator paths such as /actuator/env, /actuator/heapdump, or /actuator/refresh originating from non-management network segments.
  • Unexpected responses from management endpoints served on the public application port.

Detection Strategies

  • Compare each request's Host header port against the receiving socket port at the reverse proxy or WAF and flag mismatches.
  • Inventory all Steeltoe deployments and verify the installed version against the patched releases 3.4.0 and 4.2.0.
  • Hunt application telemetry for actuator path access patterns sourced from untrusted client IP ranges.

Monitoring Recommendations

  • Forward ASP.NET Core request logs and reverse proxy logs to a centralized analytics pipeline for correlation of Host header anomalies.
  • Alert on any successful response from management endpoint paths served on a non-management bind address.
  • Track outbound configuration or secret exposure patterns that may indicate prior actuator scraping.

How to Mitigate CVE-2026-50194

Immediate Actions Required

  • Upgrade Steeltoe management endpoints to version 3.4.0 or 4.2.0 as soon as feasible.
  • Restrict the application port at the network layer so untrusted clients cannot reach Steeltoe services directly.
  • Audit actuator endpoint exposure and rotate any secrets that may have been disclosed through env or configuration actuators.

Patch Information

The maintainers fixed the issue in Steeltoe 3.4.0 and 4.2.0. The patch changes the port comparison from the client-controlled Host header to the server socket's local port. Review the GitHub Security Advisory GHSA-58f6-6rj2-3v8r and the corresponding commits 4cbc352 and b7ca93c for implementation details.

Workarounds

  • Add explicit ASP.NET Core authorization using RequireAuthorization on all sensitive actuator endpoints as defense in depth independent of port isolation.
  • Configure the reverse proxy or load balancer to enforce or rewrite the Host header so clients cannot set arbitrary port values.
  • Block external traffic to the application port at the firewall and require connections through an authenticated ingress.
bash
# Example: enforce Host header at an nginx reverse proxy in front of the Steeltoe app
server {
    listen 443 ssl;
    server_name app.example.com;

    # Reject requests whose Host header sets an unexpected port
    if ($http_host !~* "^app\.example\.com(:443)?$") {
        return 400;
    }

    location / {
        proxy_set_header Host app.example.com;
        proxy_pass http://steeltoe-app:5000;
    }
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.