RPKI Vulnerability: Overly Permissive ROAs Enable Forged-Origin Hijacks, Exploited in Recent Attack

Introduction: The Hidden Vulnerability in RPKI-Protected Routes

On August 28, a routine software update for Virtualizor, a widely used virtualization platform, became a critical case study in internet routing security. Attackers exploited the update process by announcing a forged /24 prefix within Hetzner’s IP space. This incident underscored a systemic flaw in Route Origin Authorizations (ROAs), the foundational mechanism of the Resource Public Key Infrastructure (RPKI). The attack revealed that 16.2% of RPKI-covered IPv4 routes and 20.9% of IPv6 routes—approximately 18 million routes—remain susceptible to forged-origin hijacks due to overly permissive ROA configurations.

The Mechanism of the Attack: Exploiting Permissive ROA Configurations

The attack succeeded by leveraging a technical misconfiguration in Hetzner’s ROA. Their ROA covered a broad /16 prefix but permitted announcements down to /24 prefixes via the maxLength parameter. Since no legitimate /24 routes existed within this block, the attackers’ forged announcement passed RPKI validation unchecked. The causal chain is as follows:

• Trigger: Attackers announced a forged /24 prefix within Hetzner’s /16 block, targeting Virtualizor’s update servers.
• Exploitation Mechanism: The ROA’s maxLength parameter was set to 24, allowing any /24 prefix within the /16 block to be validated, regardless of its existence in the routing table.
• Consequence: The forged route propagated globally, hijacking traffic intended for Virtualizor’s update servers and exposing users to malicious code.

The Scale of the Problem: Millions of Routes at Risk

Our analysis of 855,217 RPKI-covered IPv4 routes found that 138,698 (16.2%) have ROAs with maxLength values exceeding the announced prefix length, lacking legitimate more-specific routes for competition. For IPv6, this figure rises to 20.9%. This vulnerability enables attackers to announce 18 million more-specific prefixes that would pass RPKI validation undetected. The Virtualizor attack demonstrates that this risk is not theoretical but actively exploitable.

Disparities Among Hosting Providers: Inconsistent Security Practices

Hosting providers exhibit significant variation in ROA configuration rigor. Our data highlights the following disparities:

• Contabo: 540 out of 553 (97.6%) covered routes have overly permissive ROAs.
• DigitalOcean: 780 out of 863 (90.4%) routes are vulnerable.
• OVH: Only 11.5% of their routes exhibit permissive configurations.

These variations underscore the lack of uniform adherence to best practices, such as leaving the maxLength parameter unset, as recommended in RFC 9319. This practice ensures ROAs match only the exact prefix being announced, eliminating the loophole exploited in the Virtualizor attack.

The Real Risk: Valid but Forged Routes

While the internet routing ecosystem has improved in dropping invalid routes—with valid routes visible from 596 vantage points compared to just 2 for invalid routes—the critical risk lies in routes that pass RPKI validation but are forged. These routes evade detection, eroding trust in internet routing, disrupting critical services, and exposing users to malicious attacks.

Conclusion: Urgent Need for Stricter ROA Practices

The Virtualizor attack serves as a stark reminder of the consequences of permissive ROA configurations. Unless hosting providers and network operators adopt stricter practices—specifically, adhering to RFC 9319 by setting maxLength to match announced prefixes—millions of routes will remain vulnerable. The solution is clear: implement precise ROA configurations to eliminate the possibility of forged-origin hijacks before they become pervasive.

Understanding the Vulnerability: How Overly Permissive ROAs Enable Forged-Origin Hijacks

The recent surge in RPKI-related attacks, exemplified by the Virtualizor update incident, underscores a critical vulnerability stemming from misconfigured Route Origin Authorizations (ROAs). ROAs, designed to validate the legitimacy of route announcements by binding IP prefixes to origin Autonomous Systems (ASes), are being deployed with excessive flexibility. This misconfiguration transforms a security mechanism into a liability, enabling attackers to hijack routes undetected. The root cause lies in the misuse of the maxLength parameter, which, when set too broadly, allows the announcement of more-specific prefixes within the covered block, even if those prefixes do not exist.

The Role of maxLength in ROA Misconfigurations

ROAs are intended to ensure that only authorized ASes can announce specific IP prefixes. However, the maxLength parameter introduces a critical trade-off between flexibility and security. When maxLength is set, it permits the announcement of more-specific prefixes within the covered block. For example, a ROA covering a /16 block with maxLength set to /24 allows any /24 prefix within that /16 to be announced as valid, regardless of whether such prefixes are actually provisioned. This creates a validation gap, as RPKI validation cannot distinguish between legitimate and forged more-specifics.

