Using BGPHorizon to Investigate the June 2026 Telegram BGP Hijack

August 30, 2026

On 16 June 2026, a set of IP prefixes belonging to Telegram appeared in the global routing table with the wrong origin network. It was widely reported, users experienced disruption, and other routing monitors flagged it as well. It is also a clean example of the kind of incident you can take apart quickly in BGPHorizon.

None of the findings here are unique to BGPHorizon. This incident was visible on other platforms. What BGPHorizon adds is speed: you can go from a name to the exact prefixes, the detections, and the individual raw events in a couple of minutes.

Summary

On 16 June 2026, more than two dozen Telegram prefixes (IPv4 and IPv6) were announced by AS18101 (Reliance Communications), which is not an authorized origin for that space.
Telegram normally announces these prefixes from AS62041 (Telegram Messenger EUR), AS62014 (APAC), and AS44907 (Telegram Messenger).
The activity came in two waves: one around 07:1x UTC and a second around 16:1x UTC. The second wave used more-specific prefixes.
BGPHorizon automatically flagged the announcements as RPKI invalid origin (high confidence), MOAS conflict, new origin, and IRR invalid origin.
The routes reached the wider internet through the upstream AS15412 (FLAG Telecom) and were observed across multiple independent route collectors.

Everything below can be reproduced in BGPHorizon.

Background

Telegram publishes its address space from a small number of ASNs and, it has RPKI ROAs in place that authorize those ASNs to originate the prefixes. That single fact is what makes this incident easy to adjudicate: when a different ASN announces the same space, the announcement is provably RPKI-invalid.

Step 1: Find the prefixes

Start from the search bar at the top of BGPHorizon, set the date range to June 2026, and search telegram. The registry (RADB / IRR) results list Telegram's route objects and prefixes, which gives you a set of prefixes to pivot from.

Step 2: Open a prefix

Open one of Telegram's prefixes, 91.108.4.0/22, and set the window to June 2026:

https://bgphorizon.com/prefix/overview?prefix=91.108.4.0%2f22&start_date=2026-06-01&end_date=2026-06-30

Prefix overview

The overview page tells you three things immediately: the prefix is normally RPKI-valid and originated by AS62041, it carries a red detections badge, and the Activity over time panel shows a point on the timeline when another origin was announcing the prefix. There are also several detections in the time window.

Step 3: Read the detections

Open the Detections tab. For this prefix, on 16 June 2026 at 07:17:27 UTC, BGPHorizon recorded a cluster of detections, all pointing at the same origin, AS18101:

Detection	Severity	Confidence	What it means
`rpki_invalid_asn`	High	High	The origin AS is not authorized by Telegram's covering ROA
`moas_conflict`	High	Medium	The prefix was announced by more than one origin at once
`origin_mismatch_new`	High	Medium	A new origin appeared that we had never seen for this prefix
`irr_invalid_asn`	Medium	Medium	The origin is not registered in the prefix's IRR route object

Drill into any incident to see the raw BGP events behind it: the announcement carried origin AS18101, the expected origin was AS62041, and it was seen by 4 peer networks across 5 collectors in a roughly 25-second window.

https://bgphorizon.com/prefix/overview?prefix=91.108.4.0%2f22&start_date=2026-06-01&end_date=2026-06-30#detections

Detections

Step 4: Establish the scope

One prefix is a data point. To see the shape of the event, pivot to the other prefixes from the search results. The same pattern repeats across Telegram's space, and it happened in two distinct waves.

Wave 1 (around 07:08 to 07:21 UTC) covered the base prefixes:

Prefix	Family	Normal origin	First seen (UTC)
`95.161.64.0/20`	IPv4	AS62041	07:08:57
`91.108.4.0/22`	IPv4	AS62041	07:17:27
`91.108.8.0/22`	IPv4	AS62041	07:18:30
`91.108.56.0/22`	IPv4	AS62041	07:18:29
`149.154.160.0/22`	IPv4	AS62041	07:18:30
`2001:67c:4e8::/48`	IPv6	AS62041	07:21:32

