Skip to content
Wednesday, October 21, 2026AboutContactRSS
Cyber Attacks

Virtualizor Attack Highlights 16% of RPKI Routes Vulnerable to Hijacks

Analysis shows a significant portion of internet routing remains open to forged-origin attacks that bypass standard validation checks.

Illustration: A network cable snaps mid-air, severing the connection to a blinking router.
AI-generated illustration: DataSafe Radar

Key points

  • IPinfo data reveals 138,698 IPv4 routes have loose ROA settings allowing valid hijacks.
  • The August 28 Virtualizor update attack exploited this specific routing configuration gap.
  • Major hosting providers like Contabo and DigitalOcean have high percentages of exposed routes.

Internet users and customers of major hosting providers face ongoing routing security risks, as analysis indicates that a significant share of the internet’s infrastructure remains vulnerable to origin hijacks. Data from IPinfo shows that 16.2 percent of RPKI-covered IPv4 routes are configured in a way that allows attackers to announce forged, more-specific routes that still pass validation checks. This structural weakness means that even with Route Origin Validation enabled, malicious traffic can be accepted by the global routing system without triggering alerts or being dropped by upstream providers.

The August 28 Virtualizor update attack demonstrated how this vulnerability operates in practice, according to IPinfo. The attackers used a forged-origin /24 route within Hetzner’s address space to distribute malicious software updates. Because Hetzner’s Route Origin Authorization covered the broader /16 block and permitted announcements down to /24, the fake route appeared legitimate to validators. No legitimate /24 route existed to compete with the attacker’s announcement, allowing the hijacked traffic to flow through the network unchecked by standard RPKI safeguards.

Scope of the Routing Exposure

IPinfo measured the prevalence of this setup across the internet to determine how common such exposure is. Of 855,217 RPKI-covered IPv4 routes, 138,698 have a ROA that is looser than the route actually announced, with no more-specific legitimate route filling the gap, according to the report. This configuration creates roughly 18 million potential more-specific routes that an attacker could announce today and have them come out RPKI-valid and uncontested. For IPv6, the situation is slightly worse, with 20.9 percent of covered routes exhibiting this same vulnerability, leaving a larger surface area for potential manipulation of internet traffic paths.

Who Is Most Affected

The risk is not evenly distributed across the internet, with some hosting providers leaving far more of their infrastructure exposed than others. Contabo leaves 540 of its 553 covered routes open to this type of attack, while DigitalOcean has 780 of 863 routes in a vulnerable state, according to IPinfo. OVH shows a significantly lower exposure rate, with only 11.5 percent of its routes affected. These disparities suggest that customers of certain providers may face higher risks of encountering compromised services or traffic redirection if attackers target these specific routing configurations.

Our take on the response

The industry has moved to drop invalid routes, with typical valid routes seen by 596 vantage points compared to just two for invalid ones, according to IPinfo. However, the remaining risk lies in routes that pass the check rather than fail it. RFC 9319 offers a technical fix by recommending that administrators leave the maxLength parameter unset in ROAs, ensuring a ROA only matches the exact block being announced. That suggests a shift in configuration standards is needed to close the gap between broad authorizations and specific route announcements, but adoption remains uneven.

For customers and users

Affected customers should verify whether their hosting provider has updated its routing configurations to align with stricter security standards. Users should monitor for unusual service interruptions or unexpected traffic redirects, which can indicate routing anomalies. Check official provider channels for announcements regarding infrastructure updates or security patches. Be cautious of unsolicited communications claiming to be from your provider about account changes or updates, as attackers often follow infrastructure exploits with phishing attempts. Verify any urgent requests through independent contact methods rather than clicking links in emails or messages.

What to do and how to stay safe: Virtualizor

  • Review your hosting provider's security documentation to see if they have implemented stricter ROA configurations or adopted RFC 9319 recommendations.
  • Monitor your network traffic for anomalies or unexpected routing changes that could indicate a hijack or redirection attempt.
  • Verify the authenticity of any security-related communications from your provider by checking their official website or contacting support directly.
  • Ensure your own systems are protected against malicious updates by verifying the integrity of software sources and using code signing where possible.

Step-by-step guide: Incident Response Plans: How to Stop Damage When Attacks Happen

General security guidance from the DataSafe Radar newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

How did the Virtualizor attack bypass security checks?

The attack used a forged-origin route that was technically valid under RPKI because the provider’s ROA allowed more-specific announcements within its block.

Which hosting providers are most exposed?

Contabo and DigitalOcean have high percentages of exposed routes, with Contabo leaving 540 of 553 covered routes open, according to IPinfo.

Is there a fix for this vulnerability?

RFC 9319 recommends leaving the maxLength parameter unset in ROAs to prevent loose authorizations, but widespread adoption is not confirmed.

Sources

  1. r/netsec
VirtualizorIPinfoRPKIBGPHetzner

Related stories