RUSTSEC-2026-0481: `verify_x509_cert` does not check the certificate validity period
tdxworkloadattestation::verification::x509::verifyx509cert(), available with the host-verification feature, checked that issuercert issued cert and verified the certificate signature. It did not check the certificate's validity period, so it accepted expired and not-yet-valid certificates.
With the host-gcp-tdx feature, this function validates the GCP launch endorsement signing certificate against the GCE confidential-computing TCB root certificate. A signing certificate outside its validity period was therefore still accepted during launch endorsement verification.
Intel describes the issue as improper certificate validation and classifies it as escalation of privilege, with a CVSS 4.0 base score of 5.9, in INTEL-SA-01520.
The flaw was corrected in #86, released in 0.2.0. The function now returns Ok(false) when the current time is outside the certificate's notBefore/notAfter range.
Reported by Borys Tsyrulnikov.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rust/tdx_workload_attestationto a version that resolves this vulnerability.Fixed in 0.2.0 - Upgrade
Upgrade
tdx_workload_attestationto a version that resolves this vulnerability.Fixed in 0.2.0
Event History
Frequently Asked Questions
Which deployments are affected by this issue?
Deployments that use tdx_workload_attestation with the host-verification feature are affected if they call verify_x509_cert. The host-gcp-tdx feature uses this function to validate the GCP launch endorsement signing certificate against the GCE confidential-computing TCB root certificate.
What would an attacker need to exploit the flaw?
An attacker would need a certificate that is correctly issued by the expected issuer and has a valid signature, but is expired or not yet valid. The vulnerable function accepted such certificates because it did not evaluate the notBefore and notAfter validity period.
How can I determine whether my version is vulnerable?
Version 0.2.0 includes the correction. In corrected code, verify_x509_cert returns Ok(false) when the current time is outside the certificate validity range; versions lacking that behavior are affected.
What can be done if upgrading is not immediately possible?
Ensure callers check the certificate's notBefore and notAfter values against the current time before accepting verification results. This compensates for the missing validity-period check in verify_x509_cert.