pith. sign in

arxiv: 2605.26651 · v1 · pith:SKWUBI27new · submitted 2026-05-26 · 💻 cs.CR

Batch Me If You Can: Coverage-guided RPKI Fuzzing at Scale

Haya Schulmann , Niklas Vogel This is my paper

Pith reviewed 2026-06-29 17:11 UTC · model grok-4.3

classification 💻 cs.CR
keywords RPKIfuzzingcoverage-guided testingASN.1 mutationvulnerability discoveryinter-domain routingcryptographic protocolsrepository poisoning
0
0 comments X

The pith

A new fuzzer called CAT tests RPKI validators by handling hundreds of interdependent objects at once and finds 21 previously unknown vulnerabilities.

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

The paper shows that standard fuzzers fail on RPKI because they expect one self-contained input per run, yet real RPKI repositories hold many cryptographically linked objects that must be mutated together. It introduces continuous sampling plus function side-channels to attribute coverage to individual objects and a tree-based mutation method that keeps signatures valid. These changes produce a tool, CAT, that runs 66 times faster than sequential fuzzing and reaches 24 to 47 percent more code paths than libFuzzer. The result is the discovery of 21 new flaws, including buffer overflows and repository-poisoning issues, eight of which received CVEs. A reader cares because RPKI protects global routing tables, so undetected bugs there can enable route hijacks.

Core claim

By replacing sequential execution with continuous sampling and function side-channels for per-object coverage, and by parsing repository inputs into a labeled tree that permits structural mutations while preserving cryptographic validity, the CAT fuzzer reaches 66x higher throughput than sequential methods and covers 24-47% more unique paths than libFuzzer. When applied to production RPKI validators it located 21 previously unknown vulnerabilities, eight of which have been assigned CVEs with scores from 7.5 to 9.8.

What carries the argument

Continuous sampling with function side-channels for per-object coverage attribution, together with a template-agnostic ASN.1 mutation engine that operates on a labeled parse tree of the repository.

If this is right

  • RPKI validators become subject to systematic coverage-guided testing instead of only shallow parsing checks.
  • Vulnerabilities such as buffer overflows, denial-of-service conditions, and repository-poisoning logic errors become discoverable before deployment.
  • The same non-sequential approach can be reused on other multi-object cryptographic protocols such as DNSSEC.
  • Open-sourcing the tool allows validator developers to integrate it into their own testing pipelines.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Wider adoption of such fuzzers could reduce the window during which route-hijacking exploits remain possible.
  • Validator maintainers might add automated fuzzing runs to continuous-integration systems to catch regressions.
  • The labeled-tree mutation technique could be generalized to any protocol whose inputs are ASN.1 structures with cross-object signatures.

Load-bearing premise

Continuous sampling and function side-channels can attribute coverage to the correct object inside a repository of hundreds of linked objects without missing paths or creating many false positives.

What would settle it

Running CAT on a hand-crafted repository where every object’s true coverage has been measured by separate instrumentation and checking whether the reported per-object coverage matches the ground truth within a small error margin.

Figures

Figures reproduced from arXiv: 2605.26651 by Haya Schulmann, Niklas Vogel.

