HomeIncident library
Incident library

INCIDENT REPLAY · 2026-06-16

Rcom (India) Telegram block leaks globally

After India ordered a nationwide Telegram block (16 to 22 June 2026), AS18101 began originating Telegram prefixes such as 91.108.4.0/22 at 07:17 UTC, and the routes escaped to the global table through its transit. When Telegram responded with more-specifics, AS18101 originated more-specifics too at 16:14 UTC. Kentik says only about 1.6 percent of BGP sources carried the bogus route because RPKI origin validation filtered it, but a small share of global Telegram traffic was pulled to India and dropped.

Mis-originationBGP leak / hijackCatalog confidence: medium

A reconstruction, not the operator's network. Hammerhead's authors rebuilt the change from the public record as a small network of their own. No configuration here is the operator's. What follows is what the tool reported on that reconstruction; it is not a claim that the tool would have prevented the outage.

What happened

Who: Reliance Communications / Rcom (AS18101); transit AS15412; victim Telegram (AS62041)

The summary at the top is paraphrased from the sources below. Hammerhead's catalog rates its confidence in this account medium.

Sources

What the public record says

  • After India ordered a nationwide Telegram block (16 to 22 June 2026), AS18101 began originating Telegram prefixes such as 91.108.4.0/22 at 07:17 UTC, and the routes escaped to the global table through its transit. When Telegram responded with more-specifics, AS18101 originated more-specifics too at 16:14 UTC. Kentik says only about 1.6 percent of BGP sources carried the bogus route because RPKI origin validation filtered it, but a small share of global Telegram traffic was pulled to India and dropped.
  • Who: Reliance Communications / Rcom (AS18101); transit AS15412; victim Telegram (AS62041)

What the reconstruction assumed

Decided by Hammerhead's authors to build a network that runs. None of it describes the operator's network.

Everything below is ours.

  • The family template (tools/replays/gen_family_misorigination.py): RCOM-1 (AS 18101), an upstream TRANSIT-1 (AS 15412) that prefers its customer's routes and filters nothing on that session, the victim, and a third party behind the upstream. RCOM-1 null-routes the space it originates, so traffic drawn to it is dropped.
  • Cisco IOS syntax. No operator here has published configuration, and which vendors they ran is not on the record.
  • The upstream's other sessions are filtered and limited, so that the audit's finding is about this session and not the template.
  • RCOM-1 exports with the ordinary customer policy, an AS-path filter that passes only what it originates (^$). A mis-originated prefix is locally originated, so it passes.
  • One Telegram block stands for the several.

What Hammerhead said

Each run below is pinned by Hammerhead's replay tests at commit 0ee9732: the verdict and the quoted text are checked against the tool's output, and a run that disagrees fails the test. Reason lines are copied verbatim; a pinned line can be part of a longer reason. Every preflight run uses --max-blast-radius 100, so a change is never counted as caught merely because it touched many devices of a small network.

every network in one snapshot

now: fail

On the reconstruction, hammerhead preflight on a before and an after snapshot returned fail, for the reasons below.

Reason text pinned (some reason contains each line)

  • RCOM-1 would start originating 91.108.4.0/22, which is inside 91.108.4.0/22 that it learns from AS 15412, originated by AS 62041
  • connected subnet(s) reachable before are not reachable after

First run, before the fixes this batch prompted

first: fail
  • reachability regression: 1 connected subnet(s) reachable before are not reachable after — 91.108.4.0/24 on TELEGRAM-1 (91.108.4.1) from RCOM-1, TRANSIT-1, X-1 [icmp echo, tcp/179 bgp, tcp/22 ssh, tcp/80 http, udp/53 dns]
  • external advertisements: RCOM-1 would start originating 91.108.4.0/22, which is inside 91.108.4.0/22 that it learns from AS 15412, originated by AS 62041. A more-specific of address space you receive from a peer is not yours to announce

Pinned in tests/gauntlet/replays-misorigination.yaml.

RCOM-1's own router, nothing declared: a new origination is reported, and only a caveat

now: pass

On the reconstruction, hammerhead preflight on a before and an after snapshot returned pass.

Caveats pinned (some caveat contains each line; a caveat never moves the verdict)

  • RCOM-1 would start announcing 1 prefix(es) to

First run, before the fixes this batch prompted

first: unknown

Pinned in tests/gauntlet/replays-misorigination.yaml.

RCOM-1's own router, with what the upstream sends declared

now: fail

