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.

Table of Contents

1. What happened during the Softaculous BGP hijack?
2. Why did the /24 override the legitimate /16?
3. How could the route remain RPKI-valid?
4. Should you set maxLength in your ROA?
5. How a BGP hijack leads to valid TLS certificates
6. ASPA vs ROA: what’s the difference?
7. What to check before announcing a leased IPv4 block
8. RPKI-valid does not mean route-trusted

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:

Incident period	Start	End
First period	August 28, ~20:57 UTC	August 29, ~08:50 UTC
Second period	August 29, ~20:57 UTC	August 30, ~06:10 UTC

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:

Route	Role	What happens
162.55.0.0/16	Legitimate route	Covers the larger address range
162.55.80.0/24	More-specific route	Preferred for traffic inside the /24

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:

RPKI check	What the route showed	Result
Is the origin ASN authorized?	Origin appeared as AS24940	✓ Valid
Is the prefix length authorized?	/24 was permitted	✓ Valid
Is the complete AS path legitimate?	Standard ROV does not verify this	Not checked

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:

Configuration	Prefix	Origin ASN	maxLength
Broader authorization	203.0.0.0/16	AS64500	/24
Exact authorization	203.0.0.0/16	AS64500	/16

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.

Not sure your ROA matches what your network actually announces? Send us the prefix and ASN and we’ll compare the ROA, live announcement and IRR objects.

Support chat

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:

Stage	What happened
1. More-specific BGP route appears	A /24 is announced inside the legitimate /16
2. Traffic is redirected	Traffic for the affected range follows the /24
3. Certificate validation is affected	Validation requests also follow the hijacked route
4. Valid TLS certificates are obtained	The attacker can present trusted-looking HTTPS
5. Users and systems connect	Connections may not trigger obvious certificate warnings
6. Software delivery is affected	A malicious Virtualizor update reaches some installations

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.

	ROA	ASPA
Main purpose	Validate route origin authorization	Validate provider relationships
Connects	IP prefix → authorized ASN	Customer ASN → authorized providers
Main question	Which ASN may originate the prefix?	Which providers is the ASN authorized to use?
Helps identify	Unauthorized origins	Unexpected provider relationships
Deployment	Established	Still developing

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.

What to check	What to verify before announcement	Why it matters
Routing history	Previous origins, more-specific announcements and unusual route changes	Establishes whether the block has had unexpected routing activity
Authorized origin ASN	The ASN that should originate the block in the new setup	Prevents a mismatch between the intended origin and the ROA
ROA configuration	Authorized ASN and permitted prefix length	Ensures the ROA matches the actual announcement plan
IRR route objects	Existing route objects and the ASN they reference	Avoids stale routing records after operational control changes
Expected announcement size	Whether the block will be announced as the full prefix or as approved more-specifics	Helps avoid unnecessarily broad maxLength authorization
AS-path baseline	Expected upstreams and normal path structure	Makes unexpected provider or path changes easier to detect
Reputation and abuse history	Current blocklist status and recent abuse history	Identifies non-routing risks before production use
Geolocation	Whether major geolocation databases reflect the intended region	Reduces regional access and service issues after deployment

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