Executive brief
Steeltoe applications using certificate-based authorization may be vulnerable to spoofing attacks when the X-Client-Cert HTTP header is not validated for private-key possession. An attacker with access to a legitimate application certificate can forge this header to bypass authorization policies (SameOrg, SameSpace) and gain unauthorized access to protected endpoints. This vulnerability is most critical in multi-tenant environments like Cloud Foundry where multiple applications share network infrastructure.
Technical details
The vulnerability exists in Steeltoe's certificate authorization middleware when UseCertificateAuthorization() is configured with AddOrgAndSpacePolicies(). The middleware trusts the X-Client-Cert HTTP header to identify the client without verifying that the requestor possesses the corresponding private key. Since common Cloud Foundry routers (Gorouter, Envoy) do not strip this header on inbound requests by default, an attacker can inject a forged certificate in this header. The attack requires network access to the application and knowledge of a valid certificate public key, and succeeds for the duration of the certificate's validity. Patches are available; mitigations include restricting header forwarding to known trusted proxies, switching to the X-Forwarded-Client-Cert header, and implementing additional authorization layers.
Affected products
- Steeltoe Steeltoe versions prior to patched release (2026-09-17)
Timeline
- 2026-09-17: disclosed
- 2026-09-17: advisory: GHSA-5mq7-rwhj-4fh9 published