Exploitation Mechanism: In the August 28 Virtualizor attack, Hetzner’s ROA covered a /16 block with maxLength set to /24. Attackers exploited this by announcing a forged /24 prefix within the /16 block. Since the ROA validated any /24 prefix within the /16, the forged announcement passed RPKI checks, despite lacking a legitimate counterpart. This enabled the hijack, redirecting traffic to attacker-controlled infrastructure.

The Scale of the Problem: 18 Million Vulnerable Routes

Our analysis of 855,217 RPKI-covered IPv4 routes reveals that 16.2% (138,698 routes) have ROAs with maxLength exceeding the announced prefix length, creating opportunities for forged more-specifics. For IPv6, the vulnerability is even more pronounced, with 20.9% of routes affected. This translates to approximately 18 million more-specific prefixes that could be announced today, passing RPKI validation without contest.

Causal Chain: Overly permissive ROAs → Absence of competing legitimate routes → Forged announcements pass validation → Hijacked traffic propagates globally, disrupting services and exposing users to malicious activity.

Provider Disparities: A Patchwork of Security Practices

Hosting providers exhibit significant disparities in ROA configurations, reflecting inconsistent security practices:

• Contabo: 97.6% of routes (540 out of 553) have permissive ROAs, leaving nearly all routes vulnerable to hijack via forged more-specifics.
• DigitalOcean: 90.4% of routes (780 out of 863) are similarly exposed.
• OVH: Only 11.5% of routes exhibit permissive configurations, demonstrating a more stringent approach that minimizes risk.

Exploitation Mechanism: Providers with lax configurations create exploitable gaps. For instance, Contabo’s setup allows attackers to hijack almost all its routes by announcing forged more-specifics, while OVH’s stricter policies effectively mitigate this risk.

The Fix: RFC 9319 and Precise ROA Configurations

The solution lies in adhering to RFC 9319, which recommends leaving the maxLength parameter unset. This ensures that ROAs match only the exact prefix being announced, eliminating the vulnerability to forged more-specifics.

Practical Insight: By removing maxLength, providers close the validation gap. Attackers would then be forced to announce the exact prefix, a scenario where legitimate routes would compete, exposing the forgery. This simple configuration change significantly enhances routing security.

The Real Risk: Undetected Hijacks and Service Disruptions

While invalid routes are largely dropped (observed by only 2 vantage points compared to 596 for valid routes), the remaining risk lies in forged routes that pass validation. These hijacks propagate globally, disrupting services and exposing users to malicious attacks.

Exploitation Mechanism: Forged route passes RPKI validation → Routers accept it as legitimate → Traffic is redirected to attacker-controlled infrastructure → Users are exposed to malicious code, data exfiltration, or service outages.

Addressing this vulnerability requires immediate action from providers to tighten ROA configurations in accordance with RFC 9319. By eliminating overly permissive ROAs, the integrity of internet routing can be preserved, preventing the exploitation of millions of vulnerable routes.

Case Study: The Virtualizor Update Attack

On August 28, a sophisticated attack exploited a critical vulnerability in the Resource Public Key Infrastructure (RPKI) framework, specifically targeting the Virtualizor update mechanism. The attack succeeded through a forged-origin hijack, enabled by an overly permissive Route Origin Authorization (ROA) within Hetzner’s network space. This case study dissects the technical mechanisms, systemic vulnerabilities, and implications for global routing security.

Attack Execution

The attacker announced a forged /24 prefix within Hetzner’s /16 address block. This announcement passed RPKI validation because Hetzner’s ROA was configured with a maxLength parameter set to /24. This configuration allowed any /24 prefix within the /16 block to be validated, regardless of whether legitimate /24 routes existed. In the absence of competing, more-specific routes, the malicious prefix propagated globally, hijacking traffic destined for Hetzner’s infrastructure.

Technical Breakdown

• ROA Misconfiguration: Hetzner’s ROA covered a /16 block but permitted announcements down to /24 via the maxLength parameter. This created a validation gap, allowing the attacker to announce a non-existent /24 prefix without detection.
• Absence of Competing Routes: No legitimate /24 routes existed within the /16 block to challenge the forged announcement. This absence ensured the malicious prefix passed RPKI validation uncontested.
• Global Propagation: Once validated, the forged route was accepted by routers worldwide, redirecting traffic to the attacker’s infrastructure. This disruption exposed users to malicious activities, including data exfiltration and injection of malicious code.

Impact and Scale

This attack exposed a systemic vulnerability: 16.2% of RPKI-covered IPv4 routes (138,698 out of 855,217) and 20.9% of IPv6 routes are protected by similarly permissive ROAs. This equates to approximately 18 million vulnerable routes susceptible to hijacking without detection. Disparities among hosting providers underscore the urgency of addressing this issue:

• Contabo: 97.6% of routes have permissive ROAs.
• DigitalOcean: 90.4% of routes are vulnerable.
• OVH: Only 11.5% of routes exhibit permissive configurations, demonstrating that stricter ROA management is both feasible and effective.

