The downfall of bgp.exchange: how a volunteer peering exchange lost its domain, mail and management plane in a day

For a few years, bgp.exchange was one of the friendliest on-ramps into real-world peering. It was a volunteer-run virtual exchange with route servers in several countries, and its public footprint listed roughly 510 participant networks (ETTAYEB, Knut Michael Haugland). Hobbyists, lab networks and small operators used it to learn BGP with live sessions instead of slides.

In September 2026 that project lost its management plane in about a day: its hypervisor, its application and database servers, its mail system, its website, its DNS and finally its domain. This is how it happened, based only on public records and on what the operators themselves have said. Where nobody knows, I say so.

A note before we start: I won't link the old domain. The operators themselves say it must still be treated as compromised.

Before the fall

The registry record (RDAP) shows the domain was registered on April 1, 2021, and is paid up until April 1, 2028. It never lapsed. Certificate transparency logs (crt.sh) look boring until September 12, 2026: one certificate per host, renewed on schedule.

On September 6, Haugland received an ordinary-looking sponsorship request from the project's support address through its mailing platform, asking for servers, network gear, connectivity or money. He kept the full headers, and it serves as his clean baseline for everything that followed (source).

September 12: the mail starts

The operators put the start of their incident window at about 3:00 AM PHT on September 12 (their status page lists it as about 05:00 AEST).

That afternoon, members started getting mail they never should have received. Haugland kept the full headers, and they show the abuse moving through more than one sending path. At 4:38 PM PHT a harassing message went out through SMTP2GO, the same campaign platform the genuine sponsorship email had used. Between 5:05 and 5:09 PM PHT, three more messages went out through the project's own mail servers by authenticated submission, signed with its DKIM keys, carrying harassment, Nazi song lyrics and political text. These messages weren't spoofed.

At 4:51 PM PHT a user opened a thread on r/networking asking whether anyone else got the "weird" mail. Replies reported real member data in the messages, including full names, and at least one member said they ended their membership because of it. Born's Tech and Windows World and ETTAYEB reported the same pattern: harassment, obscenities in Cantonese and real member names.

The website and the services go dark

The homepage was replaced with an abusive defacement page: a mix of political flags and slogans, a Nazi flag and personal attacks accusing the operators of financial exploitation and of wasting resources on a virtual IXP. I'm not reproducing any of it.

Nobody has a public record of when the page first went up. The Wayback Machine has no snapshot (I checked again on October 23), and the earliest public URLScan result Haugland found is from 10:08 PM PHT on September 12. So the page was live by then, but it may have appeared earlier.

It wasn't only the website. A member who wrote to Born's blog that day reported that peering through the exchange was disrupted, his VPN tunnels to it had stopped working and the member portal no longer let him log in. ETTAYEB reported the same: peering disrupted, some member tunnels down, the login portal unreachable. In ETTAYEB's words, this was a full compromise of the management side: website, mail, DNS and possibly the domain.

September 13: the domain walks away

Certificate transparency, the registry and Haugland's mail headers line up into one sequence. Thanks to Kat on my team for pulling the certificate and registry timeline together from crt.sh and RDAP.

• Sep 12, 12:03 PM PHT: a burst of Let's Encrypt certificates for four Frankfurt hosts. It is not clear whether the operators or the attacker requested them.
• Sep 13, 11:27 AM PHT: the first wildcard certificate for the domain (*.bgp.exchange). A Let's Encrypt wildcard requires a DNS challenge, so whoever requested it controlled the domain's DNS at that moment.
• Sep 13, 12:05 PM PHT: the registry logs an inter-registrar transfer, 38 minutes after that wildcard.
• Sep 13, 3:35 PM PHT: a Google Trust Services wildcard. That fits a move to Cloudflare, but that is our inference, not a record.
• Sep 13, 5:28 PM PHT: mail starts arriving from a new Microsoft 365 account on the domain, passing SPF, DKIM and DMARC as bgp.exchange (Haugland). Passing all three requires matching DNS records, so whoever sent that mail controlled the domain's DNS by then.
• Sep 18: the registry record changes again. It does not say what changed.
• Oct 1: a Sectigo wildcard is issued.

Today the domain sits at Tucows, is locked against transfers and updates, uses Cloudflare nameservers and has redacted registrant details. The previous registrar isn't public.

The Microsoft 365 messages kept coming. Haugland logged a message asking recipients to send cryptocurrency at 5:55 PM PHT and an "Urgent Support Needed to Keep BGP.Exchange Online" message at 7:02 PM PHT. These times fall after the operators' stated incident window ended.