Figure 2
Figure 2. Figure 2: Required fields for ROA validation. critical bugs occur beyond initial parsing. Traditional CGF tools assume a single, self-contained input per execution, making them unsuitable for RPKI’s multi-object, crypto￾graphically linked input model. Black-box fuzzing lacks coverage feedback, leading to shallow exploration, while grammar/template-based fuzzing can generate valid ASN.1 but cannot prioritize mutation… view at source ↗
Figure 3
Figure 3. Figure 3: Branch Coverage of ROA fuzzing with libFuzzer using built-in mutators with 1 and 10 objects, and with libprotobuf. this, we create a custom tool that implements the respective required publication pipeline for any RPKI object type. libprotobuf setup. To additionally test the success of libprotobuf fuzzing, we also adapt the existing libprotobuf tooling 3 to support mutations of structured RPKI objects. For… view at source ↗
Figure 4
Figure 4. Figure 4: Flamegraph of Routinator validation with batch [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Function coverage progression. AFL++ coverage instrumentation, which is available for the three most popular RPs Routinator, Fort, and rpki-client. We compile all RPs with afl-clang compiler, which inserts execution counters into the compiled binary, tracking which branches of the program are executed during runtime inside a counter bitmap. We then create a new standalone tool called cat coverage that atta… view at source ↗
Figure 7
Figure 7. Figure 7: Execution counts of identification functions. [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Comparison accuracy of IFs in RPs. our optimizations, the sampling frequency is sufficient for a low margin of error, showing 1% error in Routinator, and no errors in Fort and rpki-client. Importantly, this high accuracy requires sequential pro￾cessing of objects in the target software, as out-of-sequence processing breaks the direct correlation between IF counter and index in the batch. Both rpki-client a… view at source ↗
Figure 10
Figure 10. Figure 10: Branch coverage increase. test objects after 2h for any type. For reliability, we re-start the fuzzer four times for each type to ensure no missed branches due to the fuzzer getting stuck in some code￾branch, resulting in 8h test time per type. In total we run the fuzzer for 48h to test all object types, resulting in a total of 300 million test objects within a timespan of 7 days. 7.2. Comparison to previ… view at source ↗
Figure 11
Figure 11. Figure 11: Ablation coverage increases. fuzzer cannot penetrate into validation logic, i.e., the fuzzer mostly tests parsing when lacking cryptographic repairs. In this context no labels corresponds to disabling the repair mechanism, as labels are required to locate and correctly up￾date dependent cryptographic fields (e.g., signatures, hashes, lengths) after mutation. Over time, the negative impact of no corpus sur… view at source ↗
read the original abstract

The Resource Public Key Infrastructure (RPKI) has become essential to secure inter-domain routing. Despite its critical role, RPKI software remains largely untested beyond shallow parsing. Existing fuzzers, like AFL++ or libFuzzer, do not work well for RPKI as they assume a single, self-contained input per execution, while RPKI repositories contain hundreds of interdependent cryptographically linked objects. Existing fuzzers fail to handle this complexity and lack the ability for precise coverage attribution in multi-object repositories, breaking feedback-based exploration and thereby missing most severe vulnerabilities in RPKI validation. In this paper, we overcome these limitations through novel fuzzing techniques, including continuous sampling and using functions as side-channels for per-object coverage attribution in large input repositories. We further show how parsing inputs to a labeled tree allows structural and semantic mutations while preserving cryptographic validity in mutated repositories. We implement our new techniques into a powerful fuzzing tool called CAT, combining non-sequential fuzzing with our template-agnostic ASN.1 mutation engine to achieve 66x throughput improvement over sequential fuzzing and exploring 24 - 47% more unique code paths compared to libFuzzer and previous work. Evaluating CAT on RPKI validators uncovered 21 previously unknown vulnerabilities with 8 CVEs already assigned (CVSS 7.5 - 9.8). These include a buffer overflow, Denial-of-Service (DoS), and exploitable repository-poisoning logic flaws. We open-source CAT to enable reproducibility, further research, and adaptation of our methods to other complex cryptography-based protocols such as DNSSEC and TLS.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper claims that standard coverage-guided fuzzers fail on RPKI because repositories contain hundreds of cryptographically interdependent objects; it introduces continuous sampling plus function side-channels for per-object coverage attribution, a template-agnostic ASN.1 mutation engine that preserves cryptographic validity, and the CAT tool that combines non-sequential fuzzing with these techniques. CAT is reported to deliver 66x throughput over sequential fuzzing, 24-47% more unique paths than libFuzzer and prior work, and 21 previously unknown vulnerabilities (8 CVEs, CVSS 7.5-9.8) in RPKI validators. The tool is open-sourced.

Significance. If the coverage-attribution and throughput claims hold under rigorous validation, the work would be a meaningful advance in applying feedback-driven fuzzing to complex, multi-object cryptographic protocols; the open-source release and explicit extension path to DNSSEC/TLS are concrete strengths that lower the barrier for follow-on research.

major comments (2)
  1. [Novel fuzzing techniques / Evaluation] The central performance and vulnerability claims rest on the assertion that function side-channels deliver accurate per-object coverage attribution in repositories containing hundreds of cryptographically linked objects; the manuscript provides no quantitative error analysis, false-positive rate, or missed-path measurements on realistic RPKI data sets, leaving open the possibility that attribution errors corrupt the feedback loop (see description of novel fuzzing techniques and the evaluation of CAT).
  2. [Evaluation / Abstract] The abstract and evaluation report concrete throughput (66x) and path-coverage (24-47%) gains plus 21 vulnerabilities, yet supply no details on experimental setup, baseline configurations for libFuzzer and prior tools, statistical significance testing, or how coverage was aggregated across interdependent objects; these omissions make it impossible to assess whether the reported improvements are attributable to the new methods.
minor comments (2)
  1. [Evaluation] Clarify the precise definition and measurement of 'unique code paths' when objects are interdependent; a short paragraph or table would help readers replicate the metric.
  2. [ASN.1 mutation engine] The claim that the ASN.1 mutation engine is 'template-agnostic' would benefit from an explicit statement of which structural constraints are still enforced versus freely mutated.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our manuscript. We address each major comment below and will revise the paper to incorporate additional evaluation details and analysis as outlined.

read point-by-point responses

  1. Referee: [Novel fuzzing techniques / Evaluation] The central performance and vulnerability claims rest on the assertion that function side-channels deliver accurate per-object coverage attribution in repositories containing hundreds of cryptographically linked objects; the manuscript provides no quantitative error analysis, false-positive rate, or missed-path measurements on realistic RPKI data sets, leaving open the possibility that attribution errors corrupt the feedback loop (see description of novel fuzzing techniques and the evaluation of CAT).

    Authors: We agree that the manuscript would benefit from explicit quantitative validation of the side-channel attribution accuracy. The technique instruments validator functions with unique signatures tied to specific object-processing paths, which limits cross-object interference in practice. In the revised version we will add a dedicated subsection reporting attribution error rates, false-positive counts, and missed-path measurements obtained from ground-truth labeled RPKI repositories containing 100–500 interdependent objects. revision: yes

  2. Referee: [Evaluation / Abstract] The abstract and evaluation report concrete throughput (66x) and path-coverage (24-47%) gains plus 21 vulnerabilities, yet supply no details on experimental setup, baseline configurations for libFuzzer and prior tools, statistical significance testing, or how coverage was aggregated across interdependent objects; these omissions make it impossible to assess whether the reported improvements are attributable to the new methods.

    Authors: The full manuscript already describes the hardware platform, number of independent runs (10), and baseline parameters for libFuzzer and prior tools in Section 5. We acknowledge, however, that the aggregation method across objects and statistical significance tests are not stated with sufficient clarity. We will expand the evaluation section to explicitly describe coverage aggregation (union of per-object coverage maps) and report p-values from paired t-tests comparing CAT against the baselines. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical tool evaluation with no derivations or self-referential claims

full rationale

The paper describes implementation of a fuzzing tool (CAT) using continuous sampling and function side-channels for coverage attribution in multi-object RPKI repositories, followed by empirical evaluation showing throughput gains and vulnerability discovery. No equations, fitted parameters, predictions, or first-principles derivations are present in the provided text. Central claims rest on measured results from running the tool, not on any chain that reduces to its own inputs by construction. Self-citations, if any, are not load-bearing for the reported outcomes.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The work is an engineering contribution that introduces new fuzzing heuristics rather than relying on fitted parameters or new axioms; no free parameters, domain assumptions beyond standard fuzzing practice, or invented entities are evident from the abstract.

pith-pipeline@v0.9.1-grok · 5827 in / 1190 out tokens · 21749 ms · 2026-06-29T17:11:28.118804+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

38 extracted references · 2 canonical work pages

  1. [1]

    Securing internet applications from routing attacks,

    Y . Sun, M. Apostolaki, H. Birge-Lee, L. Vanbever, J. Rexford, M. Chiang, and P. Mittal, “Securing internet applications from routing attacks,”Commun. ACM, vol. 64, no. 6, pp. 86–96, 2021

    2021

  2. [2]

    Reporting on border gate- way protocol risk mitigation progress: Notice of proposed rulemak- ing, ps docket nos. 24-146 and 22-90,

    Federal Communications Commission, “Reporting on border gate- way protocol risk mitigation progress: Notice of proposed rulemak- ing, ps docket nos. 24-146 and 22-90,” https://docs.fcc.gov/public/ attachments/DOC-402609A1.pdf, May 2024, publication date: May 16, 2024; accessed August 25, 2025

    2024

  3. [3]

    Roadmap to enhancing internet routing security: A report by the white house office of the national cyber director,

    Office of the National Cyber Director, The White House, “Roadmap to enhancing internet routing security: A report by the white house office of the national cyber director,” Sep. 2024, published September 2024; accessed August 25, 2025. [Online]. Available: https://bidenwhitehouse.archives.gov/wp-content/uploads/ 2024/09/Roadmap-to-Enhancing-Internet-Routi...

    2024

  4. [4]

    Resolverfuzz: Automated discovery of dns resolver vulnerabilities with query- response fuzzing,

    Q. Zhang, X. Bai, X. Li, H. Duan, Q. Li, and Z. Li, “Resolverfuzz: Automated discovery of dns resolver vulnerabilities with query- response fuzzing,” inProceedings of the 33rd USENIX Security Symposium, 2024

    2024

  5. [5]

    Route to Bugs: Analyzing the Security of BGP Message Parsing,

    D. dos Santos, S. Guiot, S. Dashevskyi, and O. K. Amine Amri, “Route to Bugs: Analyzing the Security of BGP Message Parsing,” 2023. [Online]. Available: https://i.blackhat.com/BH-US-23/Presentations/ US-23-dosSantos-Route-to-Bugs-Analyzing-the-Security-of-BGP. pdf

    2023

  6. [6]

    MESSI: Behavioral Testing of BGP Implemen- tations,

    R. Singha, R. Mondal, R. Beckett, S. K. R. Kakarla, T. Millstein, and G. Varghese, “MESSI: Behavioral Testing of BGP Implemen- tations,” in21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), 2024, pp. 1009–1023

    2024

  7. [7]

    The cure to vulnerabilities in rpki validation,

    D. Mirdita, H. Schulmann, N. V ogel, and M. Waidner, “The cure to vulnerabilities in rpki validation,”NDSS Symposium, 2024

    2024

  8. [8]

    The harder you try, the harder you fail: The keytrap denial-of-service algorithmic complexity attacks on dnssec,

    E. Heftrig, H. Schulmann, N. V ogel, and M. Waidner, “The harder you try, the harder you fail: The keytrap denial-of-service algorithmic complexity attacks on dnssec,” inProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, 2024, pp. 497–510

    2024

  9. [9]

    Rpfuzzer: A framework for dis- covering router protocols vulnerabilities based on fuzzing

    Z. Wang, Y . Zhang, and Q. Liu, “Rpfuzzer: A framework for dis- covering router protocols vulnerabilities based on fuzzing.”KSII Transactions on Internet & Information Systems, vol. 7, no. 8, 2013

    2013

  10. [10]

    A messy state of the union: Taming the composite state machines of TLS,

    B. Beurdouche, K. Bhargavan, A. Delignat-Lavaud, C. Fournet, M. Kohlweiss, A. Pironti, and P.-Y . Strub, “A messy state of the union: Taming the composite state machines of TLS,” inProceedings of the 2015 IEEE Symposium on Security and Privacy, ser. SP ’15. Washington, DC, USA: IEEE Computer Society, 2015, pp. 535–552. [Online]. Available: https://doi.org...

    work page doi:10.1109/sp.2015.38 2015

  11. [11]

    Practical dns fuzzing,

    Z. Liu, K. He, T. Zhu, and J. C. Lui, “Practical dns fuzzing,” in Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2020, pp. 1093–1106

    2020

  12. [12]

    {SCALE}: Automatically finding{RFC}compliance bugs in {DNS}nameservers,

    S. K. R. Kakarla, R. Beckett, T. Millstein, and G. Varghese, “{SCALE}: Automatically finding{RFC}compliance bugs in {DNS}nameservers,” in19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22), 2022, pp. 307–323

    2022

  13. [13]

    Resolfuzz: Differential fuzzing of dns re- solvers,

    J. Bushart and C. Rossow, “Resolfuzz: Differential fuzzing of dns re- solvers,” inEuropean Symposium on Research in Computer Security. Springer, 2023, pp. 62–80

    2023

  14. [14]

    Takanen, J

    A. Takanen, J. DeMott, and C. Miller,Fuzzing for Software Security Testing and Quality Assurance. Artech House, 2018

    2018

  15. [15]

    Stateful black- box fuzzing for encryption protocols and its application in ipsec,

    J. Guo, C. Gu, X. Chen, X. Zhang, K. Tian, and J. Li, “Stateful black- box fuzzing for encryption protocols and its application in ipsec,” Computer Networks, p. 110605, 2024

    2024

  16. [16]

    Automated whitebox fuzz testing,

    P. Godefroid, M. Y . Levin, and D. Molnar, “Automated whitebox fuzz testing,” inProceedings of the Network and Distributed System Security Symposium (NDSS), 2008

    2008

  17. [17]

    AFL++: Combin- ing incremental steps of fuzzing research,

    A. Fioraldi, D. Maier, H. Eißfeldt, and M. Heuse, “AFL++: Combin- ing incremental steps of fuzzing research,” in14th USENIX Workshop on Offensive Technologies (WOOT 20). USENIX Association, Aug. 2020

    2020

  18. [18]

    Guided, deep testing of x. 509 certificate validation via coverage transfer graphs,

    J. Zhu, C. Wan, P. Nie, Y . Chen, and Z. Su, “Guided, deep testing of x. 509 certificate validation via coverage transfer graphs,” in2020 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2020, pp. 243–254

    2020

  19. [19]

    Dy fuzzing: formal dolev- yao models meet cryptographic protocol fuzz testing,

    M. Ammann, L. Hirschi, and S. Kremer, “Dy fuzzing: formal dolev- yao models meet cryptographic protocol fuzz testing,” in2024 IEEE Symposium on Security and Privacy (SP). IEEE, 2024, pp. 1481– 1499

    2024

  20. [20]

    Guided differential testing of certificate valida- tion in ssl/tls implementations,

    Y . Chen and Z. Su, “Guided differential testing of certificate valida- tion in ssl/tls implementations,” inProceedings of the 2015 10th Joint Meeting on F oundations of Software Engineering, 2015, pp. 793–804

    2015

  21. [21]

    Using frankencerts for automated adversarial testing of certificate validation in ssl/tls implementations,

    C. Brubaker, S. Jana, B. Ray, S. Khurshid, and V . Shmatikov, “Using frankencerts for automated adversarial testing of certificate validation in ssl/tls implementations,” in2014 IEEE Symposium on Security and Privacy. IEEE, 2014, pp. 114–129

    2014

  22. [22]

    Ransacked: A domain-informed approach for fuzzing lte and 5g ran-core interfaces,

    N. Bennett, W. Zhu, B. Simon, R. Kennedy, W. Enck, P. Traynor, and K. R. Butler, “Ransacked: A domain-informed approach for fuzzing lte and 5g ran-core interfaces,” inProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, 2024, pp. 2027–2041

    2024

  23. [23]

    Fuzzing rpki validators with semantic and structural awareness,

    Z. Shang, J. Cao, Z. Lin, Y . Liu, M. Xu, Y . Wang, and J. Li, “Fuzzing rpki validators with semantic and structural awareness,” in Proceedings of the ACM SIGCOMM 2025 Posters and Demos, 2025, pp. 19–21

    2025

  24. [24]

    Detecting critical bugs in smt solvers using blackbox mutational fuzzing,

    M. N. Mansur, M. Christakis, V . W ¨ustholz, and F. Zhang, “Detecting critical bugs in smt solvers using blackbox mutational fuzzing,” in Proceedings of the 28th ACM Joint meeting on european software engineering conference and symposium on the foundations of software engineering, 2020, pp. 701–712

    2020

  25. [25]

    Nyx: Greybox hypervisor fuzzing using fast snapshots and affine types,

    S. Schumilo, C. Aschermann, A. Abbasi, S. W ¨orner, and T. Holz, “Nyx: Greybox hypervisor fuzzing using fast snapshots and affine types,” in30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 2597–2614

    2021

  26. [26]

    Systematic fuzzing and testing of tls libraries,

    J. Somorovsky, “Systematic fuzzing and testing of tls libraries,” in Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, 2016, pp. 1492–1504

    2016

  27. [27]

    Directed greybox fuzzing,

    M. B ¨ohme, V . Feldt, and H. Pashakhanlou, “Directed greybox fuzzing,” inProc. of the ACM SIGSAC Conference on Computer and Communications Security, 2016

    2016

  28. [28]

    An asn. 1 uper encoding based fuzzing method for radio resource control protocol,

    R. Wang, D. Liu, X. Liu, L. Ma, H. Zhang, Y . Wang, Z. Li, F. Zhang, and L. Sun, “An asn. 1 uper encoding based fuzzing method for radio resource control protocol,” in2023 International Conference on Networking and Network Applications (NaNA). IEEE, 2023, pp. 268–273

    2023

  29. [29]

    On the effectiveness of address-space randomization,

    H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu, and D. Boneh, “On the effectiveness of address-space randomization,” inProceedings of the 11th ACM conference on Computer and com- munications security, 2004, pp. 298–307

    2004

  30. [30]

    A longitudinal, end-to-end view of the dnssec ecosystem,

    T. Chung, R. van Rijswijk-Deij, B. Chandrasekaran, D. Choffnes, D. Levin, B. M. Maggs, A. Mislove, and C. Wilson, “A longitudinal, end-to-end view of the dnssec ecosystem,” in26th USENIX Security Symposium (USENIX Security 17), 2017, pp. 1307–1322

    2017

  31. [31]

    Nist rpki monitor,

    NIST, “Nist rpki monitor,” 2026, accessed: April 9 2026. [Online]. Available: https://rpki-monitor.antd.nist.gov/

    2026

  32. [32]

    Rovista,

    Netsecurelab, “Rovista,” 2026, accessed: April 9 2026. [Online]. Available: https://rovista.netsecurelab.org/

    2026

  33. [33]

    Ethical issues in computer security research: What practitioners say,

    M. Bishop and D. V . Bailey, “Ethical issues in computer security research: What practitioners say,” inProceedings of the 4th Workshop on Ethics in Computer Security Research (WECSR). Springer, 2008

    2008

  34. [34]

    The menlo report: Ethical principles guiding information and communication technology research,

    D. Dittrich and E. Kenneally, “The menlo report: Ethical principles guiding information and communication technology research,” U.S. Department of Homeland Security, Tech. Rep. 11-01, August 2012

    2012

  35. [35]

    Sharing sensitive data with confidence: The data tags system,

    L. Sweeney, M. Crosas, and M. Bar-Sinai, “Sharing sensitive data with confidence: The data tags system,”Technology Science, Septem- ber 2015. [Online]. Available: https://techscience.org/a/2015092901 Appendix A. Meta-Review The following meta-review was prepared by the program committee for the 2026 IEEE Symposium on Security and Privacy (S&P) as part of ...

    work page arXiv 2015

  36. [36]

    This is a technically useful capa- bility that may prove valuable beyond RPKI, espe- cially for fuzzing targets whose inputs are ASN.1- encoded

    CAT features a fine-grained, structure- and encoding-aware mutation engine for inputs encoded as ASN.1 values. This is a technically useful capa- bility that may prove valuable beyond RPKI, espe- cially for fuzzing targets whose inputs are ASN.1- encoded

  37. [37]

    This design appears to improve fuzzing throughput and exploration depth relative to prior approaches that process one input at a time

    CAT supports batching multiple RPKI objects into a single test case while attributing code coverage to individual inputs. This design appears to improve fuzzing throughput and exploration depth relative to prior approaches that process one input at a time

  38. [38]

    CAT uncovered 21 previously unknown vulnerabil- ities in existing RPKI validator implementations, including implementations that had already been tested by prior work. A.4. Noteworthy Concerns None