The August 2026 Virtualizor Incident in BGPHorizon

Between 28 and 30 August 2026, a block of Hetzner address space used by Softaculous and Virtualizor was hijacked. Traffic for those addresses was pulled toward an attacker's server for roughly 33 hours across two waves. It was also reported that the attacker obtained a technically valid TLS certificate for the affected domains, and that a small number of Virtualizor installations received a malicious update package while their traffic was diverted.

Softaculous published a detailed, transparent post-mortem with a minute-by-minute measurement table reconstructed from public RIPE data. This post is more of a guide on how BGPHorizon can detect similar incidents. Read theirs for the full impact story and remediation steps. What we want to show here is:

• What this hijack looked like inside BGPHorizon
• Why it is the kind that ordinary origin-based checks miss
• How you would have been alerted in real time if you had been monitoring that space.

None of the routing evidence here is unique to BGPHorizon. It sat in the public record for anyone to read. The part we most want to demonstrate with this post is the ease of use to investigate such an incident, and our alerting capability. If this had been your address space and you had a monitor on it, the alert below would have hit your Slack and inbox at 20:57 UTC on 28 August.

Summary

• On 28 August 2026 at 20:57:30 UTC, 162.55.80.0/24, a more-specific of Hetzner's 162.55.0.0/16, appeared in the global routing table for the first time. Hetzner had never announced that /24 on its own.
• The announcement was propagated by AS62390 (NexonHost) via transit AS6204 (Zet.net), but the attacker kept AS24940 (Hetzner) on the tail of the AS path as a spoofed origin. Example path: ... 6204 62390 24940.
• Because it was more-specific than Hetzner's /16, it won route selection everywhere it propagated. Because the origin still read as Hetzner, it raised no MOAS conflict, and it validated clean under RPKI, the two checks most people rely on. Hetzner's ROA authorizes AS24940 to originate down to /24, and the forged /24 fit inside it exactly.
• BGPHorizon still flagged it at as origin_mismatch_new, a previously unseen more-specific of Hetzner's space, at high severity, seen by 176 peers across the 24 collectors BGPHorizon analyzes. The interloper networks (AS62390 and AS6204) sit one hop into the AS path.
• The hijack ran in two waves, 28 Aug ~21:00 to 29 Aug ~08:50, and 29 Aug ~20:00 to 30 Aug ~06:00, with heavy route flapping in between, matching what Softaculous measured.

How this is different from hijacks we have seen in the past

Hijacks with invalid RPKI are more noisy. A network that has no business announcing a prefix announces it anyway, and if the real owner publishes RPKI ROAs, the rogue route comes up provably RPKI-invalid and shows as a MOAS conflict at the same time. Several independent signals fire at once and the case makes itself.

This one was a bit more stealthy. The attacker did two things to stay under the radar.

1. They kept the real origin. Instead of originating the prefix from their own AS, they placed AS24940 (Hetzner) at the end of the path, so to an origin-only check the announcement looks like Hetzner announcing Hetzner's own space. No MOAS conflict, and nothing for RPKI origin validation to reject.
2. They went more-specific. Hetzner announces 162.55.0.0/16. The hijack was a /24 inside it. A longer prefix always wins in the routing table, regardless of path length or RPKI status, so the /24 quietly displaced the /16 on every network that accepted it.

That combination is what makes a forged-origin, more-specific hijack both effective and stealthy. RPKI marked this route valid, not invalid. Hetzner's ROA covers 162.55.0.0/16 with a max length of /24 and origin AS24940, so a forged /24 with AS24940 on the tail satisfied it exactly. RPKI Route Origin Validation, the control most operators reach for first, would have passed this route through, not dropped it. What catches it is history. 162.55.80.0/24 had never appeared in the 15 months of routing history we hold before 20:57 UTC on 28 August, and that is the signal BGPHorizon keys on.

Step 1: Open the prefix

Go straight to the prefix overview and set the window to late August:

https://bgphorizon.com/prefix/overview?prefix=162.55.80.0%2f24&start_date=2026-08-01&end_date=2026-08-31

The overview shows three things at a glance. The prefix carries a red detections badge. The Activity over time panel shows two sharp bursts on 28 to 30 August against an otherwise empty history, since this /24 did not exist as its own route before the incident. And the observed origin reads as AS24940 (Hetzner), the spoof.

Step 2: Read the detection

Open the Detections tab. At 28 Aug 2026 20:57:30 UTC, BGPHorizon recorded:

Detection	Severity	Confidence	What it means here
origin_mismatch_new	High	Medium	A more-specific of 162.55.0.0/16 that we had never observed before suddenly appeared, a brand-new /24 carved out of Hetzner's block

One high-severity detection, not a wall of red, because the attacker avoided the origin and RPKI tripwires. That single detection fired at the exact second the hijack began (20:57:30 UTC), corroborated by 176 distinct peers across 24 independent collectors (the collection points BGPHorizon Analyzes). The onset time matches, to the second, the first unauthorized announcement Softaculous observed in RIPE data (2026-08-28T20:57:30Z).

Step 3: Follow the path

