For me, the real question is why did the transit provider accept a the hijacked prefix from someone that's not upstream of the victim?
Yeah... especially since as both AS62390:AS-NEXONHOST and AS-ZETNET do not contain (nor have in the last month) Hetzner, so I assume everything was just unfiltered.
Does anyone know if the transit provider has been asked comments?
ArsTechnica did ask for comment and got none https://arstechnica.com/security/2026/09/well-executed-bgp-attack-uses-hijac... On Thu, 3 Sept 2026 at 11:00, James Bensley <james@inter.link> wrote:
There is a nice write-up here: https://bgpkit.com/blog/virtualizor-bgp-hijack-anatomy/
For me, the real question is why did the transit provider accept a the hijacked prefix from someone that's not upstream of the victim?
Does anyone know if the transit provider has been asked comments?
With kind regards, James Bensley (he/him) ________________________________ From: Bryton Herdes via routing-wg <routing-wg@ripe.net> Sent: 01 September 2026 00:09 To: Antonis Chariton <daknob@daknob.net> Cc: routing-wg@ripe.net <routing-wg@ripe.net> Subject: [routing-wg] Re: RTBH and RPKI
⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. That was quick, good callout!
At the very least, the hijack would have been made much less effective with a /16 minimal ROA and solely an AS_PATH length and route preference battle.
-- Bryton Herdes Principal Network Engineer AS13335 - Cloudflare
On Mon, Aug 31, 2026 at 5:13 PM Antonis Chariton via routing-wg <routing-wg@ripe.net> wrote:
Just saw this:
https://www.virtualizor.com/blog/security-incident-bgp-hijacking/
Real BGP Hijack against Hetzner where the attackers managed to issue real Let’s Encrypt certificates despite the CA checking from multiple vantage points across different RIRs and ASNs.
The prefix had ROA, so the attackers spoofed the origin to use Hetzner’s AS.
The ROA was up to /24, Hetzner only advertised the /16. The moment the attackers advertised the spoofed /24 with a longer path they attracted 100% of the traffic.
Traffic went back to Hetzner within 20’ of them announcing this specific /24 and competing with the hijackers.
If that ROA was just for the /16 I bet this wouldn’t have happened, and I’m almost certain Let’s Encrypt would not have issued that certificate.
Antonis
On 26 Aug 2026, at 16:13, Tim Bruijnzeels <tbruijnzeels@ripe.net> wrote:
Hi all,
To clarify:
On 26 Aug 2026, at 14:52, Havard Eidnes via routing-wg <routing-wg@ripe.net> wrote:
I'll have to admit that I've not looked too closely under the
covers, but to my mind, if I originate 192.168.0.0/16 into the
routing system, and do not want to authorize any longer routes in
this address space than this /16, do I not then use the maxLength
attribute to say "16"? That's certainly what it looks like to me
through the RIPE NCC RPKI ROA issuance assistant..
The RIPE NCC RPKI Dashboard expects and explicit max length that defaults to the actual prefix length. This is essentially done this way to keep the UI simple. It forces the user to make an explicit choice (go with the default or change it).
On the encoded ROA object the max length is omitted if it matches the prefix length.
Kind regards,
Tim Bruijnzeels Principal Engineer RPKI RIPE NCC
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
[CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link | Web: inter.link ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/