Wave 2 (around 16:13 to 16:33 UTC) was more granular. It announced more-specific prefixes such as 91.108.4.0/23, 91.108.6.0/23, 91.108.16.0/22, 95.161.72.0/21, the 149.154.16x.0/24 blocks, and the IPv6 ranges 2001:b28:f23c::/48 and 2001:b28:f23d::/48. More-specifics matter because a longer prefix wins in the routing table regardless of RPKI or path length, so a more-specific hijack pulls traffic more effectively than a same-length one.

Step 5: Follow the propagation

The AS paths on the rogue announcements show how they reached the outside world. Every observed path traced back through the same upstream:

19151 15412 18101
6908 15412 18101
917 60068 15412 18101

The immediate upstream that accepted and re-advertised the announcements was AS15412 (FLAG Telecom).

Timeline (16 June 2026, UTC)

07:08 95.161.64.0/20 announced by AS18101
07:17 91.108.4.0/22
07:18 91.108.8.0/22, 91.108.56.0/22, and the 149.154.160.0/22 cluster
07:21 2001:67c:4e8::/48 (IPv6)
16:13 to 16:33 second wave: more-specific /23 and /24 prefixes, plus IPv6 2001:b28:f23c::/48 and /48

In the public route-collector data we read, these unauthorized announcements show up as brief bursts on 16 June. That is worth reading carefully: route collectors only record what their peers choose to export, so this is a partial view and a lower bound, not a measurement of how many users were affected or for how long. Reports of the disruption described a longer window than any single collector snapshot shows.

What BGPHorizon flagged, in total

Across the affected Telegram prefixes on 16 June, BGPHorizon raised, among others:

26 rpki_invalid_asn incidents (high severity, high confidence)
26 moas_conflict incidents (high severity)
26 origin_mismatch_new incidents (high severity)
24 irr_invalid_asn incidents (medium severity)

The RPKI-invalid detections are the strongest signal here. Because Telegram authorizes its space with ROAs, there is no ambiguity: AS18101 was not permitted to originate these prefixes.

Every Telegram prefix that AS18101 announced that day:

91.108.4.0/22
91.108.4.0/23
91.108.6.0/23
91.108.8.0/22
91.108.8.0/23
91.108.10.0/23
91.108.16.0/22
91.108.56.0/22
91.108.56.0/23
95.161.64.0/20
95.161.64.0/21
95.161.72.0/21
149.154.160.0/22
149.154.160.0/23
149.154.160.0/24
149.154.161.0/24
149.154.162.0/23
149.154.162.0/24
149.154.163.0/24
149.154.164.0/22
149.154.164.0/23
149.154.164.0/24
149.154.165.0/24
149.154.166.0/23
149.154.166.0/24
149.154.167.0/24
2001:67c:4e8::/48
2001:b28:f23c::/48
2001:b28:f23d::/48

Reproduce it yourself

Every link below opens directly in BGPHorizon with the June window pre-set:

91.108.4.0/22 (the clearest single example): overview and detections
2001:67c:4e8::/48 (IPv6): overview
149.154.164.0/22: overview
91.108.56.0/22: overview
91.108.56.0/23: overview

Takeaways for operators

RPKI ROV works, and it makes incidents unarguable. Because Telegram had ROAs, every rogue announcement was RPKI-invalid with high confidence. If you validate and drop RPKI-invalid routes at your borders, announcements like these never enter your table.
Watch the more-specifics. The second wave used longer prefixes. Any monitoring you run should treat a new, more-specific announcement of someone else's authorized space as high priority.
A collector view is a partial view. Public collectors capture only what their peers export, so the windows visible here are a floor, not a ceiling. What people actually experienced can be broader and longer than any single vantage point records. That is exactly why a raw, queryable history is useful: you can verify the record instead of relying on a headline.

None of this required special access or novel tooling. The incident was there in the public routing record for anyone to read. What changes with BGPHorizon is how fast you get from a question to an answer: set your window to any month, search a prefix or an ASN, and BGPHorizon brings the data to you in seconds.

Monitor your own networks

Use BGPHorizon for free to monitor your own ASNs and prefixes. Create a free account, add the networks you care about, and get alerted the moment an unauthorized origin, RPKI-invalid route, or MOAS conflict appears, exactly like the one above.