The detection tells you something new appeared. The AS paths tell you who put it there. Drill into the raw events behind the detection and every hijacked announcement funnels through the same two networks before it reaches the spoofed Hetzner origin:

24482 6204 62390 24940
3491  5511 6204 62390 24940
16552 3257 6204 62390 24940
49544 6204 62390 24940

Read the tail inward. The announcement claims to originate at AS24940 (Hetzner), but the hop feeding it is AS62390 (NexonHost), reached via transit AS6204 (Zet.net), networks with no legitimate role in originating Hetzner's space. That ... 6204 62390 24940 tail is the fingerprint of the hijack, and it was identical on every vantage point that saw it.

When the origin is spoofed, the truth is one hop up the path. A prefix's own history plus the AS path together expose a hijack that origin validation alone calls clean.

Step 4: See both waves in the raw events

Set the events view across the whole incident and the two-wave structure Softaculous documented is right there in the announcement and withdrawal churn:

• Wave 1, 28 Aug ~21:00 to 29 Aug ~08:50 UTC
• Lull, 29 Aug ~09:00 to ~20:00 UTC. Hetzner briefly announced the /24 directly as a countermeasure, then everything returned to the clean /16.
• Wave 2, 29 Aug ~20:00 to 30 Aug ~06:00 UTC
• Restored, 30 Aug ~06:10 UTC onward

The route was extremely unstable throughout, with thousands of withdrawals, which is why any single collector snapshot taken mid-wave can undercount it. The raw event stream, not a single snapshot, is what lets you see the true envelope.

How you would have been alerted

Here is the part that matters if this is ever your address space. Detection after the fact is useful, but a page at 20:57 UTC is better.

If you had a monitor on 162.55.0.0/16 with more-specifics included, or on AS24940, BGPHorizon would have delivered this the instant the detection opened, to whichever channels you had attached. Slack:

And a high-severity email:

A note on what the alert shows. The title reads AS24940 because that is the origin the attacker forged, and the alert reports what was announced. A high-severity new more-specific of your own space, attributed to your own AS, that you did not announce, is exactly the shape of a forged-origin hijack. It is your cue to open the prefix and read the path, where AS62390 and AS6204 are waiting. Monitoring the space also means you see it even when, as here, the provider's own alerting never fired.

These screenshots are real alerts, not mockups. They were produced by replaying the actual recorded incident through the same notifier that sends production alerts.

Timeline (UTC)

• 28 Aug 20:57:30, 162.55.80.0/24 first announced via ... 6204 62390 24940. BGPHorizon opens a high-severity origin_mismatch_new. It is more-specific, so it wins routing wherever it reaches.
• 28 Aug ~21:00 to 29 Aug ~08:50, Wave 1, accepted across essentially every vantage point that received it, with heavy flapping.
• 29 Aug ~08:50, Hetzner begins announcing the /24 directly, and diversion drops to zero within minutes.
• 29 Aug ~09:00 to ~20:00, lull, traffic back on the legitimate /16.
• 29 Aug ~20:00 to 30 Aug ~06:00, Wave 2.
• 30 Aug ~06:10, unauthorized route withdrawn and normal routing restored globally.

Routing Indicators

All indicators, both from BGPHorizon and corroborated by Softaculous's RIPE-based measurements:

• Hijacked prefix: 162.55.80.0/24, a more-specific of Hetzner's 162.55.0.0/16
• Spoofed origin, kept on path tail: AS24940 (Hetzner)
• Injecting network: AS62390 (NexonHost)
• Transit provider: AS6204 (Zet.net)
• Characteristic AS-path tail: 6204 62390 24940
• First observed: 2026-08-28 20:57:30 UTC. Restored: 2026-08-30 ~06:10 UTC

Host and application indicators are in Softaculous's advisory: a fraudulently obtained Let's Encrypt certificate across their product domains, and a malicious java-jre-update.service systemd unit on affected Virtualizor servers. If you run Virtualizor, Webuzo, Softaculous, or related products, follow their advisory's checklist.

Reproduce it yourself

• 162.55.80.0/24 overview: open in BGPHorizon
• Detections for the same window: open
• For contrast, Hetzner's covering block 162.55.0.0/16: open

Takeaways

• RPKI ROV is necessary but not sufficient. Origin validation stops the loud RPKI-invalid hijacks, but it does nothing against a forged-origin, more-specific hijack like this one. Here the route validated as RPKI-valid, so ROV would have accepted it. Validate and drop RPKI-invalids, but do not assume a valid route is a safe one.
• Monitor your own space, and alert on new more-specifics. The single most reliable signal in this incident was history: a /24 that had never existed suddenly did. A monitor on your prefixes that pages on new more-specifics of your space, especially ones you did not announce, would have caught this at 20:57 UTC, before the certificate fraud and the malicious package ever landed.

Monitor your own networks

Use BGPHorizon for free to watch your own ASNs and prefixes. Create a free account, add the space you care about, attach a Slack, email, or webhook channel, and get paged the moment a new more-specific, an unexpected origin, or an RPKI-invalid route appears, exactly like the alert above, at the moment it happens.