On the reconstruction, hammerhead preflight on a before and an after snapshot with --boundary @rcom_2026/boundary.yaml returned fail, for the reasons below.

Reason text pinned (some reason contains each line)

  • RCOM-1 would start announcing 91.108.4.0/22 to
  • which is inside 91.108.4.0/22 that
  • (AS 15412) advertises to this network (declared by

First run, before the fixes this batch prompted

first: fail
  • external advertisements: RCOM-1 would start announcing 91.108.4.0/22 to 172.16.1.1 (AS 15412), which is inside 91.108.4.0/22 that 172.16.1.1 (AS 15412) advertises to this network (declared by noc@example.net). A more-specific of address space you receive from a peer is not yours to announce

Pinned in tests/gauntlet/replays-misorigination.yaml.

RCOM-1's own router, with the validator's ROAs

now: fail

On the reconstruction, hammerhead preflight on a before and an after snapshot with --roas @rcom_2026/roas.json returned fail, for the reasons below.

Reason text pinned (some reason contains each line)

  • RPKI: RCOM-1 would start originating 91.108.4.0/22 as AS 18101
  • authorises AS 62041

First run, before the fixes this batch prompted

first: not runnable

error: unexpected argument '--roas' found

Pinned in tests/gauntlet/replays-misorigination.yaml.

TRANSIT-1's own router, no change: the audit

now: fail (finding)

An audit of one snapshot, no change: hammerhead nqe-library --mode run, check nqe.bgp.ebgp_peer_unfiltered_and_unlimited. Pinned status: fail, a finding whose evidence contains the text below.

Evidence pinned (the evidence contains each line)

  • TRANSIT-1
  • 18101

First run, before the fixes this batch prompted

first: pass (no finding)

Pinned in tests/gauntlet/replays-misorigination.yaml.

every network in one snapshot (potential microloop)

now: fail

On the reconstruction, hammerhead preflight on a before and an after snapshot returned fail.

This run repeats another pinned run (same snapshots, flags and verdict) to record the potential microloops it finds. A caveat never moves the verdict.

Caveats pinned (some caveat contains each line; a caveat never moves the verdict)

  • RCOM-1 -> TRANSIT-1 -> RCOM-1, if TRANSIT-1 has its new next hop while RCOM-1 still has its old one

Pinned in tests/gauntlet/replays-transients.yaml.

What changed in Hammerhead because of it

From the “What was fixed” table in Hammerhead's replay notes, where each fix landed after a failing test. “Found by” is copied as written; a family name means the batch this incident belongs to.

ROA maximum length

Roa::covers_prefix refused to cover a more-specific beyond maxLength, so such a prefix came back NotFound instead of Invalid (RFC 6811).

Found by: Mis-origination family

--roas <FILE> origin-validates new originations

From the originator's own seat a block that escapes is one new prefix, and only a caveat. With a validator's export it is decidable: "the ROA for 104.244.42.0/24 authorises AS 13414".

Found by: Mis-origination family

An announcement that multiplies

The announcement to an external peer goes from a few prefixes to many in one change.

Found by: Mis-origination family, Level 3

Outbound policy runs before the local AS is prepended

The simulator prepended first, so an outbound filter-list with ^$ matched nothing the router originated.

Found by: Mis-origination family

Many foreign originations are one reason

A mass mis-origination of hundreds of prefixes was hundreds of reasons.

Found by: Mis-origination family

Limits

  • The configurations are a reconstruction. Where the record is silent, the assumptions above fill the gap; if one is wrong, the replay is wrong in that respect.
  • A verdict describes the reconstructed network's converged state. Timing, traffic load, and anything a device does that no configuration states, such as software reacting to a health check or a firmware bug, are outside it.
  • A pass is reported as a pass. A fail says a gate fired on the reconstruction, nothing more.
  • Why the catalog counts this outage as in scope: The blocking change originated prefixes the operator does not own and the export policy let them reach a transit session; simulating the change shows new foreign-prefix announcements leaving the AS.

Not fixed: A single-prefix hijack from the hijacker's own seat, with no ROA and nothing declared

One new origination is what a legitimate new prefix looks like. pass with the caveat naming it; --roas or --boundary decides it.

Recorded against: Mis-origination family (17 of 28)

Not fixed: A forged-origin hijack

Origin validation passes it by construction. ASPA is not modelled.

Recorded against: Mis-origination family

Imported from docs/replays/rcom-2026/FACTS.md and the replay manifests in the Hammerhead repository at commit 0ee9732.