Can an RPKI-Valid Route Still Be Hijacked? What IPv4 Owners Should Know

Your IPv4 prefix has a valid ROA. Your monitoring dashboard shows RPKI: Valid. Does that mean the route is safe? Not necessarily.

In August 2026, infrastructure used by Softaculous and Virtualizor was affected by a BGP hijack in which a more-specific /24 was announced inside a legitimate /16. Traffic was redirected to attacker-controlled infrastructure during two separate periods between August 28 and 30. The incident also enabled the attacker to obtain valid TLS certificates and contributed to a malicious Virtualizor update reaching a small number of installations. The unusual part was that the malicious route was still considered RPKI-valid.

Key takeaway: RPKI-valid does not automatically mean route-trusted.

For IPv4 owners, lessees and network operators, the incident shows why routing security needs to go beyond checking whether a route simply passes Route Origin Validation.

What Happened During the Softaculous BGP Hijack?

At approximately 20:57 UTC on August 28, 2026, a new BGP announcement appeared for: 162.55.80.0/24 That prefix sits inside the larger: 162.55.0.0/16 normally originated by Hetzner Online through AS24940. The affected /24 contained addresses used by Softaculous infrastructure, including software update systems and client-facing services. Softaculous reported two periods of incorrect routing:

During these periods, traffic intended for legitimate Softaculous systems could instead be routed toward attacker-controlled infrastructure.

Why Did the /24 Override the Legitimate /16?

The reason is a fundamental rule of IP forwarding: the most-specific matching prefix normally wins. A router that sees both of the following routes will generally prefer the /24 for addresses inside that smaller range:

The attacker therefore did not need to replace or hijack the entire /16. A single more-specific /24 could attract traffic for the systems located inside that range. LACNIC’s technical analysis described the event as a more-specific hijack of Hetzner’s normal /16 announcement.

How Could the Route Remain RPKI-Valid?

This is the most important part of the incident. The suspicious route was observed with an AS path resembling: … → AS6204 → AS62390 → AS24940 The rightmost ASN — the origin presented by the route — was AS24940, Hetzner’s legitimate ASN. The existing ROA also allowed prefixes within the /16 to be announced as specifically as /24. That meant two important Route Origin Validation checks succeeded:

The result was therefore:

RPKI status: Valid

The route passed origin validation even though the surrounding BGP path was associated with the hijack.

What Does Route Origin Validation Actually Check?

ROV essentially asks:

Is this ASN authorized to originate this IP prefix?

It does not prove that every autonomous system appearing earlier in the AS path represents a legitimate routing relationship. That distinction matters. An attacker who can make the authorized ASN appear in the origin position may be able to create a route that passes origin validation even though the route itself is malicious.

Should you set maxLength in your ROA?

The incident also shows why ROA configuration matters. A ROA can authorize a larger prefix while using maxLength to permit more-specific announcements. For example:

With the first configuration, the ASN can originate more-specific prefixes down to /24 and have them pass Route Origin Validation. That may be operationally useful when the network actually advertises those more-specific routes. But if those prefixes are never used, the authorization can be broader than necessary.

RFC 9319 recommends using minimal ROAs whenever possible and generally avoiding maxLength unless there is a specific operational need. The objective is to reduce the attack surface for forged-origin sub-prefix hijacks.

Following the Softaculous incident, Hetzner changed the ROA for 162.55.0.0/16 so that its maxLength became /16, removing the previous authorization for more-specific prefixes under that ROA.

A practical question for IPv4 owners

Does your ROA authorize more-specific prefixes that your network never actually announces?

If the answer is yes, your authorization may be broader than your current routing requirements.

How a BGP hijack leads to valid TLS certificates

The routing hijack was only the first stage. Softaculous reported that attacker-controlled infrastructure was able to obtain new TLS certificates for affected domains because certificate-validation traffic was also routed through the hijacked network path. The incident then affected Virtualizor’s update infrastructure. Softaculous confirmed that a malicious update reached a small number of Virtualizor installations. The sequence can be summarized like this:

This shows why BGP security is not limited to routers. Internet routing sits beneath services such as:

• TLS certificate validation;
• software repositories;
• APIs;
• DNS infrastructure;
• authentication endpoints;
• customer portals;
• payment and billing systems.

A routing compromise can therefore become the first step in a much broader infrastructure attack.

ASPA vs ROA: what’s the difference?

This is where ASPA — Autonomous System Provider Authorization — becomes relevant. ROA and ASPA address different parts of routing security.

After the incident, Hetzner also added an ASPA record identifying authorized providers for AS24940. According to the technical analysis, networks performing ASPA validation could use that information to reject paths containing an unauthorized upstream relationship such as the one observed in this event. ASPA does not replace ROAs. The mechanisms protect different parts of routing information.

A stronger routing-security model combines these signals rather than relying on only one of them.

What to check before announcing a leased IPv4 block

Before a newly leased IPv4 block is announced, the routing state should be checked against how the block will actually be used.

If the block moves to a different ASN, transit provider, cloud environment or BYOIP setup, update the relevant routing authorization and route objects before announcing it.

Registry ownership or lease status can remain correct while the routing configuration is still outdated. The operational check should therefore be performed against the planned live announcement, not only against registry data.

RPKI-Valid Does Not Mean Route-Trusted

The Softaculous incident demonstrated an important limitation of Route Origin Validation: the malicious /24 could satisfy the ROA because the apparent origin matched the authorized ASN and the ROA permitted that prefix length.

RPKI remains an important routing-security layer, but it answers a specific question about origin authorization. It does not validate the complete AS path. For IPv4 owners, lessees and operators, the practical conclusion is to keep ROAs precise and combine origin validation with route and path monitoring.

Do not stop your routing-security checks when a route says “RPKI Valid.”

Sources

• Softaculous — Security Incident: BGP Hijacking Update
• LACNIC — Latest BGP Hijack Targets Hosting Software Vendor
• RFC 9319 — The Use of maxLength in the RPKI

Vladislava Shadrina

Customer Account Manager