IPinfo Data Shows 16% of RPKI IPv4 Routes Remain Vulnerable to Origin Hijacks
Research from IPinfo reveals that over 138,000 RPKI-covered IPv4 routes allow forged-origin hijacks that pass validation checks, echoing the Virtualizor attack.
Key points
- % of RPKI-covered IPv4 routes have ROA configurations that permit unauthorized more-specific announcements.
- The August 28 Virtualizor update attack exploited this gap using a forged-origin route within Hetzner’s address space.
- Hosting providers show significant variance in exposure, with Contabo and DigitalOcean having high percentages of open routes.
IPinfo researchers reported that a significant portion of Resource Public Key Infrastructure (RPKI) covered IPv4 routes remain vulnerable to origin hijacks. The analysis found that 138,698 out of 855,217 routes, representing 16.2%, allow forged-origin announcements that pass validation. This vulnerability mirrors the technique used in the recent Virtualizor update attack.
The August 28 Virtualizor update attack utilized a forged-origin /24 route inside Hetzner’s network space. According to the IPinfo report, this route was considered RPKI-valid because Hetzner’s Route Origin Authorization (ROA) covered the broader /16 block and permitted announcements down to /24 prefixes. No legitimate /24 route existed to compete with the forged announcement, allowing it to pass validation checks uncontested.
Context and Background
The IPinfo study measured how common this specific configuration error is across the internet. For IPv6, the percentage of vulnerable routes is even higher at 20.9%. The researchers noted that approximately 18 million more-specific routes could be announced today and would emerge as RPKI-valid and uncontested. This highlights a gap where ROA settings are looser than the routes actually announced.
The remaining risk lies in routes that pass validation rather than those that fail. Invalid routes are currently being dropped by the network. A typical valid route is observed by 596 vantage points, whereas an invalid route is seen by only two. This disparity confirms that the primary threat vector is now focused on valid-looking but unauthorized announcements.
RFC 9319 provides a technical fix for this issue. The recommendation is to leave the maxLength parameter unset in ROA configurations. This ensures that a ROA only matches the specific block that the operator actually announces, preventing attackers from announcing more-specific subnets that fall within the authorized range.
Who Is Affected
Hosting providers exhibit significant differences in how many of their covered routes are left open to this type of attack. Contabo leaves 540 of its 553 covered routes open to potential hijacking. DigitalOcean has 780 of its 863 covered routes exposed to this vulnerability. OVH shows a lower exposure rate, with 11.5% of its routes affected.
These figures indicate that large hosting providers may have substantial portions of their address space vulnerable to origin hijacks that bypass RPKI validation. The variance suggests inconsistent implementation of ROA best practices across the industry. Operators using these providers may face increased risk if their upstreams do not tighten their ROA configurations.
What should you do?
Network operators and security professionals should review their current ROA configurations to ensure they align with actual announced prefixes. Organizations should monitor for unexpected more-specific route announcements within their authorized blocks. Implementing the maxLength unset strategy recommended in RFC 9319 can help mitigate this specific class of vulnerability.
What to do and how to stay safe: IPinfo
- Audit ROA configurations to ensure maxLength is unset or matches the exact announced prefix length.
- Monitor BGP feeds for unexpected more-specific announcements within your authorized address space.
- Verify that upstream providers are implementing strict ROA policies to prevent loose validation gaps.
- Review RFC 9319 guidelines for best practices in securing route origin authorizations.
Step-by-step guide: Social Engineering Warning Signs and How to Respond
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
How did the Virtualizor attack bypass RPKI validation?
The attack used a forged-origin /24 route within Hetzner’s space, which was valid because Hetzner’s ROA allowed announcements down to /24 and no competing route existed.
What percentage of IPv4 routes are vulnerable to this hijack method?
According to IPinfo, 16.2% of RPKI-covered IPv4 routes have ROA configurations that allow forged-origin hijacks to pass validation.
How can operators fix this vulnerability?
Operators can follow RFC 9319 recommendations by leaving the maxLength parameter unset, ensuring ROAs only match the specific blocks actually announced.
