Summary

  • A research team told APNIC 62 that a one-shot IPv4 scan on 2 February 2026 found 4,611 exposed BGP routers managed by 1,343 ASes in the APNIC region, including 347 routers classified as border routers.
  • “Exposed” has a specific meaning here: an arbitrary Internet source completed TCP setup on port 179 and received a BGP response during an unsolicited OPEN exchange. It does not mean the router was exploited or compromised.
  • The measurement is a dated inference, not a current registry census. It used one European vantage point, did not measure IPv6 and lacks Internet-scale ground truth for every router grouping and ASN attribution.
  • The useful next record is not a public target list. It is a confidential notice and operator disposition, followed by a comparable rescan and a privacy-safe aggregate closure receipt.

A reply beyond the port banner

An open TCP port can describe many things badly. The APNIC 62 presentation went one protocol step further. The researchers first found IPv4 addresses that responded on TCP port 179, then sent a standards-compliant BGP OPEN message and analysed the reply. Their working definition of an exposed router required a valid BGP response to an unsolicited exchange from an arbitrary Internet address.

That distinction matters. A response can reveal an ASN, BGP identifier and supported capabilities before a full session is established. It also makes the control plane allocate some processing and session state. RFC 7454 recommends discarding traffic to TCP port 179 when the source is not known or permitted to become a BGP neighbour, preferably with control-plane-specific filtering where the platform supports it.

But the distinction has a limit of its own. A response is not proof that an attacker found a software flaw, established a lasting BGP session, changed a route, disrupted traffic or harmed a customer. The paper describes information disclosure, exposure to implementation faults and resource exhaustion as possible risks. It does not report any such event in the APNIC sample.

The regional count is an inferred snapshot

The global Scan-179 result began with 141,313 IPv4 addresses that accepted TCP connections and exchanged OPEN messages. The researchers grouped those interfaces into 20,432 routers associated with 4,194 ASes. They classified 1,127 as border routers, 16,124 as internal routers and 3,181 as unclassified.

For APNIC 62, the deck supplied a regional cut: 4,611 routers managed by 1,343 ASes, of which 347 were classified as border routers. Its country chart counts ASes, not routers. Indonesia leads that chart with 387, followed by Bangladesh with 209 and Japan with 115. India has 92. These are observations within the authors’ mapping method, not a league table of negligent networks.

The grouping is clever rather than authoritative. It combines BGP identifiers, OPEN ASNs and interface-to-AS mapping. Private ASNs and shared addressing can complicate that join. A router with a public ASN whose observed interfaces map to the same AS can be internal or can be a border router using addresses supplied by its own network. The authors therefore leave thousands of routers unclassified instead of pretending the topology is visible.

They also removed a conspicuous false-positive class. Some 1,627 addresses copied the scanner’s ASN and BGP identifier. The team treated those as likely honeypots after checking that they exposed many ports and carried Shodan’s honeypot label. That improves the dataset; it does not produce ground truth for everything left in it.

February is not September

The scan ran once, on 2 February, from one European vantage point. The paper is IPv4-only and sees only devices that responded. Filters can vary by source, path, time, maintenance state and platform policy. A router counted in February may be closed now; a protected or unreachable router may never have appeared.

The September presentation is therefore new publication and regional framing, not a fresh September scan. APNIC did not perform the measurement and does not control the routers. Its useful role here is as the forum where a research result meets the operators able to explain or change the configuration.

That explanation remains thin. The paper says the team contacted 12 operators. One confirmed its IP-to-AS mapping and argued that default BGP protocol behaviour provided sufficient protection for port 179. The researchers note other possible explanations, including difficult vendor guidance and software limits. One answer cannot classify the remaining 1,342 regional ASes, and silence cannot be translated into fault.

The missing record begins after detection

A responsible workflow should keep the target evidence private. Each case can record the scan timestamp and vantage, probe version, TCP and BGP response class, the inference used to join an interface to a router and AS, and a confidence level. It should then identify the routing-security or abuse contact, delivery time and any correction to the attribution.

The operator’s disposition is the decisive field: intended and bounded exception; stale access list; filtering defect; unsupported platform; retired interface; false attribution; or another documented reason. Where change is required, the record needs an owner and due date. A repeat measurement should use comparable conditions, with a second vantage where source-based filtering is material.

The public output can stay aggregate: notices delivered, acknowledgements received, dispositions recorded, corrections accepted, exposures closed and cases awaiting rescan. No IP address or named AS needs to appear. The result would show whether a striking number became a repair programme without turning a research dataset into an attackers’ directory.

Sources