CVE-2026-81868: 
C# vulnerability analysis and mitigation

CVE-2026-81868 is an authentication bypass vulnerability in Steeltoe's certificate-based authorization library (Steeltoe.Security.Authorization.Certificate) caused by improper certificate validation. The middleware trusts the public certificate supplied in the X-Client-Cert HTTP request header without verifying possession of the corresponding private key, enabling header spoofing attacks. All versions up to and including 4.2.0 of the NuGet package are affected; the issue is fixed in version 4.3.0. It carries a CVSS v3.1 base score of 6.5 (Medium) (Github Advisory, Feedly). The advisory was originally published on September 9, 2026, and registered with the NVD on September 17, 2026.

The root cause is classified under CWE-288 (Authentication Bypass Using an Alternate Path or Channel) and CWE-295 (Improper Certificate Validation). When AddOrgAndSpacePolicies() and UseCertificateAuthorization() are configured, the middleware reads the client certificate directly from the X-Client-Cert HTTP header and evaluates SameOrg/SameSpace policies against it — without performing a mutual TLS handshake or otherwise confirming that the requester holds the private key corresponding to the presented certificate (Github Advisory). Because common Cloud Foundry routers (Gorouter, Envoy) do not strip this header from inbound external requests, an attacker who can reach the application and has obtained any valid public certificate from an application instance in the target org or space can inject a crafted X-Client-Cert header to impersonate that instance. The fix (commit b626ef3) introduces AddOrgAndSpacePoliciesForMutualTls(), which reads the X-Forwarded-Client-Cert header — a header that Gorouter strips from untrusted inbound requests and only sets after a successful mTLS handshake — and replaces header-based certificate injection with a real mTLS handshake for outbound calls (Steeltoe Commit).

A successful exploit allows an unauthenticated network attacker to bypass SameOrg and SameSpace certificate-based authorization policies and gain unauthorized access to protected endpoints for the full validity period of the spoofed certificate (Github Advisory). The primary impact is high confidentiality loss — the attacker can read data from protected inter-service APIs — with a low integrity impact due to the potential to submit unauthorized requests to those endpoints. Availability is not directly affected. In Cloud Foundry environments where internal microservices rely solely on SameOrg/SameSpace policies for access control, exploitation could enable lateral movement across services within the same organization or space.

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The EPSS score is 0.0, reflecting a very low current probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to first obtain a valid public certificate from an application instance in the target Cloud Foundry organization or space, and to have network access to the vulnerable application — conditions that raise the effective attack complexity.

1. Reconnaissance: Identify a target application deployed on Cloud Foundry that uses Steeltoe.Security.Authorization.Certificate (version ≤ 4.2.0) with AddOrgAndSpacePolicies() and UseCertificateAuthorization(), and that is reachable via a public route or internal CF network.
2. Obtain a public certificate: Acquire the PEM-encoded public certificate of any application instance in the target Cloud Foundry organization or space. This may be obtained from a less-sensitive application in the same org/space, from CF API metadata, or through other means — no private key is required.
3. Craft the spoofed request: Encode the obtained public certificate in a format accepted by the X-Client-Cert header (typically URL-encoded PEM). Construct an HTTP request to a protected endpoint on the target application.
4. Inject the header: Send the crafted HTTP request directly to the target application (bypassing the CF router, or via a path where the router does not strip X-Client-Cert), including the X-Client-Cert header set to the encoded certificate.
5. Bypass authorization: The vulnerable middleware reads the header, validates the certificate's org/space fields against its own identity, and grants access — without verifying private-key possession — allowing the attacker to access protected resources (Github Advisory).

• Network: Inbound HTTP requests to protected endpoints containing an X-Client-Cert header originating from IP addresses that are not known trusted proxy sources (e.g., not the CF Gorouter or Envoy sidecar IP ranges).
• Network: Requests to internal-only service endpoints arriving via public CF routes rather than internal .apps.internal routes.
• Logs: Application access logs showing successful authorization on SameOrg/SameSpace-protected endpoints from unexpected source IPs or at unusual times.
• Logs: Presence of X-Client-Cert header in request logs for traffic that did not originate from a known CF router — legitimate mTLS-forwarded requests should only arrive via X-Forwarded-Client-Cert after the fix is applied.
• Logs: Repeated access attempts to sensitive inter-service endpoints with varying certificate values in the X-Client-Cert header, potentially indicating certificate enumeration.

Upgrade Steeltoe.Security.Authorization.Certificate to version 4.3.0, which replaces the vulnerable AddOrgAndSpacePolicies() with AddOrgAndSpacePoliciesForMutualTls() and performs true mTLS validation (Steeltoe Release). If an immediate upgrade is not possible, apply the following mitigations: (1) restrict certificate forwarding to trusted proxy source IPs using ForwardedHeadersOptions.KnownProxies and KnownNetworks; (2) switch the forwarding header to X-Forwarded-Client-Cert so that Gorouter/Envoy strip it from untrusted inbound requests; (3) add a secondary authorization layer (e.g., shared secret or mTLS at the proxy layer) for sensitive endpoints; and (4) use Cloud Foundry internal routes (.apps.internal) with container-to-container network policies to restrict access to intended clients only (Github Advisory).