BGP Hijacking: How an ISP Can Protect Its IP Prefixes

RPKI/ROV, strict prefix filtering, control-plane protection and route monitoring — a complete audit methodology for network operators, based on a real BGP hijack.

October 24, 2026 · SunuCyberSecurity Team · Expert level · Network administrators, telecom operators, ISPs, BGP engineers, security managers

Source: real Softaculous/Virtualizor incident, August 28-30, 2026 — details and sources in section 2

The Border Gateway Protocol (BGP) is one of the foundational mechanisms of how the Internet works. It lets autonomous systems (AS) exchange routing information and determine how to reach the IP prefixes announced by other networks.

But this essential function is also an attack surface. An incorrect or malicious route announcement can hijack traffic destined for a legitimate network, make a service unreachable, or, under certain conditions, expose communications to infrastructure controlled by an attacker.

In late August 2026, a real BGP hijack targeted an address range used by Softaculous's infrastructure (hosted at Hetzner) and served, during the hijack window, a modified Virtualizor software package to certain installations checking for an update. The incident, documented by Virtualizor and Softaculous themselves and then covered by several security-focused outlets, concretely illustrates the importance of RPKI, route-origin validation, BGP filtering and cryptographic verification of software updates.

For Internet service providers, this incident is a reminder of a fundamental rule: routing security must be ensured in the BGP control plane, in announcement policies, and in the systems that consume the routed traffic.

This article covers the main BGP hijacking scenarios, the defense mechanisms to deploy, and an audit methodology adapted to ISP infrastructure.

1. Understanding BGP hijacking

BGP hijacking refers to a situation in which an autonomous system announces routes that cause part of the traffic to be routed through an illegitimate path.

Every IP prefix is associated with a routing announcement. BGP routers evaluate several attributes and policies to select the best path. Contrary to a common assumption, BGP does not, on its own, provide a universal cryptographic mechanism proving that every announcement is legitimate.

An incident can notably result from three scenarios.

1.1. Announcing a more-specific prefix

A legitimate network announces, for example, 203.0.112.0/23. Another AS announces a sub-prefix such as 203.0.112.0/24 without authorization.

On routers that accept this announcement, the longest-prefix-match rule can route traffic destined for that more-specific range to the wrong network, even if the original path looks preferable by other BGP attributes.

The exact outcome, however, depends on operators' policies and the announcement's propagation.

1.2. Announcing an existing prefix with a misleading path

An attacker can announce a legitimate prefix while presenting an AS path that influences routing decisions. The route will not necessarily be accepted everywhere: providers' policies, prefix filters, RPKI validation and other BGP attributes affect how it is handled.

1.3. Route leaks

A route leak happens when a network propagates routes beyond its intended routing policy — for example by redistributing to one provider routes learned from another provider.

A leak can be accidental or malicious. It can cause congestion, traffic redirection or a connectivity outage, without necessarily resulting from a computer intrusion.

It is therefore important to distinguish malicious hijacking, misconfiguration and route leaks. The defensive measures overlap, but investigation and attribution are not identical.

2. Why the August 2026 incident matters

Between August 28, 2026 at 20:57 UTC and August 30 at 06:10 UTC — roughly 33 hours — a sub-prefix, 162.55.80.0/24, part of the address space used by Softaculous's services at Hetzner, was announced by AS62390 (identified by Softaculous as NexonHost) via transit provider AS6204. This announcement, more specific than the legitimate 162.55.0.0/16 route, hijacked traffic to a server controlled by the attacker — who had obtained a valid Let's Encrypt certificate for the hijacked destination, avoiding any client-side certificate warning.

During that window, a modified Virtualizor update package was served to installations that queried the update service during the same period. Softaculous states it cannot produce a definitive list of affected installations. One hosting provider that audited its own fleet reported confirmed root-level compromise on 5 of the 34 hypervisors it checked. Virtualizor shipped the fixed version 3.2.9.9, including a new security-analysis tool, on September 1, and recommends rotating API credentials and auditing any server that may have been exposed during the window.

This example illustrates a chain of risk:

1. An incorrect or malicious BGP announcement changes the path of traffic.
2. Legitimate requests reach infrastructure that was not intended.
3. The trust mechanisms of the consuming system are put to the test.
4. If cryptographic verification of packages is insufficient, a tampered package can be accepted.
5. A software compromise can then occur well beyond the router that suffered or propagated the routing incident.

An overreaching conclusion should be avoided, however: a BGP hijack does not automatically decrypt HTTPS traffic and does not guarantee that a malicious package will be accepted. The outcome depends on TLS configuration, certificate validation, package signing, and the application's own security controls.

