Poster: From Fort to Foe: The Threat of RCE in RPKI

Haya Schulmann; Michael Waidner; Niklas Vogel; Oliver Jacobsen

REVIEW 4 major objections 5 minor 2 references

Poster: From Fort to Foe: The Threat of RCE in RPKI

T0 review · 4 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A buffer overflow in the RPKI validator Fort can let an attacker publish a malicious certificate that executes code on any machine running the validator.

desk verdict Real CVE-backed buffer overflow in Fort, but the RCE framing overreaches the demonstrated, protection-disabled PoC and version-only scan. read the letter →

arxiv 2411.16518 v1 pith:X7TUH4LW submitted 2024-11-25 cs.CR

Oliver Jacobsen , Haya Schulmann , Niklas Vogel , Michael Waidner This is my paper · ORCID

classification cs.CR

keywords RPKIremotecodeexecutionbufferoverflowFortvalidatorBGPkey-usageextensionCVE-2024-45237backdoor

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper establishes that Fort, a widely used RPKI validator, contains an unchecked buffer overflow in its handling of the X.509 key-usage extension, and that an attacker who controls an RPKI publication point can turn that overflow into remote code execution on every Fort instance that downloads the malicious object. Because relying parties fetch from all public RPKI repositories, a small attacker with a registered resource can expose the exploit to the entire population of Fort validators at once. A compromised validator can then feed fabricated route-authorization data to BGP routers without forging signatures, allowing prefix hijacks or the invalidation of legitimate routes, and can be used as a stepping stone into the local network hosting the routers. The paper reports that the vulnerable code entered the repository in January 2019, that it affects all Fort versions from Beta-2 to 1.6.2, that over 100 observed live systems run affected versions, and that the issue is CVE-2024-45237 with a 9.8 severity rating. It also argues that the dead-code placement of the vulnerable function has hallmarks of a possibly intentional backdoor, while leaving open that it may be a copy-paste mistake.

What carries the argument

The load-bearing mechanism is the unchecked `memcpy` in `handle_ku`, which copies the bytes of an ASN.1 BIT STRING (a length-prefixed byte array used in X.509 certificates) into a two-byte stack buffer according to the string's length, with no upper-bound check. That single operation converts a malformed certificate into a stack write primitive. Exploitation is gated by the compiler toolchain: `_FORTIFY_SOURCE` replaces `memcpy` with a bounds-checking variant, built-in inlining can optimize the copy away entirely, and `-fstack-protector-strong` adds a canary to functions with local arrays; the paper says none of these is explicitly set in Fort's build, so default toolchain behavior decides whether the overflow reaches a compiled binary.

What would settle it

Compile Fort 1.6.2 with a mainstream distribution's default hardening flags (for example `_FORTIFY_SOURCE=2` and `-fstack-protector-strong`), point it at a local RPKI repository containing a certificate whose key-usage bitstring is longer than two bytes, and observe whether the process exits via the fortify or stack-canary check before control flow is hijacked. If it exits before overflow, the specific RCE does not apply to default hardened builds; if it opens a shell or otherwise redirects execution, the central claim is confirmed.

Watch

Extended reading notes

Core claim

The central discovery is a stack buffer overflow in Fort's `handle_ku` function. The function copies an ASN.1 BIT STRING from a certificate's key-usage extension into a two-byte local array with `memcpy(data, ku->data, ku->length)` and never checks that `ku->length` is at most two. A certificate whose key-usage bitstring is longer than two bytes therefore writes attacker-controlled bytes into adjacent stack memory. The paper shows that an attacker can meet the surrounding validation checks, publish such a certificate in a live RPKI repository, and overwrite the return address with a 13-byte payload that opens a shell. It argues that all Fort versions from Beta-2 through 1.6.2 are affected, that the bug came in with a January 2019 commit, and that the observed live population includes over 100 systems running vulnerable versions. The paper's proof of concept disables compiler protections, and it states that bypassing ASLR and other mitigations is possible with additional effort.

Load-bearing premise

The chain from bug to remote code execution depends on the target Fort being compiled with a toolchain that does not activate fortification, stack-protector, or built-in memcpy elimination; the paper's only execution demonstration disables those protections, and its internet measurement records versions rather than compiler flags.

Editorial extensions

If this is right

