Safeguard
Application Security•

CWE-370 Missing Certificate Revocation Check After the First

CWE-370 happens when a certificate is checked once and then trusted forever. Learn why revocation needs a recheck before each privileged action.

Safeguard Security Team
2 min read

CWE-370, Missing Check for Certificate Revocation after Initial Check, describes a product that checks a certificate's revocation status once and never again. It can keep performing privileged actions after the certificate has been revoked.

This applies to long lived sessions, services that authenticate once and run for hours, and any workflow that gates several actions behind one earlier check.

How it happens

A connection starts. The software checks that the certificate is valid and not revoked. It then caches the result for the life of the session. Later, the certificate is revoked, perhaps because the key leaked. The session carries on as if nothing had happened.

MITRE frames this as a race condition. The time between the check and each later use is a window in which the answer can change. MITRE adds a pointed observation: a revoked certificate in use is almost certainly a sign of malicious activity.

What an attacker gains

The record lists three effects. Trust may be assigned to an entity that is not who it claims to be. Data from an untrusted, possibly malicious source may be accepted. Data may be disclosed to an entity impersonating a trusted one.

How to find it

The record lists no detection methods and no observed CVEs for this entry. Review the design.

  • Where is revocation checked? At connection time only, or before each privileged action?
  • How long can a cached revocation result live?
  • What happens to an open session when a certificate is revoked?

How to fix it

MITRE's mitigation is direct: check certificates for revoked status before each use of a protected resource. If the check runs before each access, the delay that creates the race becomes almost negligible and the risk drops significantly.

A practical reading:

  1. Tie the revocation check to the privileged action, not to the session start.
  2. Keep any cache lifetime short, and weigh it against how fast you need revocation to take effect.
  3. Decide in advance what a failed or unreachable check means, and make the safe answer the default for sensitive actions.

Quick check

Why is checking once at connection time not enough?

Revocation can happen later. Without a recheck before each privileged action, the session keeps its benefits after the certificate is revoked.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.