Medium, CVSS 6.5NuGetAmendedPublished
Steeltoe: Header-forwarded client cert lacks proof of private-key possession
CVE-2026-81868 · GHSA-5mq7-rwhj-4fh9
- Affected
- NuGet steeltoe.security.authorization.certificate <= 4.2.0
- Fixed in
- 4.3.0· Vendor fix available
- Issue
- When Steeltoe's certificate-based authorization (UseCertificateAuthorization) is configured, the default configuration of the middleware relies on the X-Client-Cert HTTP header to identify the client certificate, without verifying private-key possession. This header is not stripped by common Cloud Foundry routers (like Gorouter or Envoy) on inbound requests. Impact An attacker who obtains the public certificate of an application instance in the target organization or space can spoof the X-Client-Cert header. This allows the attacker to bypass SameOrg and SameSpace authorization policies, granting unauthorized access to protected endpoints for the duration of the certificate's validity period. Affected configuration - The application uses AddOrgAndSpacePolicies() and UseCertificateAuthorization() for inter-service authorization. - Inbound requests are not restricted to a known trusted proxy source IP. - The application's endpoints are network-accessible to the attacker (e.g.,…
Recommended action: Upgrade to 4.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.