If the exploit is valid, any Fort validator that fetches objects from an attacker's RPKI publication point can be remotely compromised, and validators fetch from all publication points by design.
A compromised validator can report arbitrary route-authorization data to BGP routers without producing any cryptographic signature, so prefix hijacks can be made to look valid and legitimate prefixes can be made to look invalid.
Because the RP machine must have network access to routers, the same foothold becomes a launching point for attacks on border routers and other hosts on the internal network.
Fort deployments that cannot be patched immediately need compensating controls such as compiler hardening, not storing router credentials on the RP host, network segmentation, and monitoring for unexpected outbound connections.
The vulnerability's presence across all affected versions means the attack surface is not limited to outdated installations; current-at-the-time Fort 1.6.2 is vulnerable as well.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If the version-based measurement undercounts exploitable deployments, the real impact could be larger than the 100+ observed systems, since the internet measurement records versions, not the compiler flags that determine whether the overflow is actually exploitable.
The same pattern of trusting an ASN.1 BIT STRING length without a bounds check may occur in other RPKI validators or forks; a targeted audit of key-usage parsing in those codebases is a natural next test of how general the flaw is.
The dead, unreachable code with a controllable overflow is precisely the signature that tooling could flag: future static analysis could warn on `memcpy` whose source length is parsed from network data and whose destination is a fixed-size stack array and on functions whose output is never used.
If the backdoor hypothesis is ever confirmed or rejected, it would change how RPKI trust should be structured; the paper's evidence stops short of certainty, so the operational takeaway should be to treat RP software as boundary-trust software regardless of origin.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Short version: this is a real bug with an assigned CVE, and the authors found actual internet-facing Fort instances running affected versions. The part that doesn't fully hold up is the headline RCE claim, which depends on a compiler configuration the authors do not show exists on any of the measured systems.

What's new: first public analysis of an RCE-capable bug in an RPKI relying-party client, CVE-2024-45237. The vulnerable memcpy in Listing 1 is concrete, and the local reproduction with a manipulated key-usage bitstring is consistent with the source. They found the buggy code was introduced in January 2019, affecting all versions through 1.6.2. The live publication-point scan reporting over 100 vulnerable clients, including Amazon and RIRs, is a useful datapoint. The backdoor speculation is appropriately hedged and not load-bearing.

The central weakness is the gap between the source-level overflow and the claimed large-scale RCE. The only demonstrated RCE runs with _FORTIFY_SOURCE undefined, -fno-builtin-memcpy, and no stack protector. In their own default-configuration experiment, the stack protector catches the overflow and Fort crashes—that's DoS, not RCE. The paper acknowledges the compiler dependence in Section 2, but the abstract and intro state the vulnerability "allows" RCE without that qualification. The live scan counts version strings, not compiled binaries, so we don't know how many of the 100+ systems are actually exploitable. The speculation about bypassing ASLR via partial overwrite or brute force is plausible but not demonstrated. Also, the paper ships no exploit code, measurement data, or patch details; some of that is poster-page constraints, but the version-only measurement should be labeled as such.

Overall: the bug is real, the CVE is real, and the RPKI impact discussion is sensible. The paper's own evidence supports a confirmed memory-corruption vulnerability with conditional RCE and likely DoS in default builds. That is still a solid security finding for a poster. But the universal RCE language should be toned down.

Recommendation: send it to peer review. It deserves referee time because of the external corroboration and the importance of RPKI infrastructure. The revision should separate confirmed bug from demonstrated exploit, state the compiler configuration assumptions clearly, and either provide the scan data or explicitly present the limitation.

Referee Report

4 major / 5 minor

Summary. The paper reports a buffer-overflow vulnerability in the key-usage handling of the RPKI validator Fort, identified as CVE-2024-45237. It claims that the overflow is remotely triggerable through RPKI publication points and can be escalated to remote code execution on machines running Fort, with severe consequences for RPKI validation integrity, the host, and the local network. The paper also speculates that the vulnerability might constitute an intentional backdoor. The evaluation consists of a local reproduction in which a default-configured Fort crashes under the stack protector, a proof-of-concept RCE in a configuration with compiler protections disabled, and a live measurement that finds over 100 systems running a vulnerable Fort version.

Significance. The paper identifies a real, externally corroborated source-level buffer overflow in Fort, anchored to a concrete code excerpt and a local reproduction, and it provides an ethical live measurement of the Fort population. The CVE assignment and the explicit code-level analysis are strengths, and the paper makes no use of fitted parameters or circular self-justification. If the RCE claim could be substantiated for default or common deployments, the impact would be substantial because relying parties are central trust points for BGP routers. However, the current evidence establishes a source-level overflow and conditional RCE; the large-scale, unconditional RCE impact stated in the abstract and introduction is not yet demonstrated.

major comments (4)

[§2 Escalation; §3 Evaluation] The paper's headline claim that 'an attacker can achieve RCE on the machine running the software' (Abstract) and that the attack 'impacts all globally running RPs of Fort' (Section 1) is not supported by the evidence. The only demonstrated code execution is in a local setup 'without enabling compiler protections' (Section 2, Escalation). In the Section 3 local-repository experiment under a default compiler configuration, the same overflow is caught by the stack protector and Fort crashes, which is a denial of service, not RCE. The live measurement identifies over 100 systems running a vulnerable version from version strings, but a version string does not reveal compiled flags; the paper itself states in Section 2 that exploitability depends on the compiler setup. The manuscript must qualify the RCE claim to the configurations in which the overflow is exploitable and present the large-scale impact as an upper bound conditioned on toolchain configuration, not as a demonstrated fact.
[§2 Compilation] The threat model is ambiguous. The text says that an attacker 'only requires control of the default specification of the compiler toolchain to trigger the vulnerability to be compiled into the binary' and proposes injecting a file into a compiler search directory or manipulating the build environment. That is a supply-chain or build-time compromise, which is a different attack from remotely sending a malicious RPKI object to an already-deployed Fort instance. For the remote attack described in Section 2, the target's compile-time flags are fixed at build time and are not controllable by the remote attacker. The paper should separate these two threat models and state explicitly which one each claim refers to.
[§3 Evaluation] The evaluation conflates source-level vulnerability with binary-level exploitability. The statement 'all Fort version from Beta-version 2 to version 1.6.2 are vulnerable to buffer overflow' describes the source code; whether a given deployed binary contains the unchecked memcpy depends on the compiler flags used (e.g., _FORTIFY_SOURCE, -fno-builtin-memcpy, -fstack-protector-strong). The live measurement reports client versions, not the set of protections in the executed binaries. To support the large-scale RCE claim, the paper would need to sample the actual toolchain configurations of the observed systems or otherwise bound the fraction that is RCE-exploitable. Without that, the impact assessment remains speculative.
[§2 Escalation] The escalation to RCE on systems with modern protections is asserted rather than demonstrated. The paper states that ASLR can be bypassed by partial overwrite or brute force and cites [1], but it does not show that the specific primitive—an overflow from a 2-byte stack buffer with the third payload byte constrained to be below 0x8—yields a workable partial-overwrite or brute-force strategy for Fort's binary layout. Because the existence of remote RCE on current default builds is central to the paper's impact claim, this step requires at least a concrete exploit strategy or an explicit statement that no such bypass was implemented.

minor comments (5)

[§2 Vulnerable code] The first sentence describes the key-usage field as a 9-bit field, while the overflow uses ku->length as a byte count. Please clarify the exact encoding of ku->length (for example, whether it includes the unused-bits octet of the ASN.1 BIT STRING) and state that a normally encoded 9-bit key usage would fit within the 2-byte buffer.
[§3 Source of vulnerability] The speculative discussion of an intentional backdoor should be clearly labeled as speculation. The abstract's phrase 'identify indications that the discovered vulnerability could constitute an intentional backdoor' overstates what the body shows, since Section 3 concludes that no operational indications for malicious planting were found and that a copy-paste error is also plausible.
[§3 Evaluation] There is a typo: 'all Fort version from Beta-version 2' should be 'all Fort versions from Beta-version 2'.
[§2 Exploitation] The statement that 'The RP will only log a benign error about a malformed key-usage extension' is vague; please specify the exact log entry and its location, since 'benign' is a strong claim.
[§1 Introduction] The phrase 'We develop an RFC attack vector' is ambiguous; it should be 'an attack vector based on RPKI objects' or 'an attack vector using RFC 5280 certificate extensions' to avoid confusion with the RFC publication process.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the RCE finding is anchored to the Fort source, a live RPKI repository, and an independently assigned CVE; no fitted input or self-citation chain carries the result.

full rationale

The paper's central claim is a concrete memory-corruption vulnerability in Fort's key-usage parsing (Listing 1), triggered through RPKI publication points. The derivation chain is anchored to external artifacts: the vulnerable source code, a locally reproduced crash in a default compiler configuration, a PoC overwriting the return pointer in a non-hardened build, a live measurement of over 100 Fort instances reporting vulnerable version strings, and CVE-2024-45237 assigned with a 9.8 critical rating. None of these steps reduce to the paper's own inputs by construction. The exploitability of the overflow is explicitly conditional on compiler protections (Section 2, 'Compilation'), and the paper distinguishes between the source-level bug, the demonstrated crash under default protections, and the RCE PoC with protections disabled; this is a limitation in the strength of the RCE generalization, not a circularity. The only self-citation, [2] (CURE), is used as a tool citation for setting up a local RPKI repository and as a reference for the general abundance of RPKI vulnerabilities; it is not load-bearing for the vulnerability discovery, the PoC, or the CVE. No quantity is fitted to force a predicted outcome, no uniqueness theorem is imported from the authors' prior work, and no known result is renamed. The gap between 'real memory-corruption bug' and 'unqualified large-scale RCE impact' is an evidentiary or correctness concern about compiler-dependent exploitability, not a circular-derivation concern, and therefore does not raise the circularity score.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claim relies on the attacker being able to feed malicious objects through RPKI publication points and on target Fort builds lacking effective compiler protections. No invented entities or fitted parameters are introduced.

assumptions (4)

domain assumption An attacker can obtain RPKI publication point resources, specifically IP address space and RIR membership, to host malicious RPKI objects.
Section 2 'Real-world exploitation' states that setting up a repository requires ownership of Internet resources and RIR membership, which the paper treats as a low barrier. This is load-bearing for remote exploitability.
domain assumption Victim Fort deployments run binaries compiled without effective memory protections, or with older toolchain defaults that leave the overflow exploitable.
Section 2 'Compilation' says none of the protections are explicitly set in the build configuration and that exploitability depends on toolchain defaults and flags. The PoC disables compiler protections, so the universal RCE claim relies on this environmental assumption.
domain assumption BGP routers accept the relying party's output without performing independent cryptographic verification.
Sections 1 and 3 state that routers do not perform additional cryptographic checks and that data provided to routers does not require signatures, which makes RPKI tampering impactful.
domain assumption The vulnerable memcpy path is reachable in all Fort versions from Beta version 2 to 1.6.2.
Section 3 states that the code was added in January 2019 and that all versions up to 1.6.2 are vulnerable. Only version 1.6.2 is experimentally confirmed by the paper.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Poster: From Fort to Foe: The Threat of RCE in RPKI." pith.science (2026). https://pith.science/paper/X7TUH4LW

@misc{pith2026241116518,
  author       = {Pith},
  title        = {Pith review of: Poster: From Fort to Foe: The Threat of RCE in RPKI},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/X7TUH4LW}},
  note         = {Machine review of arXiv:2411.16518}
}

read the original abstract

In this work, we present a novel severe buffer-overflow vulnerability in the RPKI validator Fort, that allows an attacker to achieve Remote Code Execution (RCE) on the machine running the software. We discuss the unique impact of this RCE on networks that use RPKI, illustrating that RCE vulnerabilities are especially severe in the context of RPKI. The design of RPKI makes RCE easy to exploit on a large scale, allows compromise of RPKI validation integrity, and enables a powerful vector for additional attacks on other critical components of the network, like the border routers. We analyze the vulnerability exposing to this RCE and identify indications that the discovered vulnerability could constitute an intentional backdoor to compromise systems running the software over a benign coding mistake. We disclosed the vulnerability, which has been assigned a CVE rated 9.8 critical (CVE-2024-45237).

Figures

Figures reproduced from arXiv: 2411.16518 by the authors.

**Figure 1.** Attack Setup. to routers. RPs fetch objects from all the public RPKI PPs, parse and validate them, and compile a list of validated prefixed for the routers to use in BGP for best path selection. This allows the routers to filter incoming BGP announcements for valid ownership of prefixes; if the announced Autonomous System (AS) number inside the BGP message differs from the authorized AS-prefix pair in the RPKI, the… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

2 extracted references · 2 canonical work pages

[1]

Dmitry Evtyushkin, Dmitry Ponomarev, and Nael Abu-Ghazaleh. 2016. Jump over ASLR: Attacking branch predictors to bypass ASLR. In2016 49th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO) . IEEE, 1–13

work page 2016
[2]

Donika Mirdita, Haya Schulmann, Niklas Vogel, and Michael Waidner. 2024. The CURE to vulnerabilities in RPKI validation. NDSS Symposium (2024)

work page 2024

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.

[1] [1]

Dmitry Evtyushkin, Dmitry Ponomarev, and Nael Abu-Ghazaleh. 2016. Jump over ASLR: Attacking branch predictors to bypass ASLR. In2016 49th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO) . IEEE, 1–13

work page 2016

[2] [2]

Donika Mirdita, Haya Schulmann, Niklas Vogel, and Michael Waidner. 2024. The CURE to vulnerabilities in RPKI validation. NDSS Symposium (2024)

work page 2024