CVE-2026-72755 in Routinator
Summary
by MITRE • 10/26/2026
Routinator stores a newly-retrieved TA certificate via HTTPS in cache without validation, potentially overwriting a known good TA certificate even if validation fails.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in Routinator centers on the handling of Trust Anchor certificates retrieved via HTTPS during the Resource Public Key Infrastructure data collection process. As a critical component for validating Route Origin Authorizations within the RPKI ecosystem, Routinator is responsible for fetching and caching trust anchor certificates from various repositories to ensure the integrity of routing announcements. The core technical flaw lies in the application's cache management logic, specifically regarding how it processes newly retrieved TA certificates. When a new certificate is fetched over HTTPS, the system stores this artifact directly into its local cache without performing sufficient validation checks against previously established trusted states or verifying the cryptographic validity and chain-of-trust integrity before committing the change to persistent storage.
This lack of pre-commitment validation creates a significant security gap where operational logic prioritizes data availability over data integrity in certain failure scenarios. Specifically, if the retrieval process encounters issues such as network errors, certificate expiration mismatches, or signature verification failures during the HTTPS transaction, the application may still proceed to overwrite an existing, known-good trust anchor with the newly retrieved but potentially invalid or corrupted version. This behavior undermines the fundamental security model of RPKI, which relies on a stable and verified set of root certificates to authenticate route origins. By allowing unvalidated updates to persist in the cache, the system introduces a state where downstream validators may begin trusting routes based on compromised or incorrect trust anchors, effectively breaking the chain of trust that protects against BGP hijacking and leaks.
The operational impact of this vulnerability is severe for network operators relying on Routinator for route validation services. If an attacker can manipulate the HTTPS response from a repository or exploit a man-in-the-middle scenario to inject a malicious certificate, they could potentially cause Routinator to cache this invalid trust anchor. Subsequent validation processes would then use this compromised root to verify ROAs, leading to incorrect acceptance of unauthorized routes. This results in a degradation of network security posture, where traffic may be routed through untrusted paths without detection by automated filtering systems that depend on accurate RPKI data. The risk is compounded because the overwrite occurs silently within the cache layer, potentially going unnoticed until significant routing anomalies occur or forensic analysis reveals the discrepancy between expected and actual trust anchors.
From a standards perspective, this flaw aligns with CWE-20 Improper Input Validation, as the system fails to adequately validate input data before processing it into critical security state storage. It also relates to CWE-697 Incorrect Comparison during validation processes where the outcome of HTTPS retrieval does not trigger appropriate rejection logic for cache updates. In terms of MITRE ATT&CK techniques, this vulnerability facilitates potential supply chain attacks or repository compromise scenarios by allowing an adversary to poison the local trust store if they can influence the data source. The lack of atomicity and verification before state mutation represents a fundamental design weakness in how security-critical configurations are managed dynamically.
To mitigate this risk, immediate updates to Routinator should be applied to enforce strict validation protocols prior to cache modification. Developers must implement checks that verify the cryptographic signature, expiration dates, and chain-of-trust integrity of any newly retrieved TA certificate against local policy requirements before allowing it to replace existing entries. Additionally, implementing a rollback mechanism or maintaining separate staging areas for new certificates can prevent immediate overwrites until manual or automated verification confirms their validity. Network operators should also monitor cache logs for unexpected changes in trust anchor hashes and consider deploying redundant validation instances with independent configurations to cross-verify results during periods of repository instability. Ensuring that HTTPS connections are strictly validated against trusted certificate authorities further reduces the attack surface for injection attacks targeting this specific data path.