Sources: Virtualizor — Security Incident · Softaculous — Security Incident · The Hacker News · BleepingComputer.

3. Risks specific to an ISP

For an Internet service provider, a BGP anomaly can have consequences that go well beyond a single server.

Service unavailability

An incorrect announcement can cause a loss of connectivity to services, payment platforms, DNS, authentication systems, or applications hosted abroad.

Traffic redirection

Hijacked traffic can arrive via an unintended path. Depending on the protocol and security controls, this can cause connection errors, degraded performance, or increased exposure to on-path attacks.

Supply-chain compromise

Management systems, hypervisors, billing platforms, or update servers may depend on external services. A change in the network path can therefore become a risk factor for the software supply chain.

Erosion of subscriber trust

An outage or redirection affecting several destinations can be perceived by subscribers as a general failure of their Internet access. The operator must be able to distinguish a local outage, a transit problem, a DNS incident, and a global routing anomaly.

4. RPKI and ROV: an essential defense against illegitimate announcements

Resource Public Key Infrastructure (RPKI) lets holders of IP resources cryptographically authorize specific autonomous systems to announce certain prefixes. These authorizations are published as ROAs (Route Origin Authorizations).

Route Origin Validation (ROV) then lets a network compare a BGP route's origin AS against the available RPKI authorizations.

The usual outcomes are:

• Valid: the origin and prefix length match a valid authorization.
• Invalid: the announcement contradicts an authorization — for example, the origin AS is not authorized, or the prefix is more specific than the authorized maximum.
• NotFound: no matching RPKI authorization is available.

What RPKI/ROV protects — and what it does not

ROV lets an operator reject or deprioritize announcements with an invalid origin, depending on policy. It therefore reduces a significant class of hijacks.

However, ROV does not prove that every AS path is legitimate, and it does not catch every route leak. An announcement from an authorized AS can still reflect a policy problem or a compromise.

It does not replace prefix filters, AS-path controls, route monitoring, or incident response procedures.

Implementation recommendations

For prefixes owned by the operator:

1. Inventory every IPv4 and IPv6 prefix actually announced.
2. Create or verify the corresponding ROAs with the appropriate Regional Internet Registry.
3. Verify the authorized origin AS and the maximum prefix length.
4. Deploy redundant RPKI validators.
5. Apply a documented ROV policy to received routes.
6. Monitor route-state changes and validation errors.

An incorrect ROA can make a legitimate announcement invalid. It is therefore necessary to verify authorizations before applying a strict rejection policy in production.

5. BGP filtering: limiting announcements to expected routes

Prefix filtering must be applied to eBGP sessions, both inbound and outbound.

Outbound

An ISP must announce only the prefixes it is authorized to announce. Outbound policies should be explicit and tailored to each neighbor.

Inbound

The policy depends on the relationship with the neighbor:

• Full transit: accept the expected Internet routes per the agreed policy, while rejecting prohibited prefixes and clearly incorrect announcements.
• Default-route provider: accept only the default route if that is indeed the agreed service.
• Peering peer: limit announcements to the prefixes expected from that peer.
• Customer: apply route filters matching the customer's authorized prefixes and the agreed propagation policies.

Filters must be generated or verified from reliable sources, then tested. A poorly built allowlist can break legitimate routing; an overly permissive filter lets through unwanted announcements.

Complementary measures

• Apply prefix-count limits consistent with each session.
• Control AS paths according to the commercial relationship and routing policy.
• Reject special-use, non-routable, or the operator's own address space when it should not be received on that session.
• Control unauthorized sub-prefix announcements.
• Document exceptions and their validity period.

AS-path filtering is useful, but it is not on its own cryptographic proof of legitimacy: an announced path can be misleading or manipulated.

6. Protecting BGP sessions and the control plane

BGP runs over TCP, typically on port 179. Sessions should be established only with intended neighbors and through the appropriate transport interfaces.

Protective measures include:

• filtering traffic destined for the control plane;
• allowing BGP sessions only from the expected peer addresses;
• using available and compatible neighbor-authentication mechanisms;
• considering GTSM/TTL Security where the topology allows it;
• applying appropriate Control Plane Policing (CoPP) policies;
• monitoring session state changes and unusual resets;
• protecting administrative access through dedicated management networks.

Authenticating a BGP session helps protect the connection between neighbors, but does not by itself validate the legitimacy of every announced prefix. It must be combined with routing policy and origin validation.

7. Monitoring route announcements in real time

