Let me start with what the headlines said, then tell you what was actually happening underneath.
On June 16, 2026, the National Testing Agency put out a notice: the Ministry of Electronics and Information Technology (MeitY) had ordered a temporary block on Telegram across India, effective until June 22, ostensibly to prevent cheating during the NEET undergraduate medical entrance exam on June 21. Clean story. Patriotic-sounding reason. Government protecting exam integrity.
Except, network researchers were already screaming about something else entirely.
While the government was busy crafting press releases about exam security, Reliance Communications was busy hijacking Telegram’s IP space and leaking that hijack to the entire global internet.
These two things are almost certainly connected. And the connection tells you a lot more about India’s internet governance than any NEET press release ever will.
The “Exam Security” Block: Let’s Dispose of This Quickly
Before we get into the BGP mechanics, I want to spend thirty seconds on the stated justification, because it deserves exactly that much attention.
MeitY’s position is that blocking a messaging platform nationwide – the one used by millions of businesses, NGOs, political organizers, remote workers, and regular people – is a proportionate response to the possibility that some students might use it to share exam answers.
It isn’t. Not even close.
WhatsApp exists. Discord exists. Slack exists. Every SMS group chat in the country exists. If you block Telegram on exam day and leave every other messaging platform online, you haven’t solved cheating – you’ve just inconvenienced everyone who wasn’t cheating. You’ve also burned through the goodwill of every business owner running purchase orders through Telegram groups (there are a lot of them), every developer using Telegram bots in production pipelines (also a lot), and everyone who just wanted to talk to their friends without switching apps.
This isn’t a security measure. It’s a statement of control. “We can shut this down when we want.” The exam is the excuse.
Now let’s talk about what was actually happening at the network layer, because that’s where this gets genuinely alarming.
BGP: The Internet’s Routing Brain, and Why You Should Care
To understand what Reliance did, you need to understand how internet routing actually works – not the handwaving “packets travel across cables” version, but the protocol that actually decides which cables those packets travel across.
The internet is not a single network. It’s somewhere north of 100,000 separate autonomous systems (ASes) – each one a network with its own address space, run by a telco, an ISP, a university, a cloud provider, a CDN. Your home ISP is an AS. Jio is an AS. Telegram runs its own AS. Google runs several. Each AS has an autonomous system number (ASN), a globally unique identifier assigned by regional internet registries.
BGP (Border Gateway Protocol) is what these ASes use to talk to each other. Specifically, it’s how they announce “I own these IP address ranges, and I can route traffic to them.” Every router on the global internet uses BGP to build a constantly updating map of where every IP address block lives. When you type a Telegram server’s IP into a packet, your ISP’s router consults its BGP table to figure out the best path to get there.
The protocol is ancient. RFC 4271 was published in 2006, and BGP has been around in various forms since the late 1980s. It was designed for a cooperative internet where network operators trusted each other. It was not designed for adversarial environments. And it has one enormous, well-documented flaw: BGP announcements are not authenticated by default.
Any AS can announce any IP prefix. The protocol has no built-in way to verify that the announcing AS actually owns those addresses. This is how BGP hijacking works, and it has been a known attack vector for over two decades.
What Reliance Actually Did
Here’s the specific incident, as reconstructed from RPKI validator data and RIPEstat queries that multiple researchers independently cross-checked.
Telegram’s messaging infrastructure runs across several IP blocks. One of them is 91.108.56.0/22 – a /22 prefix, meaning it covers 1,024 IP addresses (from 91.108.56.0 to 91.108.59.255). This block is owned by Telegram Messenger Network and is announced by AS62041, Telegram’s own autonomous system number. It has a proper route object registered in the RIPE NCC database, and it is signed with RPKI.
RPKI (Resource Public Key Infrastructure) is the security layer that BGP desperately needed. It works by letting IP address owners cryptographically sign their route announcements. A “Route Origin Authorization” (ROA) is essentially Telegram saying, with a certificate backed by RIPE NCC’s root of trust: “Only AS62041 is authorized to originate announcements for 91.108.56.0/22.” Routers that validate RPKI can check any BGP announcement against this signature. If the originating ASN doesn’t match the ROA, the route is marked RPKI-invalid and should, in a properly configured network, be dropped.
During the Telegram block, AS18101 – Reliance Communications began announcing 91.108.56.0/22 as its own. Same prefix, different origin AS. From a BGP perspective, the internet now had two competing claims: Telegram saying “send this traffic to us,” and Reliance saying “no, send it to us.”
When you validate AS18101’s announcement against Telegram’s RPKI records, the result is invalid_asn. There is no Route Origin Authorization that permits Reliance to originate this prefix. There is no route object registered for 91.108.56.0/22 in Reliance’s name anywhere in the RIPE database. Zero. Nothing. The announcement is completely unauthorized, and the RPKI infrastructure correctly flags it as such.
Now here’s the part that takes this from “regional telecom doing sketchy blocking” to “active international routing incident”:
Reliance passed this announcement upstream to FLAG Telecom (AS15412) – its international transit provider. FLAG accepted the RPKI-invalid route without filtering it. And then FLAG propagated it to its international peers.
How the Hijack Leaked Globally
FLAG Telecom has a history that matters here. It was formerly owned by Reliance Communications. The relationship between AS18101 and AS15412 is not a normal commercial peering arrangement between strangers. FLAG was RCom’s international backbone. Even after ownership changed, the transit relationship and the associated trust configurations apparently stayed in place. This is almost certainly why FLAG didn’t filter the invalid announcement: legacy trust, legacy configurations, and possibly nobody at FLAG paying close enough attention to their route filtering policies.
Once FLAG accepted and propagated the route, it spread to FLAG’s international peers: CDN77 (AS60068), Misaka (AS917), euNetworks (AS13237), Taiwan Digital Streaming (AS18041), and others. These networks received what looked, from a pure BGP perspective, like a legitimate route to 91.108.56.0/22 – it came from an established transit provider with good connectivity, and BGP’s path selection algorithm has no concept of “wait, is this authorized?”
The scale of propagation is what clinches this as a global incident rather than a regional one. Researchers cross-checking RIPEstat data found that all 328 out of 328 RIS (Routing Information Service) peers were seeing both origin ASes for 91.108.56.0/22 – AS62041 (Telegram) and AS18101 (Reliance). That’s not a partial propagation or a regional routing table anomaly. That’s a full global hijack. Every BGP router on the internet that checks its table was seeing the contested announcement.
Traffic that ended up routing to AS18101 instead of AS62041 went into a blackhole. There’s nothing at Reliance’s edge that knows what to do with Telegram traffic (they’re not running Telegram’s servers). Packets arrive, find no matching forwarding rule, and get dropped. This is why users in the UAE – completely outside India, completely unaffected by India’s Section 69A blocking order were finding Telegram unreachable. Their traffic was being misdirected to a Reliance blackhole by a routing announcement that had no business being in the global BGP table in the first place.
The RPKI Mechanism: Why This Should Have Been Caught
Let’s go deeper on RPKI because it’s the key technical thread here, and it illustrates both how the security infrastructure is supposed to work and where the operational failures happened.
RPKI is built on a five-tier hierarchy of trust. At the top, the five Regional Internet Registries (ARIN, RIPE NCC, APNIC, ARIN, LACNIC, AFRINIC) act as trust anchors. Each RIR manages the cryptographic root of trust for IP addresses allocated in its region. Below the RIRs, address holders (ISPs, large enterprises, CDNs) receive certificates that attest to their address holdings. From those certificates, they can create Route Origin Authorizations.
A ROA contains three fields that matter: the IP prefix, the maximum prefix length, and the origin ASN. Telegram’s ROA for 91.108.56.0/22 specifies that announcements for this prefix (and any more-specific prefixes up to a certain length) must originate from AS62041. When a router with RPKI validation enabled receives a BGP announcement and the origin ASN doesn’t match like AS18101 announcing a prefix that Telegram owns, it marks the route as RPKI-invalid.
The problem is that “marked as invalid” doesn’t mean “automatically dropped.” RPKI validation is a policy tool, not a hard enforcement mechanism. Each network operator configures its own policy for what to do with RPKI-invalid routes. Best practice and the official IETF recommendation is to drop them entirely. But plenty of networks configure their routers to accept RPKI-invalid routes anyway, either because they haven’t updated their configurations, or because they made a deliberate business decision to prioritize route availability over security, or because nobody thought about it.
FLAG Telecom accepted and propagated an RPKI-invalid announcement from RCom. That’s the operational failure. Their route filtering should have caught this. It didn’t.
If every network on the internet ran strict RPKI validation, what’s called “RPKI-based route origin validation with invalid drop”, this hijack would have been contained to networks that chose to accept RCom’s announcement deliberately. The global propagation only worked because a significant portion of the internet’s networks still don’t enforce RPKI validation for invalid routes. We’ve known this is a problem for years. The NIST has guidelines on it. MANRS (Mutually Agreed Norms for Routing Security) has been pushing for better filtering practices since 2014. The internet is getting better on this slowly but incidents like this one show exactly what the gap costs.
Was This an Accident?
The “misconfigured local block gone global” theory goes like this: Reliance was trying to comply with India’s Section 69A blocking order for Telegram. To implement the block domestically, they configured a null route for Telegram’s IP prefixes – traffic from Indian users heading to 91.108.56.0/22 gets redirected to a dead end. Normal ISP blocking procedure.
But somewhere in that configuration, instead of just inserting a null route in their internal routing tables, they accidentally originated a BGP announcement for the prefix – telling the world, via FLAG, that they were the legitimate destination for Telegram’s traffic. The internal block leaked into the global routing table.
This is technically plausible. BGP misconfigurations do happen. The internet has seen accidental route leaks before. Pakistan Telecom knocked YouTube offline globally in 2008 with exactly this kind of mistake. Human error in complex network configurations is real.
But there are a few things that make pure-accident harder to swallow here.
First, the announcement persisted. Multiple researchers spotted it, documented it, and publicly reported it. Network operators contacted FLAG Telecom. The incident was visible in public routing data. Yet it stayed live for an extended period. Accidents get cleaned up faster when there’s external pressure and the error is obvious.
Second, the timing. The government ban announcement, followed immediately by a technically sophisticated routing manipulation that happened to push users toward a blackhole rather than a redirect, followed by slow remediation – this sequence is either a spectacular coincidence or it isn’t.
Third, the competitive context. Reliance Jio and RCom share common ownership threads with Mukesh Ambani’s broader business empire, which has a strategic partnership with Meta – the company behind WhatsApp, Telegram’s primary competitor in India. Telegram’s growth in India has been directly at WhatsApp’s expense. A platform disruption that makes Telegram unreliable while WhatsApp continues working normally is commercially convenient for a Meta-aligned entity.
None of this proves intent. But “we accidentally configured a global BGP hijack of our primary competitor’s IP space and then didn’t fix it quickly when people noticed” is a story that requires you to accept a lot of charitable coincidences stacking up simultaneously.
The Resolution Path (and Why It’s Complicated)
Technical remediation for this incident has a clear playbook, even if the execution is slow.
FLAG Telecom needs to configure route filtering that drops RPKI-invalid announcements from AS18101. This is an operational change on FLAG’s routers. It’s not technically complex – it’s a routing policy update. The challenge is organizational: somebody at FLAG has to make the decision and push the change.
Peer networks that received the announcement from FLAG can independently filter AS18101’s announcements for prefixes they have no legitimate claim to. This requires each network to either run their own RPKI validation or to receive filtering recommendations from organizations like MANRS or their own NOC community channels.
Telegram has one additional technical option: deaggregation. Their /22 prefix (91.108.56.0/22) could be split into two /23 prefixes (91.108.56.0/23 and 91.108.58.0/23). BGP prefers more-specific routes. If Telegram announces two /23s that are more specific than Reliance’s /22, most BGP implementations will prefer Telegram’s announcements, effectively reclaiming the traffic. This is a well-known countermeasure against prefix hijacking and doesn’t require cooperation from anyone else. Whether it fully works depends on whether Reliance is also announcing the more-specific prefixes, but it’s the fastest unilateral option Telegram has.
Long term, the incident is an argument for accelerating RPKI ROV (Route Origin Validation) deployment globally. Networks that drop RPKI-invalid routes would have been immune to this leak. The internet infrastructure community has the tools to prevent this class of attack. What’s missing is universal adoption.
The Bigger Picture: What This Actually Tells Us
Step back from the technical details for a moment and look at the shape of what happened.
A government issued a platform block under Section 69A – India’s content-blocking provision – using exam integrity as justification. At roughly the same time, a major Indian telecom with financial ties to a competing platform executed a BGP operation that disrupted Telegram’s connectivity not just in India but internationally. The stated reason for the block (NEET exam security) is demonstrably disproportionate since every other messaging platform remained online. The technical disruption extended far beyond India’s jurisdiction, affecting users in countries that India has no authority over.
If the BGP manipulation was intentional and I want to be clear that this remains unproven, it represents state-adjacent infrastructure abuse at a scale we don’t usually see from democratic governments. This isn’t China’s Great Firewall, which at least operates within China’s borders. This is routing manipulation that reached the UAE, Taiwan, and Europe.
If it was accidental, then it reveals that a major Indian telecom implementing a government blocking order has BGP practices sloppy enough to accidentally disrupt global internet routing and either didn’t know or didn’t care enough to fix it quickly.
Neither explanation is good. One is more alarming than the other.
The pattern that’s worth watching: if you want to force a platform into a commercial arrangement – data sharing agreements, routing through domestic infrastructure, local content moderation compliance – you first make the platform legally precarious in your jurisdiction. Then you make it technically unreliable. The platform has a choice: fight the block in courts for years, or come to the table. Telegram has navigated this in multiple countries. The question is whether India’s approach here was a clumsy accident or a negotiating tactic dressed up as network administration.
What You Can Do
If you’re a network operator, the immediate action is straightforward: configure your routers to drop RPKI-invalid route announcements. If you’re already doing ROV, verify your policies are set to “invalid = reject” rather than “invalid = warn.” Check whether you’re peering with AS15412 (FLAG) and whether your filters would have caught this.
If you’re a Telegram user in India, a VPN was and remains the practical workaround. WireGuard-based VPNs such as Mullvad, ProtonVPN encrypt your traffic before it hits your ISP’s routing table, making prefix-level blocking ineffective.
If you’re a journalist covering this, the story isn’t the NEET ban. The story is which entity – RCom, Jio, or some intermediary configured the BGP announcement, why FLAG didn’t filter it, and who made the decision to leave it live after it was flagged.
Final Thought
The internet’s routing layer is largely invisible to regular users, and that invisibility is part of the problem. When a government blocks a website, there’s at least a press release. When a telecom hijacks an IP prefix and leaks it globally, it shows up in BGP routing tables that almost nobody outside network operations looks at. The harm is real – Telegram users in Dubai lost access but the mechanism is opaque enough that most people never connect the dots.
That’s what makes this incident worth paying attention to. Not just the specific organizations involved, not just the Indian government’s exam-security pretext, but the broader demonstration that internet routing infrastructure can be weaponized quietly, plausibly accidentally, with global reach, and with very slow accountability.
The tools to fix this exist. RPKI ROV deployment is the direct answer. What this incident illustrates, again, is what happens when those tools aren’t universally adopted and when the networks running global transit infrastructure don’t enforce the security policies they theoretically support.
We’ve known BGP hijacking is a problem since before some of the engineers who should be fixing it were born. Incidents like this are the cost of not fixing it.
This post first appeared at - The CyberSec Guru