CVE-2026-81868: Steeltoe: Header-forwarded client cert lacks proof of private-key possession
Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. Prior to 4.3.0, Steeltoe.Security.Authorization.Certificate deployments using AddOrgAndSpacePolicies() and UseCertificateAuthorization() trust the public certificate supplied in the X-Client-Cert request header without proving possession of the corresponding private key. Common Cloud Foundry routers do not remove this header from inbound requests. When inbound requests are not restricted to a known trusted proxy source IP, an attacker who obtains the public certificate of an application instance in the target organization or space and can reach the application can spoof X-Client-Cert to bypass the SameOrg and SameSpace policies for the certificate validity period. This issue is fixed in version 4.3.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Steeltoe.Security.Authorization.Certificateto a version that resolves this vulnerability.Fixed in 4.3.0 - Compensating control
Restrict inbound requests to a known trusted proxy source IP (do not allow direct access from arbitrary clients) so X-Client-Cert spoofing cannot bypass SameOrg/SameSpace policies during the certificate validity period.
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using Steeltoe.Security.Authorization.Certificate with both AddOrgAndSpacePolicies() and UseCertificateAuthorization() are affected before version 4.3.0, if inbound requests are not restricted to a known trusted proxy source IP.
What does an attacker need to exploit this?
The attacker must be able to reach the application and obtain the public certificate of an application instance in the target organization or space. They can then spoof the X-Client-Cert header during the certificate's validity period.
Are Cloud Foundry deployments affected by default?
Common Cloud Foundry routers do not remove X-Client-Cert from inbound requests. Exposure still depends on whether the application restricts inbound requests to known trusted proxy source IP addresses.
What can be done before upgrading?
Restrict inbound requests so that only known trusted proxy source IPs can reach the application. Upgrade to version 4.3.0 to apply the fix.
How can I determine whether a deployment may have been vulnerable?
Check whether the application ran a version earlier than 4.3.0, used AddOrgAndSpacePolicies() with UseCertificateAuthorization(), and accepted inbound traffic from sources other than known trusted proxies. Also determine whether an attacker could have reached the application and obtained an application instance's public certificate.