Steeltoe: Header-forwarded client cert lacks proof of private-key possession
Exact source revision recorded 23 Oct 2026 15:48:27 UTC. It does not establish the source's current position. Latest evidence.
cve-program · CVE-2026-81868
PublishedSteeltoe 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.
- Source published
- 17 Sep 2026 15:36:23 UTC
- Source modified
- 23 Sep 2026 18:46:54 UTC
- Observed here
- 23 Oct 2026 15:48:27 UTC
- Source terms
- CVE Program Terms of Use
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS 3.1 · 6.5 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N