Enforcing the Lead AS in BGP AS_PATH: Strategies for Route Origin Validation

Several recent route hijack attempts flagged by Spamhaus have drawn our focus. In many of these incidents, a malicious actor exploited autonomous system numbers (ASNs) that were not actively in use. In particular, these hijacks seem to involve the creation of fabricated AS_PATHs that funnel traffic through unintended routes.

By spoofing AS_PATHs, the attacker aims to divert traffic away from its intended destination while simultaneously obscuring their identity. In extreme cases, a hijacker could strip so much information from the network path that they could falsely appear to be the original source of a Border Gateway Protocol (BGP) prefix themselves. Such hijacked routes can be exploited to intercept traffic or for other malicious activities.

A straightforward fix exists for these scenarios: ensuring that a BGP peer always includes its own AS as the “First AS” in any route it advertises — and having the receiving network verify this. To gauge how widely this safeguard is actually applied, we ran targeted tests on several major networks and analyzed their BGP behaviors. Keep reading to find out what we discovered.

Examining route hijacks involving forged paths

The theory that an actor is fabricating fake AS_PATHs becomes more convincing when we examine the implausible relationships between ASes listed in the path. Take, for example, one of the hijacks reported by Spamhaus targeting a prefix owned by Orange S.A., the French telecommunications company. Using the monocle tool, we were able to quickly locate a BGP UPDATE message tied to the hijack:

➜  ~ monocle search --start-ts 2026-04-13T00:20:00Z --end-ts 2026-04-13T00:23:59Z --prefix 90.98.0.0/15 --collector rrc26 --json
{
  "aggr_asn": null,
  "aggr_ip": null,
  "as_path": "48237 1299 199524 270118 17072 41128",
  "atomic": false,
  "collector": "rrc26",
  "communities": null,
  "local_pref": 0,
  "med": 0,
  "next_hop": "185.1.8.3",
  "origin": "IGP",
  "peer_asn": 48237,
  "peer_ip": "185.1.8.3",
  "prefix": "90.98.0.0/15",
  "timestamp": 1776039612.0,
  "type": "ANNOUNCE"
}

We know that AS1299 (Arelion) is a Tier 1 network, which means every AS listed to the right in the path should represent an upstream (customer-to-provider) relationship reading left to right. This would mean AS17072 is a transit provider for AS41128, AS270118 provides transit for AS17072, and AS199524 provides transit for AS270118. But when we look more closely at these networks:

• AS41128 is an idle ASN registered to Orange France

• AS17072 is an ISP operating mainly out of Mexico

AS270118 is a Mexico-based hosting provider

• AS199524 is Gcore, a provider known for its broad global peering footprint

The sequence of ASes shown above would imply that an inactive Orange France ASN is purchasing transit from Mexican ISPs, which is then passed upstream to Gcore and eventually to Tier 1 providers — a highly improbable arrangement.

In another case, a reported hijack targeting prefixes 47.1.0.0/16 and 47.2.0.0/16 from origin AS36429 even listed Cloudflare’s main ASN, 13335, in the AS_PATH: “199524 270118 17072 13335 36429”. Examples of these BGP UPDATEs are visible through the MRT Explorer on Cloudflare Radar:

We can definitively state that Cloudflare (AS13335) has no adjacency with AS36429, which is currently unused and owned by Charter. This confirms the path was fabricated by the hijacker, which incorporated Cloudflare’s ASN as one of several fictitious upstream networks in route advertisements sent toward Gcore (AS199524). Furthermore, Spamhaus correctly noted that all the hijacked routes ultimately terminated at a single network connecting to Gcore’s peering in Chicago — traffic never actually passed through the Mexican ISPs or Cloudflare’s network in the data-forwarding path.

Based on this evidence, we can confidently conclude that these paths are forged up to the leftmost common AS, which in this instance is AS199524, since everything to its right is clearly implausible. Our assessment is that the hijacker is following a deliberate strategy consisting of these steps:

1. Launch BGP announcements for “parked” or unassigned prefixes

2. Completely fabricate the AS_PATH, deliberately omitting the attacker’s own local ASN

3. Propagate these routes to Gcore, AS199524

In these hijacks, it appears that Gcore (AS199524) does not perform the validation checks to ensure the First AS matches the expected customer’s ASN. (We’ll explore why this might be the case later in this article.) As a consequence, the forged path is accepted and the hijacked prefixes are distributed to upstream providers and peers.

Although Autonomous System Provider Authorization (ASPA) will help invalidate these forged paths, attackers could still circumvent it by using an origin AS that passes RPKI-ROV validation or a legitimate upstream AS listed in ASPA records. To effectively block these particular hijacks, we need to depend on a different protective mechanism already available in BGP: First AS checking and enforcement.

The importance of First AS checking

