How Fuzzing Exposed Critical Vulnerabilities in RPKI Relying Party Software

TLDR: Researchers recently demonstrated that widely used RPKI relying party software is riddled with memory corruption and path traversal bugs, leaving 41.2% of the internet's routing infrastructure vulnerable. By building a custom fuzzer called CURE, they uncovered 18 distinct vulnerabilities, including critical flaws in Routinator. Pentesters and network engineers should audit their routing stack immediately, as these flaws allow attackers to crash critical infrastructure or potentially manipulate routing data.

Routing security is often treated as a theoretical exercise, but the reality is that the internet's backbone relies on fragile, complex software that rarely gets the scrutiny it deserves. Resource Public Key Infrastructure (RPKI) is the primary mechanism we use to prevent BGP hijacking, yet the software responsible for validating these cryptographic objects has been operating with significant, unpatched security debt. Recent research presented at Black Hat 2024 proves that the "glue" holding our routing security together is surprisingly easy to break.

The Fuzzing Challenge: Why RPKI is Hard to Test

RPKI relies on ASN.1 and X.509 certificate formats, which are notoriously difficult to parse correctly. Most developers building relying party software—the engines that download and validate these objects—have focused on performance and protocol compliance rather than adversarial robustness.

Standard fuzzers fail here because they lack the context to generate valid, cryptographically signed RPKI objects. If you just throw random bytes at a parser, it will reject the input at the first validation check, never reaching the deep logic where the most interesting memory corruption bugs hide. The researchers behind this work built CURE, a fuzzer specifically designed to understand the structure of RPKI objects. CURE doesn't just mutate bytes; it understands the schema, allowing it to generate malformed objects that pass initial validation but trigger edge-case logic errors, memory leaks, or crashes deep within the parsing stack.

From Path Traversal to Denial of Service

The most severe finding was a path traversal vulnerability in Routinator, tracked as CVE-2023-39916. This vulnerability is a classic example of why input validation is non-negotiable. By crafting a malicious RPKI object, an attacker could force the software to write files outside of its intended directory or manipulate internal data structures.

Beyond path traversal, the researchers found a consistent pattern of denial-of-service (DoS) vulnerabilities across multiple implementations, including OctoRPKI and Fort. The attack flow is straightforward:

1. The fuzzer generates an object that triggers an unhandled exception or an out-of-bounds memory access.
2. The relying party software crashes.
3. Because these services are designed to be "always on," they automatically restart.
4. The attacker feeds the same malicious object again, trapping the service in a perpetual crash-restart loop.

This effectively blinds the network operator. If the relying party cannot validate RPKI data, the router loses its source of truth for route origin validation. In a worst-case scenario, this forces the router to fall back to insecure BGP announcements, opening the door for the very hijacking attacks RPKI was meant to prevent.

Real-World Impact for Pentesters

If you are conducting a red team engagement or a network security assessment, RPKI infrastructure is a high-value target that is often overlooked. Most organizations assume their routing software is "secure by design" because it handles critical infrastructure. This is a dangerous assumption.

During an engagement, look for the presence of relying party software in the management network. If you find an instance of Routinator or rpki-client, you are looking at a potential entry point for a DoS attack that could disrupt the entire organization's external connectivity. The impact is not just a service outage; it is the degradation of the organization's ability to verify the authenticity of internet routes.

The Defensive Reality

Defending against these attacks requires a shift in how we manage routing infrastructure. First, treat your RPKI validator as a critical, internet-facing application. It needs the same patching cadence as your web servers or firewalls. Second, monitor your validator logs for unexpected crashes or "panic" messages. If your service is restarting frequently, you are likely being targeted or are processing malformed data that needs immediate investigation.

The OWASP guidance on Input Validation remains the gold standard here. Even if you aren't writing the validator yourself, you should be running these tools in an isolated environment and monitoring their resource consumption.

The research highlights a sobering truth: we have built a massive, global security layer on top of software that is still in its infancy regarding security maturity. We need more tools like CURE to stress-test these protocols before they become the single point of failure for the entire internet. If you are a researcher, look at the parsers. If you are a defender, patch your validators. The party is crashing, and it is time we started paying attention to the guest list.