Ephemeral Leaks: Why Path Hunting Reads Like an Attack and Isn't
Picture the day someone on your security team has to decide whether a flagged route leak in Venezuela is an attack or nothing. A Cloudflare Radar alert is on the wall screen. The prefix got flagged within the hour of some military or political event in the news, and a colleague has already drawn a line between the two. The path looks wrong. An autonomous system that should never have touched the route sits in the middle of the AS-PATH. It has the shape of a hijack. The clock is running, and the wrong call in either direction costs you.
In May 2026, Doug Madory, Director of Internet Analysis at Kentik, took that exact alert apart on the APNIC blog and reached a deflating conclusion: most of these are nothing. He calls them ephemeral leaks, valley-free violations that exist for under a second during normal BGP convergence and disappear before they misdirect a single packet. The detector is doing its job. The interpretation fails. From the leasing desk I see the same pattern in most routing-security panic: the dangerous part is almost never the leak itself, it's the response it triggers.
Madory is right that "most flagged leaks are harmless convergence noise," and that is the simple conclusion to reach. The part operators tend to skip is the harder follow-on: you still cannot ignore the queue, because the same mechanism that produces harmless noise is the one a real path-error leak hides inside.
What an ephemeral leak actually is
A route leak, in the valley-free sense, is when an autonomous system takes a route learned from a provider or peer and re-announces it somewhere it shouldn't, to another provider or another peer. That creates an Up-Down-Up shape in the AS-PATH that contradicts the commercial relationships routing is supposed to respect. RPKI origin validation never catches it, because the origin ASN is legitimate; only the propagation is wrong.
The "ephemeral" qualifier is about duration, and it comes straight from how BGP recovers. When a route is withdrawn, routers don't fall silent and pick the next-best path instantly. They engage in path hunting: each speaker sequentially tries the backup paths it knows, advertising them as it goes, before settling or giving up. Madory's sharpest data point is that a single withdrawal triggers announcements that exceed the withdrawals themselves by an order of magnitude. During that storm, plenty of the transient paths a router floats are valley-free violations. They are real announcements. They are also gone in milliseconds.
Cloudflare Radar, like Jared Mauch's original detector before it, works message-by-message: one announcement containing a bad AS-PATH is one reported leak. That design is why the queue fills with ephemera. It is not a bug, it is the price of catching anything sub-second at all.
The case that makes it concrete
Madory pulled raw RouteViews data for event #497796 to show what a flagged leak looks like at the message level. Prefix 193.201.241.0/24 began a partial withdrawal around 13:08 UTC on 31 March 2026. In the middle of the path-hunting churn, AS48452 momentarily passed a route from AS8262 to AS3257, a clean valley-free violation. From the observing vantage point, neither leaked announcement stayed in circulation for a full second. A second example, event #498317 on 67.215.94.0/24, lasted a little over two seconds before the prefix finished withdrawing.
The Venezuela event everyone worried about, #462460, involved 200.74.226.0/24 with AS8048 prepended nine times in the path. Madory's finding is the quiet one: it wasn't even a new leak. It was a brief reappearance of a leak that already existed earlier in the hour, surfacing again at 15:40 UTC as the prefix recovered from a temporary withdrawal. There was a steady drumbeat of these going on across the global routing table the whole time. A momentary mishap coinciding with a news event isn't evidence of a connection, given how constant the drumbeat is, coincidence is the default expectation.
The detection lineage matters here, because it explains why the noise floor changed. Mauch's 2007 tool, born in the Chihuahuan Desert and still running nearly two decades on, listed transit-free ASNs and flagged any path carrying more than two of them. That aggregated, count-based logic mostly surfaced sustained problems. Andree Toonk adapted it for BGPstream, shown at Black Hat in 2015 and later discontinued after Cisco acquired OpenDNS. When Cloudflare moved to per-message AS-relationship classification in 2022, it expanded coverage to exactly the short-lived violations the older tools never bothered to report. The ephemeral leaks didn't appear in 2022; the ability to see them did.
Where I'd push back on the "just noise" reflex
This is where the reflex goes wrong. Once a team internalizes "ephemeral leaks are convergence artifacts," the next move is to mute the feed, and that is the wrong lesson. Madory cites a conversation from APRICOT 2018 in Kathmandu with Alexander Azimov, one of the architects behind ASPA and RFC 9234, who conceded the leaks are mostly transient but made the point that lands for me: each one marks a place in the policy mesh where a *real* leak could get through. The ephemeral leak and the catastrophic one travel the same gap. The transient version just happens to die during convergence before it does damage. Mute the channel and you also stop seeing where your safeguards are missing.
So the operator's job is to triage by duration and persistence, which is exactly what message-by-message detection, by design, can't do for you. Silencing the detector and chasing every spike are both ways of getting it wrong.
A study of real-time analytics on local BGP information reported 92% locating accuracy at sub-millisecond latency, which sounds like the answer until you notice the same measurement literature found BGP tables miss a large share of true AS adjacencies: in one study, up to 86.2%, mostly peer-to-peer links. You cannot reconstruct the full path-relationship graph from public data alone, so some violations will always be ambiguous from the outside. That limit is real, and it is why I treat any single-vantage leak report as a lead, not a verdict.
A triage table for routing leak alerts
The operational question is never "leak vs. no leak." The detector already told you it's a leak. What you are sorting is a self-correcting convergence artifact against a violation that persists. Set the two side by side on the few signals that separate them, and the call gets fast.
| Signal | Ephemeral artifact (stand down) | Persistent leak (investigate) |
|---|---|---|
| Duration at the vantage point | Sub-second to a few seconds | Minutes or longer, across snapshots |
| Timing relative to a withdrawal | Coincides with a known withdrawal or churn | Appears with the prefix otherwise stable |
| Repetition and origin | Flickers, then the legitimate path returns; origin ASN is correct | The violating origin holds the route across snapshots |
None of this requires a code change or a new appliance. It requires correlating the leak timestamp against the prefix's withdrawal and reachability history. That is exactly the stateful view Madory points to when he notes that finding the *disruptive* leaks means going beyond analysing messages in isolation and instead tracking how long a bad route actually persists and propagates.
Why detection isn't the fix, and what is
Madory is careful not to oversell detection, and on this I agree completely from the registry side. Knowing a leak happened does nothing to stop the next one. The structural fixes live at the protocol layer.
RPKI Route Origin Validation is the one most people reach for first, and for path-error leaks it is the wrong tool: it validates the origin ASN, not the path, so a properly originated route sent the wrong way passes ROV clean. As of July 2025, RPKI had reached roughly 56% IPv4 coverage. That is meaningful progress against misorigination and hijacks, and beside the point for the leaks in this article.
The mechanism that actually addresses wrong-way propagation is path-aware: ASPA and the BGP Roles of RFC 9234, where a router advertises its relationship (customer, provider, peer) at session establishment and can then reject announcements that violate it. Cloudflare Radar has started tracking ASPA adoption, and Madory reports it picking up steam. The supplementary OTC and Downstream-Only markers exist as a stopgap, but they can be stripped by an inattentive or hostile router, which is why the role-based capability is the more durable answer.
My one operational caution: deploying role enforcement against the wrong relationship data does more harm than the leaks it prevents. If you assert a peering relationship your registry records don't match, you will start rejecting legitimate announcements. The prerequisite is the work I spend most of my days on: making sure the route and relationship objects in the RIR databases reflect what the network actually does, before you ask routers to enforce them.
About
I'm Evgeny Sevastyanov, and I lead the customer-support team at InterLIR, a Berlin-based IPv4 marketplace, working remotely from Varna. My day job is the registry side of all this: creating and maintaining objects in the RIPE and APNIC databases for clients leasing and transferring IPv4 space, and flagging listings that don't hold up. I hold the RIPE Database Associate certification, and a Master's in International Commercial Law, so I arrived at routing through contracts and registration paperwork rather than through packet captures.
That background is why ephemeral leaks catch my attention. When a leak actually matters, what stops the next one is accurate registry data sitting under whatever validation you turn on, never just a faster detector. Clean route and relationship objects are the quiet condition that lets the path-aware machinery do its job, and keeping them clean is most of what I do.
Conclusion
Madory's case holds: the majority of route leaks flashing across Cloudflare Radar are ephemeral byproducts of convergence, and reading them as coordinated attacks wastes the one resource a routing team can't scale, which is attention. "Mostly harmless" still does not mean "ignore." The same path-hunting churn that throws off harmless violations is the cover under which a persistent, damaging leak travels.
Telling them apart means correlating each single-message alert with the prefix's actual history rather than reading it as a verdict on its own. Detection got good enough to show us the noise floor. The work now is duration-aware triage on the alerts, plus path-aware validation built on registry data you've actually verified. Read the full analysis on the APNIC blog.
If you want one thing to watch from here, watch ASPA and RFC 9234 Roles adoption on Cloudflare Radar against that roughly 56% RPKI coverage. The day the path-aware curve starts climbing toward the origin-validation curve is the day this whole class of alert stops being a judgment call. Until then, the signal worth tracking is how long each flagged leak actually persists, because that number, and not the news cycle around it, is what separates the noise from the one that matters.
Frequently Asked Questions
An ephemeral leak is a valley-free violation that appears for a very short time, often under a second, while routers explore backup paths during BGP convergence. The route is real but disappears before it misdirects traffic. Doug Madory argues that most leaks reported on Cloudflare Radar are exactly this kind of harmless convergence artifact rather than malicious activity.
No. The same path-hunting churn that produces harmless ephemeral leaks is where a genuine, persistent path-error leak can hide. Muting the feed means losing visibility into the policy gaps a real leak would exploit. The better move is to triage by duration and persistence rather than escalating every spike.
Check duration and persistence. An ephemeral leak lasts seconds, coincides with a known withdrawal or churn, flickers, and resolves as the legitimate path returns. A real leak persists across snapshots while the prefix is otherwise stable, with the violating origin holding the route. This needs correlating the alert against the prefix's withdrawal history, which message-by-message detection alone cannot do.
Not the path-error kind. RPKI Route Origin Validation checks the origin ASN, not the propagation path, so a route originated correctly but passed the wrong way validates clean. RPKI reached about 56% IPv4 coverage by July 2025 and helps against hijacks and misorigination, but path-aware mechanisms like ASPA and RFC 9234 BGP Roles are what address valley-free leaks.
Accurate relationship data. BGP Roles let a router reject announcements that violate the declared customer, provider, or peer relationship, but if you assert a relationship your registry objects do not match, you will start dropping legitimate routes. Verify that the route and relationship objects in the RIR databases reflect what your network actually does before enabling enforcement.