An ISP should not wait for subscriber complaints to detect a hijack. It must monitor prefix changes, AS paths, origins, and unusual routing variations.

Indicators to monitor

• appearance of an unexpected sub-prefix;
• sudden change of origin AS;
• a route becoming RPKI Invalid;
• unusual spike in announcements or withdrawals;
• abnormal variation in the number of prefixes received from a neighbor;
• repeated resets of a BGP session;
• a changed path toward critical destinations;
• increased packet loss or connection errors toward several networks.

Global route-monitoring platforms and BGP collection feeds can complement local router data. Alerts should be correlated with configuration changes, maintenance windows, and transit-provider incidents.

Distinguishing a routing incident from a DNS or application problem

An unreachable destination does not necessarily mean a BGP hijack.

The investigation should compare:

1. DNS resolution;
2. routes toward the destination addresses;
3. paths observed from several networks;
4. RPKI states;
5. TCP and TLS connectivity;
6. incidents reported by transit providers.

An announcement change observed from several collectors, combined with an unexpected sub-prefix and an unauthorized origin, is a far stronger signal than a simple connection failure.

8. Responding to a suspected BGP hijack

Phase 1 — Confirm the anomaly

• Identify the affected prefix and its expected origin.
• Compare routes seen locally with observations from multiple external collectors.
• Check the ROAs and the RPKI result.
• Review policy changes and neighbor events.
• Determine whether the incident is local, limited to one provider, or visible Internet-wide.

Phase 2 — Contain the incident

• Contact the relevant transit provider or peer through the agreed incident channels.
• Request validation or withdrawal of an unauthorized announcement when justified.
• Fix faulty filters or policies after validation.
• Avoid improvised sub-prefix announcements: they can worsen the incident or be filtered by other networks.

Phase 3 — Assess dependent systems

If update servers, hypervisors, billing systems, or administrative services may have been reached via the hijacked path:

• review logs and update history;
• verify signatures and checksums published by the vendor through a trusted channel;
• look for configuration changes or persistence mechanisms;
• revoke or renew any secrets that may have been exposed;
• isolate systems suspected of compromise per the incident-response plan.

Phase 4 — Restore and learn

• confirm the stability of legitimate announcements;
• verify that traffic has returned to the expected paths;
• document the causes and decisions made;
• fix filters and procedures;
• improve alerting and run a validation exercise.

Restored routing does not mean that systems which received hijacked traffic are automatically clean.

9. Recommended action plan for an ISP

These timelines are indicative implementation targets. Networks facing an ongoing incident must address the relevant measures immediately, without waiting for the proposed schedule.

Conclusion

BGP hijacking is a systemic risk: a routing anomaly can affect destinations, service providers, and software update chains that appear entirely unrelated to one another.

For ISPs, defense rests on several complementary layers: RPKI/ROV for origin validation, strict prefix filtering, BGP session protection, control-plane hardening, and route monitoring at both local and global scale.

The Softaculous/Virtualizor incident of August 2026 is also a reminder that robust network security is not enough if dependent systems accept updates without proper cryptographic verification.

A resilient network does not simply forward routes: it verifies which ones it should accept, monitors their changes, and has an operational procedure to react quickly.

References

1. Virtualizor — Security Incident (official advisory), August 31, 2026
   virtualizor.com/blog/security-incident-bgp-hijacking
2. Softaculous — Security Incident (official advisory), August 2026
   softaculous.com/blog/security-incident-bgp-hijacking-update
3. The Hacker News — BGP Hijack Delivers Malicious Virtualizor Update That Establishes Persistent Root Access, September 2026
   thehackernews.com/2026/09/bgp-hijack-delivers-malicious.html
4. BleepingComputer — Hackers push malicious Virtualizor update in BGP hijacking attack
   bleepingcomputer.com/.../hackers-push-malicious-virtualizor-update-in-bgp-hijacking-attack
5. Cisco — Protecting Border Gateway Protocol for the Enterprise
   sec.cloudapps.cisco.com/security/center/resources/protecting_border_gateway_protocol
6. Internet Society — Continued Progress in African DNS Security, for broader context on the resilience of African Internet infrastructure
   pulse-dev.internetsociety.org/.../continued-progress-in-african-dns-security

Note: the events and indicators of the August 2026 incident are reported from the official advisories published by Virtualizor and Softaculous, cross-checked against coverage from The Hacker News and BleepingComputer. General BGP recommendations draw on Cisco documentation and routing-security best practices. Any configuration applied in production must be adapted to the topology and tested before deployment.

Related reading

Check your own exposure

A free scan, in minutes, no credit card required.