A BGP route leak is a legitimate route announced beyond the scope it was meant for, usually by misconfiguration. A hijack is an attacker or faulty network claiming address space it does not own. Both can pull traffic through the wrong network, so the effects look alike even though the causes differ.
The definition
RFC 7908 defines a route leak as "the propagation of routing announcement(s) beyond their intended scope." More precisely, an AS announces a learned route to another AS in violation of the policies of the receiver, the sender, or an AS on the preceding path. The RFC notes that leaks can be malicious, but most come from accidental misconfiguration.
The RFC does not define a hijack. It frames a leak as a policy violation about how a route is propagated. In most leak types the route, path and prefix are generally intact.
The six types in RFC 7908
- Hairpin turn with full prefix. A multihomed AS passes a route from one upstream provider to another unchanged.
- Lateral ISP to ISP to ISP leak. A route from a non-transit peer is passed to another non-transit peer.
- Transit provider prefixes to a peer. Routes learned from a provider are leaked to a lateral peer.
- Peer prefixes to a transit provider. Routes learned from a peer are leaked up to the AS's own provider.
- Prefix re-origination. The offending AS strips the path and announces the prefix as its own. Traffic may still reach the true origin through it. This is the closest to a hijack, though the RFC still classifies it as a leak.
- Accidental leak of internal prefixes. Internal, often more specific, prefixes escape and the receiver fails to filter them.
How the consequences look
A leak can redirect traffic through an unintended path, which may allow eavesdropping or traffic analysis. It may or may not overload a network or create a black hole. From an application owner's seat, symptoms include sudden latency, packet loss to some regions, or users reaching your service through a surprising path.
What you can do as a service owner
You do not control other networks' routing, but you can limit the damage:
- Use TLS everywhere with correct certificate validation, so an on-path network cannot read or alter content. See BGP hijacking and software distribution.
- Publish route origin authorizations for your prefixes if you hold address space. Origin validation catches some of these cases, but not all. Read RPKI route origin validation and its limits.
- Monitor reachability from several networks, not only from your own.
- Verify downloads. Signed packages and checksums mean a rerouted download still cannot be silently swapped.
- Keep a contact path to your upstream provider's network operations team.
Where Safeguard fits
This topic sits below where Safeguard works. Safeguard helps with the application side: scanning dependencies for known vulnerabilities, including in the networking, TLS and HTTP libraries you pull in, and gating pull requests with policies. Start with the free scan at gold.safeguard.sh/scan.
Quick check
Is a route leak always an attack?
No. RFC 7908 says leaks can be malicious, but most arise from accidental misconfiguration.
Which leak type resembles a hijack?
Prefix re-origination, where the offender strips the path and announces the prefix as its own.
Sources
Last reviewed: 19 October 2026.
