frontdoor rule · FD022

AWS OIDC provider thumbprint missing or stale

OIDC thumbprint missing or stale

Amazon Web ServicesUpdated Source on GitHub

Severity: medium. Low for the well-known issuers AWS validates against its own trust store.

AWS only. GCP validates its providers against the public CA set and has no thumbprint field; Azure does not have the concept either. Firing this on them would put a medium on every project scanned.

What it means

An AWS OIDC provider carries a list of CA certificate thumbprints. Historically, AWS used them to verify the TLS certificate of the issuer before trusting a token from it.

This finding covers two cases:

  • No thumbprint registered at all.
  • With --resolve: none of the registered thumbprints match the CA chain the issuer is currently serving.

Why the severity is usually low

Since 2023, AWS validates a set of well-known issuers — GitHub, GitLab, Google, Terraform Cloud, Buildkite, CircleCI, Vercel, Bitbucket — against its own trust store and ignores the registered thumbprint entirely. For those, a missing or stale thumbprint is untidy rather than exploitable, and frontdoor reports it as low and says why.

For an issuer AWS does not special-case — a self-hosted GitLab, a private OIDC provider, an internal IdP — the thumbprint is still the check. That is a medium.

What an attacker does

Only relevant where AWS actually falls back to the thumbprint: an attacker able to intercept TLS to the issuer could present their own certificate and mint tokens your account would accept. That is a high bar, which is why this rule sits below the subject and audience rules rather than beside them.

The more common real-world consequence is not an attack at all: a stale thumbprint on a non-exempt issuer means the provider stops working, usually during a certificate rotation, usually at an inconvenient moment.

How to fix it

bash
aws iam update-open-id-connect-provider-thumbprint \
  --open-id-connect-provider-arn ARN \
  --thumbprint-list THUMBPRINT

Take the value from the issuer's own published documentation, not from whatever your laptop happens to negotiate at that moment.

About --resolve

Comparing the registered thumbprint against reality needs a TLS connection to the issuer. That is the only network call frontdoor makes outside your cloud provider, so it is off by default. With --resolve it opens the handshake, reads the certificate chain, and closes without sending a request — no account id, no ARN, no request body.

frontdoor answers this once, when you run it; Secorvia checks it continuously across every account you connect, on a free tier that needs no card.