Amidst news regarding the U.S. capture and arrest of Venezuelan leader Nicolás Maduro, a cybersecurity newsletter observed a routing leak in Venezuela on January 2, referencing Cloudflare Radar data.
An analysis of the data revealed eleven route leak events since early December, affecting multiple prefixes, with AS8048 identified as the source. While the exact cause on the day of the event remains unconfirmed, this recurring pattern suggests that CANTV (AS8048), a prominent Venezuelan Internet Service Provider (ISP), may have inadequate routing export and import policies. This implies that the observed BGP anomalies could stem from technical shortcomings by the ISP rather than malicious intent.
This post will briefly discuss Border Gateway Protocol (BGP) and BGP route leaks, then examine the observed anomaly and its potential causes.
Background: BGP route leaks
A BGP route leak can be understood as behavior similar to taking the wrong exit off a highway. While a destination may still be reached, the path could be slower and involve delays not present on a more direct route.
Route leaks are formally defined in RFC7908 as “the propagation of routing announcement(s) beyond their intended scope.” Intended scope is determined by pairwise business relationships between networks. These relationships, represented in BGP using Autonomous Systems (ASes), typically fall into two categories:
-
customer-provider: A customer pays a provider network for connectivity to the Internet for themselves and their downstream customers.
-
peer-peer: Two networks agree to exchange traffic with each other and their respective customers, without payment (settlement-free).
In a customer-provider relationship, the provider announces all routes to the customer. Conversely, the customer advertises only routes originating from their own network and their direct customers.
In a peer-peer relationship, each peer advertises to the other only its own routes and the routes of its downstream customers.
These advertisements facilitate traffic flow in expected ways: from customers upstream to provider networks, potentially across a single peering link, and then potentially back down to customers at the far end of the path from their providers.
A valid path adheres to the valley-free routing rule:
A route leak occurs when an AS violates valley-free routing by taking routes from a provider or peer and redistributing them to another provider or peer. For instance, a BGP path should ideally never traverse a “valley” where traffic goes up to a provider, then down to a customer, and then up to a provider again. RFC7908 defines various types of route leaks, with a simple example being the Type 1: Hairpin route leak between two provider networks by a customer.
In the figure above, AS64505 takes routes from one of its providers and redistributes them to its other provider. This is unexpected, as providers should not use their customer as an intermediate IP transit network. AS64505 would likely become overwhelmed with traffic, being a smaller network with fewer backbone and network links than its providers. This can quickly become very impactful.
Route leak by AS8048 (CANTV)
With an understanding of BGP route leaks, the hypothesis presented in the newsletter post can be examined. The post highlighted several route leak anomalies on Cloudflare Radar involving AS8048. On the Radar page for this leak, this information is displayed:
The leaker AS is identified as AS8048 — CANTV, Venezuela’s state-run telephone and Internet Service Provider. Routes were observed to be taken from one of its providers, AS6762 (Sparkle, an Italian telecom company), and then redistributed to AS52320 (V.tal GlobeNet, a Colombian network service provider). This clearly constitutes a route leak.
The newsletter suggested “BGP shenanigans” and posited that such a leak could be exploited for intelligence gathering by government entities.
While the exact cause of this route leak cannot be definitively stated, available data suggests a more mundane explanation. This is partly because BGP route leaks occur frequently and have always been a part of the Internet, most often for non-malicious reasons.
To gain further insight, the impacted prefixes and networks can be examined more closely. The prefixes involved in the leak were all originated by AS21980 (Dayco Telecom, a Venezuelan company):
The prefixes are also all members of the same 200.74.224.0/20 subnet, as noted by the newsletter author. More significantly, the relationship between the originating network AS21980 and the leaking network AS8048 is that AS8048 is a provider of AS21980.
The customer-provider relationship between AS8048 and AS21980 is visible in both Cloudflare Radar and bgp.tools AS relationship inference data. A confidence score for the AS relationship can also be obtained using the monocle tool from BGPKIT, as shown here:
➜ ~ monocle as2rel 8048 21980Explanation:- connected: % of 1813 peers that see this AS relationship- peer: % where the relationship is peer-to-peer- as1_upstream: % where ASN1 is the upstream (provider)- as2_upstream: % where ASN2 is the upstream (provider)Data source: https://data.bgpkit.com/as2rel/as2rel-latest.json.bz2╭──────┬───────┬───────────┬──────┬──────────────┬──────────────╮│ asn1 │ asn2 │ connected │ peer │ as1_upstream │ as2_upstream │├──────┼───────┼───────────┼──────┼──────────────┼──────────────┤│ 8048 │ 21980 │ 9.9% │ 0.6% │ 9.4% │ 0.0% │╰──────┴───────┴───────────┴──────┴──────────────┴──────────────╯
While only 9.9% of route collectors observe these two ASes as adjacent, nearly all paths containing them indicate AS8048 as an upstream provider for AS21980, suggesting high confidence in this provider-customer relationship.
Many of the leaked routes were also heavily prepended with AS8048, which would have made them potentially less attractive for routing when received by other networks. Prepending involves padding an AS multiple times in an outbound advertisement by a customer or peer, aiming to shift traffic away from a particular circuit to another. For example, many paths during the leak by AS8048 appeared as: “52320,8048,8048,8048,8048,8048,8048,8048,8048,8048,23520,1299,269832,21980”.
AS8048 is shown to have sent its AS multiple times in an advertisement to AS52320. Due to BGP loop prevention, the path would never actually traverse in and out of AS8048 multiple times consecutively. A non-prepended path would look like this: “52320,8048,23520,1299,269832,21980”.
If AS8048 was intentionally attempting to become a man-in-the-middle (MITM) for traffic, why would the BGP advertisement be made less attractive instead of more attractive? Furthermore, leaking prefixes to attempt MITM traffic when already a provider for the downstream AS would not be logical.
The leaks from AS8048 also surfaced in multiple separate announcements, each around an hour apart on January 2, 2026, between 15:30 and 17:45 UTC, suggesting potential network issues that manifested as a routing policy problem or a convergence-based mishap.
It is also noteworthy that these leak events began over twelve hours prior to the U.S. military strikes in Venezuela. Leaks impacting South American networks are common, and there is no reason to believe, based on timing or the other factors discussed, that the leak is related to the capture of Maduro several hours later.
In fact, looking back over the past two months, numerous similar leaks by AS8048 can be observed, indicating this is not a new BGP anomaly:
The history of Cloudflare Radar’s route leak alerting pipeline shows that AS8048 is no stranger to Type 1 hairpin route leaks. Since the beginning of December alone, there have been eleven route leak events where AS8048 is the leaker.
From this, a more innocent possible explanation for the route leak can be drawn: AS8048 may have configured overly loose export policies towards at least one of its providers, AS52320. Consequently, redistributed routes belonging to its customer were propagated even when direct customer BGP routes were missing. If its export policy toward AS52320 only matched on an IRR-generated prefix list and not a customer BGP community tag, for example, it would explain why an indirect path toward AS6762 was leaked back upstream by AS8048.
These types of policy errors are something RFC9234 and the Only-to-Customer (OTC) attribute would significantly help with, by more tightly coupling BGP to customer-provider and peer-peer roles, when supported by all routing vendors. The more technical details on RFC9234 will be saved for a follow-up blog post.
The difference between origin and path validation
The newsletter also highlighted as “notable” that Sparkle (AS6762) does not implement RPKI (Resource Public Key Infrastructure) Route Origin Validation (ROV). While AS6762 does appear to have an incomplete deployment of ROV and is flagged as “unsafe” on isbgpsafeyet.com because of it, origin validation would not have prevented this specific BGP anomaly in Venezuela.
It is important to categorize BGP anomalies into route misoriginations and path-based anomalies, as understanding the difference helps identify the appropriate solution. Route misoriginations, often referred to as BGP hijacks, are addressed by RPKI Route Origin Validation (ROV), which ensures the legitimate owner originates a prefix. In the BGP anomaly discussed here, the origin AS was correctly identified as AS21980, and only the path was anomalous. Therefore, ROV would not be effective in this scenario.
Given this, path-based validation is needed. This is what Autonomous System Provider Authorization (ASPA), an upcoming draft standard in the IETF, aims to provide. The concept is similar to RPKI Route Origin Authorizations (ROAs) and ROV: an ASPA object is created to define a list of authorized providers (upstreams) for an AS. This will then be used by various vantage points across the Internet to invalidate route leaks. For example, AS6762, a Tier-1 transit-free network, would use the special reserved “AS0” member in its ASPA signed object to declare that it has no upstream providers, only lateral peers and customers. Then, AS52320, the other provider of AS8048, would observe routes from its customer with “6762” in the path and reject them by performing an ASPA verification process.
ASPA is based on RPKI and is precisely what would help prevent route leaks similar to the one observed in Venezuela.
A safer BGP, built together
It is important to offer an alternative explanation for the BGP route leak by AS8048 in Venezuela that was observed on Cloudflare Radar. It is helpful to understand that route leaks are an expected side effect of BGP historically being based entirely on trust and carefully-executed business relationship-driven intent.
While route leaks could be done with malicious intent, the data suggests this event may have been an accident caused by a lack of routing export and import policies that would prevent it. To achieve a safer BGP and Internet, collaboration is needed to drive adoption of RPKI-based ASPA, for which RIPE recently released object creation, on the wide Internet. It will be a collaborative effort, just as RPKI has been for origin validation, but it will be worth it and prevent BGP incidents such as the one in Venezuela.
In addition to ASPA, simpler mechanisms such as Peerlock and Peerlock-lite can be implemented by operators, which sanity-checks received paths for obvious leaks. One especially promising initiative is the adoption of RFC9234, which should be used in addition to ASPA for preventing route leaks with the establishing of BGP roles and a new Only-To-Customer (OTC) attribute. If routing vendors have not been asked for an implementation of RFC9234 to be on their roadmap, it is encouraged to do so. This can help make a big difference.
Update: Sparkle (AS6762) finished RPKI ROV deployment and was marked safe on February 3, 2026.