Mechanisms of Vulnerability

The root cause lies in the misuse of the maxLength parameter in ROAs. When maxLength is set to a value smaller than the prefix length, it permits the validation of more-specific prefixes within the covered block. If no legitimate routes exist at that level, attackers can exploit this gap to announce forged prefixes that pass RPKI validation. The causal chain is as follows:

1. Overly Permissive ROAs: maxLength allows validation of non-existent more-specific prefixes.
2. Absence of Competing Legitimate Routes: Forged announcements face no opposition, ensuring validation.
3. Forged Announcements Pass Validation: Malicious routes propagate globally, hijacking traffic.

Remediation and Best Practices

The solution requires strict adherence to RFC 9319, which recommends leaving the maxLength parameter unset. This ensures ROAs match only the exact prefix being announced, eliminating the validation gap. Providers like OVH demonstrate that stringent configurations are achievable and effective. Immediate action is imperative to secure the ~18 million vulnerable routes, as forged routes that pass validation pose a direct threat to internet routing integrity and user security.

The Virtualizor attack serves as a critical reminder: RPKI’s effectiveness hinges on precise ROA configurations. Without them, the framework’s security guarantees are compromised, leaving critical infrastructure vulnerable to hijacks and malicious exploitation. Addressing this vulnerability is not optional—it is essential to safeguarding the global routing ecosystem.

Scope of the Problem

The Virtualizor update attack on August 28 starkly demonstrated a critical vulnerability within the Resource Public Key Infrastructure (RPKI) framework. This incident exploited an overly permissive Route Origin Authorization (ROA) within Hetzner’s network, enabling a forged /24 prefix to pass RPKI validation. This attack was not an isolated event but a manifestation of a systemic issue: 16.2% of RPKI-covered IPv4 routes and 20.9% of IPv6 routes—approximately 18 million routes—remain vulnerable to forged-origin hijacks due to misconfigured ROAs.

Mechanism of Vulnerability

The root cause lies in the misuse of the maxLength parameter in ROAs, which introduces a validation gap exploitable by attackers. The process unfolds as follows:

• ROA Misconfiguration: When a ROA includes a maxLength value, it authorizes the announcement of more-specific prefixes within the covered address block. For instance, a ROA for a /16 block with maxLength=/24 permits any /24 prefix within that block to be validated, regardless of whether these prefixes are legitimately allocated.
• Validation Exploitation: Attackers leverage this permissiveness by announcing forged more-specific prefixes. Since the ROA validates these prefixes, they pass RPKI checks without competition from legitimate routes, effectively bypassing origin verification.
• Global Propagation: Once validated, the forged route propagates globally through BGP, hijacking traffic and redirecting it to malicious infrastructure. This enables critical threats such as data exfiltration, service outages, and malware distribution.

Real-World Impact: Provider Disparities

The prevalence of this vulnerability varies significantly among hosting providers, highlighting disparities in ROA management practices:

• Contabo: 97.6% of their routes have permissive ROAs, leaving 540 out of 553 routes exposed to hijacking.
• DigitalOcean: 90.4% of their routes are at risk, with 780 out of 863 routes vulnerable.
• OVH: Only 11.5% of their routes have permissive configurations, demonstrating that stringent ROA management is both feasible and effective in mitigating this vulnerability.

The Solution: RFC 9319 and Precise ROAs

The definitive solution lies in adhering to RFC 9319, which mandates omitting the maxLength parameter from ROAs. This ensures that ROAs validate only the exact prefix being announced, eliminating the validation gap. The causal chain of this fix is as follows:

• Exact Prefix Matching: Without maxLength, ROAs validate only the specific prefix announced, preventing forged more-specific prefixes from passing validation.
• Competitive Route Validation: Legitimate routes compete with forged announcements, exposing and blocking malicious prefixes during the BGP route selection process.
• Global Security Enhancement: Precise ROAs restore trust in RPKI, safeguarding millions of routes from hijacking and ensuring the integrity of internet routing.

Immediate Action Required

The consequences of inaction are severe. Failure to address these vulnerabilities could result in:

• Massive Route Hijacking: Millions of routes could be hijacked undetected, disrupting critical services and infrastructure.
• User Compromise: End-users would be exposed to malicious activities, including data theft, service disruptions, and malware injection.
• Erosion of Trust: The credibility of RPKI as a foundational security measure would be irreparably damaged.

Network operators must take immediate steps:

• Audit ROAs for permissive maxLength configurations and rectify misconfigurations.
• Implement RFC 9319 guidelines to enforce precise prefix matching.
• Collaborate with hosting providers to standardize and enforce stricter ROA practices across the industry.

The Virtualizor attack serves as a critical reminder: securing RPKI is not optional—it is imperative. The time to act is now, before the next hijack escalates into a global crisis.