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:
| 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.
Normal routing
162.55.0.0/16 announced by the legitimate network
Traffic follows the /16
Legitimate infrastructure receives the traffic
During the hijack
162.55.80.0/24 appears as a more-specific route
Traffic for 162.55.80.x follows the /24
Traffic can be redirected
Caption: BGP forwarding prefers the more-specific /24 over the /16 for addresses inside that range.
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.
ROA authorization
Prefix: 162.55.0.0/16
Authorized origin: AS24940
More-specifics allowed to /24
—
Hijacked announcement
Prefix: 162.55.80.0/24
Apparent origin: AS24940
Prefix length: /24
Path included unexpected ASes before the origin
Validation result
✓ Origin ASN matched
✓ Prefix length matched ✓ RPKI VALID
But: the complete AS path was not validated by ordinary ROV.
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.
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.
Security layer — Question it helps answer
ROA
Is this ASN allowed to originate this prefix?
ROV
Does the current BGP origin match the ROA?
ASPA
Is this provider relationship authorized?
BGP monitoring
Has the prefix, origin or AS path changed unexpectedly?
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.”
Browse available IPv4 blocks by RIR and region on the InterLIR Marketplace.