Moving traffic across the Internet is a bit like shipping a package. When the package is dispatched, a record is maintained of every carrier that handles it along the way. In BGP, this record is called the AS_PATH (Autonomous System Path), and it documents every network that route passes through.

The AS_PATH attribute in BGP serves path selection. This selection process determines which route to a given destination offers the best sequence of hops, where “best” is based on several variables. It also enables loop prevention, allowing networks to reject paths that have already passed through their own AS. Beyond simply logging the networks a BGP UPDATE — and therefore the resulting route — will pass through, the AS_PATH can also be evaluated by operator-defined routing policies to steer traffic around or intentionally through a particular AS — for instance, to route around BGP anomalies and prevent unintended consequences.

BGP was designed on a foundation of trust, and the AS_PATH can be fairly easily tampered with — whether for what might appear to be valid reasons, such as AS prepending to shift traffic distribution, or for malicious purposes such as trimming the path to artificially draw traffic toward oneself or to carry out origin-based attacks.

Let’s explore how these two types of malicious BGP manipulations are

carried out.

• AS64506 uses RPKI ROA (Route Origin Authorization) records to cryptographically sign routes and block route origin hijacking attempts.

• AS64506 also sets up an ASPA object that lists only AS64503 as an authorized provider.

• AS64505 tampers with the AS_PATH by removing its own ASN and pretending to originate from AS64506.

• AS64502 does not check the First AS rule.

The route looks RPKI-ROV valid and represents the shortest available path, so it effectively captures traffic meant for AS64506. AS64506 has taken all the right steps by publishing a valid ROA for its prefix advertisement and even configuring an ASPA object with its single provider AS64503.

Despite this, the attacker operating AS64505 can still divert traffic intended for AS64506. Even if AS64501 (the customer) and AS64502 (their provider) perform ASPA validation, they will not detect an invalid path because there is no valley in the path “64502 64506”. Essentially, AS64505 avoids including its own ASN in the AS_PATH, allowing it to impersonate AS64506 without any intermediate AS hop.

The proper way to stop this hijack using current tools is to enforce the First AS in the AS_PATH. Once this rule is applied, AS64502 would correctly reject the route from AS64505.

• AS64506 has two transit providers: AS64503 and AS64505.

• AS64505 charges its customer AS64506 based on traffic volume ratios.

• AS64505 removes itself from the path, and its peer AS64504 does not enforce the First AS rule.

The BGP path selection process now picks the route through AS64504 as the best path from AS64501. AS64506 pays both providers, AS64503 and AS64505, to carry traffic from the Internet. But now AS64505 offers a shorter BGP path from distant sources, which means AS64505 will handle all traffic destined for AS64506 and get paid for it, while AS64503 receives nothing.

These BGP weaknesses can be easily addressed by enforcing the First AS to match the peer AS in a received AS_PATH.

When an operator sets up a BGP neighbor, they must configure the remote AS of the network they are connecting to. If the First AS in the AS_PATH does not match this configured value, then the path has been tampered with. The First AS enforcement process is described in Section 6.3 of RFC 4271 very clearly as:

“If the UPDATE message is received from an external peer, the local

system MAY check whether the leftmost (with respect to the position

of octets in the protocol message) AS in the AS_PATH attribute is

equal to the autonomous system number of the peer that sent the

message. If the check determines this is not the case, the Error

Subcode MUST be set to Malformed AS_PATH.”

RFC 7606 later updates how error-handling should be implemented by vendors, recommending that routes with malformed AS_PATHs should be discarded using the treat-as-withdraw approach. This lets routers drop specific prefixes with malformed attributes without tearing down the entire BGP session.

The current ASPA draft explicitly highlights the importance of First AS enforcement, noting that ASPA cannot handle paths where enough AS_PATH information is missing due to malformed announcements. Enforcing First AS in AS_PATHs is essential for Internet routing security.

Rather than relying solely on theoretical failure scenarios and past public incidents involving First AS rule violations, we wanted to measure firsthand how widely these AS_PATH violations are accepted across the Internet. To accomplish this, we configured BGP announcements to neighbors where we deliberately broke the rule ourselves. Here is what we did:

1. Allocated two IP prefixes, one for IPv4 and one for IPv6, to announce to Tier 1 External BGP (EBGP) neighbors

2. Intentionally prepended the test prefix announcements to Tier 1 neighbors with a Cloudflare-owned, non-13335 ASN (AS402542) placed before 13335

For instance, we announced the prefixes to AS1299 from our standard BGP session in Geneva. Our local AS is AS13335, but we included AS402542 explicitly as the First AS in the AS_PATH.

[email protected]> show configuration policy-options policy-statement 4-TELIA-ACCEPT-EXPORT term ADV-FIRST-AS-PROBE-CR-1695522
from {
    community ANYCAST-ROUTE;
    prefix-list fl_first_as_prober;
    route-type internal;
}
then {
    origin igp;
    as-path-prepend 402542;
    next-hop self;
    accept;
}