At 8:23 PM PHT, a user identifying as part of the team confirmed on r/networking that the site had been hacked and that the domain had been "transferred away without our consent." A Discord statement attributed to the team, shared as a screenshot on Reddit, said the transfer happened through an API, that mail servers, Docker hosts and the web server were affected, and that route servers were not compromised. Haugland notes that the screenshot can't be independently authenticated.

When Haugland checked again at 9:54 PM PHT on September 13, both the root domain and www still served the defacement, and the looking glass redirected to it. He also noted that no incident explanation had been emailed to members.

The rebuild

The operators' own incident statement, printed in Born's German edition, says the attacker was able to "Gain unauthorised access to BGP.Exchange infrastructure, including hypervisor systems" and "Gain unauthorised access to the app.bgp.exchange management platform."

The operators later published their own timeline on a status page at bgpexchange.com. I couldn't independently confirm that site is operated by the team, so treat it as their claim. All times converted to PHT:

• Sep 14, 1:00 PM: affected systems narrowed to the application server, the database server, the email server and the Sydney hypervisor.
• Sep 14, 5:30 PM: domain recovery escalated with the registrar and registry; replacement Sydney infrastructure prepared.
• Sep 15, 12:00 AM: new Sydney hypervisor installed, then patched and hardened.
• Sep 15, 12:00 PM: new DNS, mail and Docker infrastructure deployed; application security review started; decision made to rebrand.
• Sep 17, 3:00 PM: core replacement infrastructure operational, with the application redesigned so admin functions are separated from member-facing services.
• Sep 28: rebrand to ixFabric underway, with PeeringDB, APNIC and RIPE records being updated.

In other words, the management side wasn't patched, it was replaced. The operators say they found no evidence that any route server, in any location, was accessed, and no evidence of access to hypervisors at their other points of presence. That is their claim; I have seen no public evidence either way. ETTAYEB also reported a measured operator statement on September 17 saying the same about the route servers.

What happened to the community channels

Email was abused through three sending paths: the SMTP2GO campaign platform, the project's own mail servers and the new Microsoft 365 account. The website, the member portal and the looking glass were down or defaced. That much is documented.

Discord was still working on Sep 12–13, according to a Born reader. I found no public record of when or whether the other channels went down. The operators' first statement came on Discord, and I found no public source showing that the Telegram group, the mailing list or any social accounts were taken over. A public Telegram group under the old name still lists several hundred members. Beyond Reddit, Born and ETTAYEB, I found one Mastodon post from someone who got the mail, and nothing on Hacker News, NANOG, LowEndTalk, GitHub or DN42.

Routing data

Kat on my team went through the public routing and registry data. Here is what it shows, with times in PHT.

• The ASN: the exchange runs AS24381, registered at APNIC as BGPE-AS with the description "BGP.Exchange." Its APNIC record was last modified on Sep 27, as part of the move to ixFabric (RIPEstat whois).
• PeeringDB: about 50 city exchange records were renamed to ixFabric in one batch early on Sep 28. The organization record now carries the notice "OUR DOMAIN HAS BEEN STOLEN, SEE BGPEXCHANGE.COM" (PeeringDB).
• Sep 12 to 13: public route collectors show none of the project's own routes withdrawn. Haugland's RIPE RIS snapshots show the same 13 prefixes visible to about 735 peers from Sep 11 to Sep 13. That is outside reachability only. Member tunnels and route-server sessions aren't visible to public collectors, so this data neither confirms nor refutes the operators' claim.
• Oct 3 to 17: smaller drops in visibility.

September 21: an unexplained routing event

Between 5:39 and 5:43 AM PHT on September 21, AS24381 sent about 1,700 announcements and 450 withdrawals, and several of its IPv6 blocks vanished from RIPE collectors until about 7:56 AM PHT on September 22 (RIPEstat, bgp.tools). The operators haven't explained it publicly, and I won't guess.

Where things stand

RIPEstat shows 11 prefixes from AS24381 today. The operators promised the new ixFabric site within 48 to 72 hours on September 28. Three weeks later, ixfabric.net still shows only "Coming Soon."

What we still don't know

• How the attacker first got in.
• Which API was used for the domain transfer, and at which registrar.
• When the defacement first appeared.
• What changed in the registry record on September 18.
• What caused the September 21 routing event.

What I take away from it

Whatever happened to the route servers, an exchange is more than its route servers. The portal, the mail, DNS and the domain are how members find you, trust you and get told what's going on. Lose those and the exchange goes down anyway, and anyone holding the old domain can keep speaking in your name.

If you were a member: treat anything from the old domain as untrusted, rotate any credentials you shared with the portal, review your sessions and tunnels, and only trust updates through channels the team has verified.

And for the rest of us running small networks: lock your domains, turn on registrar lock and 2FA, watch certificate transparency for your own names, and keep your management plane as far from your data plane as you can.