Skip to content

← Public intelligence

NuGet package

steeltoe.security.authorization.certificate

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. 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.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →