frontdoor rule · FD022
AWS OIDC provider thumbprint missing or stale
OIDC thumbprint missing or stale
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
aws iam update-open-id-connect-provider-thumbprint \
--open-id-connect-provider-arn ARN \
--thumbprint-list THUMBPRINTTake 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.