[email protected]> show route advertising-protocol bgp  162.159.82.0/24 detail | grep "AS path: "
     AS path: 402542 [13335] I

With this setup, our expectation is that:

1. Networks that do enforce-first-as will silently discard the route via the RFC 7606 withdrawal method

2. Networks that do not enforce-first-as will accept the route and install it for forwarding toward our test

Both outcomes are visible in public BGP route views. Our original plan was to continuously announce prefixes to all peers in a way that deliberately breaks the First AS rule, providing a tool for everyone to see which ISPs validate the First AS and which do not. However, we discovered that some networks still haven’t adopted the guidance from RFC 7606 for handling malformed BGP AS_PATHs, and instead of applying a treat-as-withdraw approach, they reset BGP sessions. This meant we couldn’t safely run continuous announcements that violate the First AS rule without disrupting real traffic to Cloudflare, which is obviously not something we can do.

Instead, we focused on the networks whose policies have the greatest impact: Tier 1 networks. These form the backbone of the Internet and have the largest AS customer cones, meaning that hijacks or malformed paths originating from these peers carry the widest-reaching consequences. Let’s begin by looking at how an anycast prefix, 1.1.1.0/24, normally propagates across Tier 1 networks.

The propagation of 1.1.1.0/24 looks exactly as expected – every Tier 1 network that Cloudflare currently has a direct adjacency with can reach it directly.

Now, let’s compare that with our intentionally malformed announcement of the prefix 162.159.82.0/24:

^{Note: AS5511 (Orange S.A.) is not shown above due to its limited visibility in public route views, but it was included in our testing and measurements.}

This prefix propagates very differently from 1.1.1.0/24 – far fewer Tier 1 networks are accepting the announcement directly from Cloudflare (in this case from AS13335 with AS402542 prepended). Based on our test criteria described earlier, here are the results we observed.

Tier 1 networks that are enforcing the First AS rule (by dropping the invalid announcements):

• AS174 (Cogent)

• AS1299 (Arelion)

• AS3257 (GTT)

• AS3491 (PCCW)

• AS5511 (Orange S.A.)

• AS6453 (Tata)

• AS7018 (AT&T)

Tier 1 networks that are not enforcing the First AS rule (by accepting and installing the prefixes):

Through our testing, we uncovered a concerning reality: Half of the Tier 1 networks are vulnerable to hijacks that exploit the First AS rule.

While our measurement study focused only on Tier 1 networks, there’s no question that many non-Tier 1 networks also fail to enforce the First AS rule.

We observed that most of the Tier 1 networks failing the First AS violation test are running Juniper Networks routers, as identified by the peers’ MAC addresses.

This underscores how vendor default behavior determines how secure a network is “out of the box” against First AS violation-based attacks. Let’s review some of the major BGP implementations and their default settings to better understand who is protected by default and who isn’t.

The chart below outlines major routing and networking vendors and their BGP policies. Here, “Yes” means the BGP implementation enforces First AS by default, which is a positive sign. “No” means the implementation is vulnerable by default.

The absence of default enforcement from some vendors may be due to the one legitimate scenario where the First AS should not be enforced on External BGP (EBGP) sessions: Internet Exchange (IX) route servers.

A route server’s role is to transparently (without adding its own AS to the AS_PATH) distribute routes between peers on the exchange fabric. This eliminates the need for peers to set up new BGP sessions every time a new network joins – they can simply peer with the route server.

In practice, most production networks have far more sessions with neighbors who are not transparent IX route servers than those who are. It’s far more practical to configure “no enforce-first-as” on a small number of route-server sessions than to manually enable “enforce-first-as” on every single peer across your network.

While a “secure by default” approach is ideal for defending against First AS violations, it’s generally a difficult challenge to persuade vendors to alter long-standing defaults. Vendors would also need to implement a graceful transition method to avoid disrupting IX route server BGP sessions that depend on “no enforce-first-as” settings to receive routes successfully.

Attackers deliberately manipulate AS_PATHs to bypass BGP security mechanisms. Even RPKI-based ASPA path validation cannot defend against forged-origin hijacks where the path has been stripped down to only the origin AS, leaving nothing for ASPA to invalidate.

The good news is that we already have a mitigation for these scenarios: we can verify that the First AS matches the BGP peer’s AS and always enforce this check. Refer to the “Documentation” column in the table above for guidance. It should be safe to enforce First AS on any External BGP (EBGP) session except those connected to an IX route server neighbor.

If you are a network operator, please enable First AS enforcement on your routers today to protect your network and the broader Internet.

If your router vendor or chosen BGP implementation defaults to enforcing First AS, you’re already protected and should be rejecting any First AS violations.

By working together, we can make the Internet more resilient against these types of hijacks.