In early January 2026, unusual Internet routing behaviour was observed involving AS8048, operated by CANTV, Venezuela’s state-owned telecommunications provider. The anomalies were highlighted by Graham Helton, a red team engineer writing on his blog Low End Orbit, based on publicly available BGP data.
Soon after, Cloudflare published its own technical analysis of the same routing events, presenting another point of view. Cloudflare argued that the observed patterns were consistent with a BGP route leak, a type of incident that occurs regularly on the Internet and is most often caused by configuration or policy errors rather than deliberate interference.
This article does not analyse the specific incident further. Instead, it uses it as a brief reminder of a broader issue: BGP incidents are common, difficult to interpret, and still fundamentally hard to secure.
Why BGP anomalies are hard to interpret
BGP is the protocol that allows autonomous systems (ASes) to exchange routing information and decide how traffic flows across the global Internet. It was designed decades ago, at a time when the network was smaller, more cooperative, and largely based on mutual trust between operators.
That design assumption still shapes BGP today.
The protocol does not include native mechanisms to:
- cryptographically verify that an AS is authorised to originate a prefix, or
- validate that the advertised AS path reflects legitimate business or routing relationships.
As a result, when routing data shows unexpected paths, repeated AS prepending, or sudden changes in reachability, the protocol itself provides no way to determine intent. From BGP’s perspective, a benign misconfiguration and a malicious manipulation can look identical.
Route leaks: a routine failure with global impact
One of the most common BGP failure modes is the route leak.
A route leak occurs when an AS unintentionally announces routes beyond their intended scope. Typical examples include exporting routes learned from one upstream provider to another, or propagating internal or customer routes more widely than intended.
Route leaks do not require an attacker. A single configuration mistake, combined with permissive policies elsewhere in the routing ecosystem, is enough to affect traffic far beyond the originating network.
Their impact can include degraded performance, increased latency, packet loss, partial outages, or large-scale traffic shifts across regions. Because BGP is global and transitive, even small errors can propagate widely.
Why “bad” routes still propagate
Some routing anomalies draw attention because they appear counterproductive, such as excessive AS path prepending that makes a route less attractive rather than more.
This showcases a key limitation of BGP: the protocol does not evaluate whether a route is sensible. As long as an announcement is syntactically valid and passes local policy checks, it can be propagated.
BGP does not understand intent, quality, or expected topology. It only compares attributes. Without strong filtering and validation, degraded or unusual paths can still spread across the Internet.
The core security gaps in BGP
The security limitations of BGP are well understood and long-standing.
First, there is no native authentication. Traditional BGP allows any AS to announce reachability to almost any prefix. Trust is implicit, and validation is external.
Second, policy enforcement is decentralised. Prefix filtering, max-prefix limits, and strict export policies are effective when applied consistently, but deployment and maintenance vary widely between operators.
Third, security extensions are only partially adopted.
RPKI enables cryptographic verification of route origin, allowing networks to confirm whether the originating AS is authorised to announce a given prefix. This significantly reduces simple prefix hijacks. However, RPKI does not validate the full AS path and does not prevent route leaks where the origin itself is legitimate.
BGPsec extends this concept by cryptographically signing each hop in the AS path. While standardised, BGPsec has seen little to no real-world deployment due to operational complexity, performance overhead, and the requirement for universal participation along the path.
More recently, mechanisms such as ASPA (AS Provider Authorization) aim to detect certain classes of route leaks by validating provider–customer relationships using RPKI. ASPA is promising, but deployment is still emerging and far from universal.
Finally, detection remains largely reactive. Most operators rely on legacy monitoring systems, third-party alerts, or community coordination to identify routing incidents after they have already affected traffic.
What routing anomalies reveal about BGP security
Modern security discussions often focus on applications, APIs, and endpoints. Yet availability and integrity still depend on the network layer — and BGP remains central to that layer.
Routing incidents can disrupt services, interfere with DDoS mitigation paths, enable traffic interception, or amplify existing attacks, often without compromising a single server.
The uncomfortable reality is that BGP failures are not rare or exceptional events. They are a routine part of Internet operations, and they will continue to be until stronger security mechanisms are both widely deployed and consistently enforced.
The value of recent routing anomalies lies not in what they prove about intent, but in what they reveal about the Internet’s underlying trust model — and how fragile that model still is: BGP’s security challenges are not the result of negligence, but of historical design choices that no longer match today’s threat landscape.
At Internet scale, trust alone is not a security strategy — and BGP still depends on it more than any critical infrastructure should.
About FastNetMon
FastNetMon is a leading solution for network security, offering advanced DDoS detection and mitigation. With real-time analytics and rapid response capabilities, FastNetMon helps organisations protect their infrastructure from evolving cyber threats.For more information, visit https://fastnetmon.com.