Source-linked AI summary
Drishti: AI-Led Human-Directed Vulnerability Auditing for 5G Cores
Sriram Ramachandran, Levente Csikor, Dinil Mon Divakaran
TL;DR
Validation and impact assessment remain costly for 5G-core vulnerability audits. Drishti combines AI-led candidate generation with human-directed, four-part validation and produces three findings across Open5GS and free5GC, including a 2-byte input that OOM-kills an AMF in 6.2 seconds.
Problem
Validation and impact assessment remain scarce and costly for 5G-core vulnerability audits, especially for verifying defects, reachability, operator impact, and fix-completeness.
Method
Drishti combines a cellular-core anti-pattern catalog, critical-path triage, concentric validation, and patch-review in an AI-led human-directed audit procedure.
Results
Applied to Open5GS and free5GC, Drishti produced three findings, including a 2-byte input that OOM-killed the free5GC AMF in 6.2 seconds and a shipped CVE patch with dead defense-in-depth code.
Takeaways & Limitations
The findings show that Drishti can turn 5G-core vulnerability candidates into validated operator-impact and fix-completeness claims.
Takeaways & Limitations
The evaluation covers only open-source implementations and lacks a controlled comparison against another audit system.
Abstract
from arXiv · showhide
Candidate generation for open-source vulnerabilities is no longer scarce. AI-assisted code review now produces defect candidates cheaply, and industry programs pair them with expert human triage. The remaining scarcity is validation and impact assessment, and the gap is largest in critical-infrastructure software like 5G cores. Here, validation has four costs: verification, reachability, impact, and fix-completeness. We present Drishti, an AI-led human-directed vulnerability audit framework with four components, one per cost: (i) an anti-pattern catalog for verification, (ii) critical-path triage for reachability, (iii) concentric validation for impact, and (iv) patch-review for fix-completeness. Across audits of Open5GS and free5GC, Drishti produced three findings. The first is a pre-authentication NULL-dereference in the Open5GS NRF multipart parser, fixed upstream with a CVE requested. The second is an ASN.1-PER memory amplification in the free5GC NGAP decoder. A 2-byte input from a rogue gNodeB OOM-kills the AMF in 6.2 seconds. The third is a defective patch on CVE-2025-69248 whose defense-in-depth check is dead code before authentication.
1 Introduction
AI-assisted vulnerability discovery has made candidate generation abundant, shifting scarcity toward validation and impact assessment. Drishti addresses this gap in open-source 5G cores by pairing AI-generated candidates with expert human triage across four validation costs.
- Motivation: Candidate generation is no longer scarce, while validation and impact assessment have become the main bottlenecks.Google lowered payouts for lower-complexity findings after citing AI-assisted discovery, and Chrome 149 shipped 429 security fixes in one stable release.
- Motivation: Frontier agents reproduce benchmark targets in only 17−22% of cases and can produce incomplete or misleading patches.On CyberGym’s 1,507-instance benchmark across 188 projects, agents surfaced 18 incomplete patches across 15 projects; expert review found some fixes merely guarded crash sites or masked corrupted state.
- 5G-Core Auditing: 5G-core auditing is costly because coordinated network functions handle authentication, session management, and service discovery for connected devices.The paper identifies four validation costs: verification, reachability, impact, and fix-completeness.
- Drishti: Drishti is an AI-led, human-directed audit framework for open-source 5G cores that specializes industry-standard AI candidate generation and expert triage for the cellular domain.Its components target verification with a domain-specific anti-pattern catalog and address the four identified validation costs.
2 Background and Related Work
The 5G core exposes attacker-influenced NAS, NGAP, and SBI protocol surfaces across interconnected control-plane functions. Prior work spans protocol testing, specification modeling, AI-assisted discovery, and repair, while Drishti instead combines source review, a cellular-core anti-pattern catalog, 3GPP-driven triage, and shipped-patch auditing.
- 5G Core Background: The 5G core uses HTTP/2-based SBI links among control-plane functions, while the UPF forwards subscriber traffic.Relevant functions include AMF, SMF, AUSF, UDM, and NRF.
- 5G Core Background: NAS, NGAP, and SBI expose attacker-influenced inputs through TLV, ASN.1-PER, and JSON or multipart encodings.N2 IPsec is optional and often disabled, increasing exposure of the NGAP surface.
- Related Work: Prior 5G testing systems fuzz protocol traffic or learned state machines, whereas Drishti reads source and audits shipped patches.Drishti also applies an anti-pattern catalog for cellular-core code; cited systems do not report shipped-patch audits as outputs.
- Related Work: SPEC5G uses 3.5 million sentences from more than 13k cellular-network specifications and 13 websites, while Drishti encodes protocol semantics in an anti-pattern catalog and 3GPP-driven triage.The approaches differ in direction: specification-to-structure extraction versus semantics-guided code review.
- AI-Assisted Security Research: CyberGym agents reproduce target vulnerabilities in only 17−22% of 1,507 instances, and corrected detection results drop from 68% to 3% F1-score.These limits motivate Drishti’s focus on review-worthy validation artifacts rather than discovery alone.
- Design Premise: Drishti’s design premise is that general-purpose benchmark and evaluation systems identify limitations but provide no method to overcome them, motivating its integrated 5G-specific audit procedure.The framework adds artifacts that general-purpose systems do not provide and applies its symptom-fix taxonomy retrospectively.
3 Drishti Framework
Drishti is a seven-step, cost-aware audit procedure that combines an anti-pattern catalog, reachability triage, concentric validation, and fix-layer selection. It allocates human effort to curation, triage, semantic reasoning, lab work, and final checks while AI handles per-candidate analysis.
- Procedure: Drishti’s seven steps progress from linting and catalog-based candidate enumeration through contextual review, reachability analysis, exploitability validation, and fix-layer selection.The procedure prioritizes cheaper filters before more expensive validation.
- Anti-pattern catalog: 17 catalog entries AP1–AP17 capture recurring vulnerability-producing patterns across free5GC NAS, NGAP, and ASN.1-PER decoder code.Each entry includes a description, language-specific idioms, and a grep recipe for mechanical candidate enumeration.
- Anti-pattern catalog: None of gosec, staticcheck, or golangci-lint covers the highest-impact decoder anti-patterns: memory amplification, CPU exhaustion, stack exhaustion, and unbounded state growth.Drishti supplements these gaps with taint tracking, AST queries, and handler-state review.
- Critical-path triage: Reachability triage ranks surviving code by 3GPP-procedure impact, authentication state, blast radius, and attacker class, focusing on rogue UEs and rogue gNBs.Candidates are tagged with the reaching attacker class and the 3GPP procedure carrying the input.
- Concentric validation: Concentric validation expands from unit-test reproduction to single-network-function testing, full-core realistic traffic, and operator-relevant impact measurement.The four stages progressively validate stronger claims at higher cost, measuring crashes, resource pressure, system-level effects, time to impact, scope, recovery, and configuration sensitivity.
4 Case studies
Drishti’s three case studies show how its validation, source-reading, and patch-review components uncovered exploitable defects in free5GC and Open5GS. The findings span memory exhaustion, pre-authentication denial of service, and an ineffective defense-in-depth patch.
- free5GC NGAP amplification: 4 MB of heap per 2-byte malformed input exceeded two million-fold amplification, and the AMF was OOM-killed in 6.2 seconds.The test used MemoryMax=256M and 48 concurrent workers; validation stopped after the decisive single-NF OOM-kill.
- Open5GS NRF parser: A pre-authentication NULL field dereference in Open5GS’s NRF multipart parser crashed the NRF and drove all seven registered network functions into exception and retry states.The defect was reachable before authentication because it occurred before request dispatch, and staged testing reproduced the crash with the first malformed message.
- Open5GS NRF parser: The Open5GS maintainer fixed the parser defect within 15 days, and the audit team requested a CVE from MITRE.The failure would prevent new PDU-session establishment until PFCP recovery in a similarly configured private 5G deployment.
- Patch review: The free5GC v1.2.3 patch correctly closes the original AMF panic, but its defense-in-depth validation is unreachable before authentication because of two coding errors.The errors are a read against a zero-allocated buffer before the wire read and a mask width that misclassifies the identity-type field.
5 Discussion
Drishti’s NGAP amplification finding differs from stateful FSM fuzzing by exposing decoder-side allocation defects before the state machine engages. The results are illustrative, limited to open-source implementations without controlled comparison, and the CPS/IoT experiment measures 5G service failure rather than physical-process consequences.
- Related work: CoreCrisis targets the same pre-authentication NAS/N1 surface as Drishti’s NGAP amplification finding, but uses stateful FSM fuzzing of a black-box implementation.The methods therefore operate on the same surface through different auditing approaches.
- Related work: FSM fuzzing surfaces expressible state-transition bugs, whereas domain-catalog source reading exposes decoder-side allocation defects reachable before the state machine engages.The passage contrasts the defect classes each method can reveal.
- Limitations: The results are illustrative rather than statistical because the three generation routes have different denominators, making one false-positive rate misleading.The paper does not present the findings as a statistical estimate.
- Limitations: The evaluation examined only open-source implementations and did not include a controlled comparison against another audit system.Future work should compare independent implementations and examine post-authentication surfaces.
- Limitations: The CPS/IoT experiment measures 5G service failure, not a physical-process consequence.This limits what can be inferred about real-world physical impacts.
6 Conclusion
AI methods increasingly generate vulnerability candidates for 5G core code, but validating real operator impact remains the central challenge. Drishti addresses this gap by combining four validation components and applying audit effort only when cheaper evidence warrants it.
- Conclusion: Drishti targets the remaining challenge of turning AI-generated 5G-core vulnerability candidates into claims about real operator impact.The framework emphasizes spending audit effort only where evidence warrants it.
- Conclusion: Drishti combines an anti-pattern catalog, critical-path triage, concentric validation, and patch-review to address four validation costs.These components are paired so each cost is paid only when cheaper evidence justifies it.
- Conclusion: The framework was applied to audits of Open5GS and free5GC.
Ethics and Disclosure
Drishti’s experiments were conducted exclusively in an isolated laboratory, and every finding was disclosed to the affected project before paper submission through private or coordinated channels.
- Controlled Evaluation: All experiments ran against open-source 5G cores in an isolated laboratory, never against production networks or third-party deployments.This constrained testing to non-production environments.
- Responsible Disclosure: Every finding was disclosed to the affected project before submission through coordinated or private reporting channels.The Open5GS NRF dereference was reported through the maintainer’s coordinated channel, while free5GC NAS and NGAP findings used the project’s private process.
- Responsible Disclosure: The authors followed standard disclosure timelines and shared reproduction details with affected projects.MITRE was asked to assign a CVE for the Open5GS NRF dereference.
A Appendix · A.1 ASN.1-PER amplification: detailed measurements
The free5GC ASN.1-PER decoder accepts attacker-controlled SEQUENCE OF counts without bounds, enabling large pre-parse allocations. Detailed measurements show that a 2-byte malformed input can trigger multi-megabyte allocation and sustained AMF memory exhaustion.
- A.1 ASN.1-PER amplification: detailed measurements: The vulnerable free5GC decoder is parseSequenceOf in the aper module, which reads the wire-supplied element count before parsing any element.It passes that count to reflect.MakeSlice as both slice length and capacity, without applying a schema-based upper bound.
- A.1 ASN.1-PER amplification: detailed measurements: A 2-byte malformed input allocates 4,200,576 bytes (4.01 MB) of heap before parsing any element.The input patches 0xFF 0xFF into the element-count field of an otherwise well-formed NGSetupRequest.
- A.1 ASN.1-PER amplification: detailed measurements: The target information-element struct is 64 bytes, and the resulting amplification factor exceeds two million.The allocation is driven by the attacker-controlled element count and repeated struct-sized slice entries.
- A.1 ASN.1-PER amplification: detailed measurements: 447 MB AMF resident memory, or 8.4× baseline, occurs without a cgroup memory cap during sustained malformed traffic.Virtual memory grows to 626 MB; resident memory recovers after the attack stops, but the Go heap retains that reservation.
- A.1 ASN.1-PER amplification: detailed measurements: 71% SBI responsiveness remains in the MemoryMax=512M, 24-worker run before the cgroup triggers an OOM-kill.The passage identifies this degradation as occurring under a cgroup memory cap during the attack.
- A.1 ASN.1-PER amplification: detailed measurements: Table 2 reports AMF time-to-OOM under sustained malformed NGSetupRequest traffic across three original configurations and one cross-host revalidation.The original runs used an aarch64 host, while the final row revalidated the result on x86_64.
A.2 CVE-2025-69248 patch defect: line-by-line analysis
The v1.2.3 patch closes the original CVE-2025-69248 panic but leaves its intended defense-in-depth validation dead due to two coding errors. Seven unit tests confirm that malformed pre-authentication MobileIdentity5GS values are accepted, while downstream exploitability remains open.
- A.2 CVE-2025-69248 patch defect: line-by-line analysis: The patch closes the original AMF panic but fails to enforce its intended defense-in-depth validation for malformed pre-authentication identity values.The first patch change closes the original panic path; the second adds validation intended to enforce TS 24.501 length constraints.
- A.2 CVE-2025-69248 patch defect: line-by-line analysis: At lines 321–323, validation reads Buffer[0] before wire bytes are copied into the zero-allocated buffer, making the validation block ineffective.SetLen() creates Buffer = make([]uint8, Len), while binary.Read copies actual bytes only at line 353.
- A.2 CVE-2025-69248 patch defect: line-by-line analysis: The 0x0F mask is too wide: TS 24.501 assigns identity type to bits 1–3, so bit 4 causes misclassification of four odd-encoded types.The affected values are 0x09, 0x0B, 0x0D, and 0x0F; the specification requires mask 0x07.
- A.2 CVE-2025-69248 patch defect: line-by-line analysis: Seven unit tests pass because the decoder accepts every malformed MobileIdentity5GS value the validation block was intended to reject.Tests covered undersized GUTI, IMEI, 5G-S-TMSI, and SUCI values, undefined types 0x06 and 0x07, and an oversized length.
- A.2 CVE-2025-69248 patch defect: line-by-line analysis: The dead validation layer silently accepts malformed pre-authentication MobileIdentity5GS inputs, while their individual exploitability in downstream code remains an open question.No live-stack reproduction was needed because the dead block does not itself crash the AMF and the original panic is already closed.
A.3 Audit accounting · A.4 Experimental setup
The audit accounting distinguishes mechanical candidates, contextual review, confirmed code patterns, and validated reachability or runtime results. The experimental setup reports case-study configurations, experiment durations, and stopping conditions rather than end-to-end audit time.
- A.3 Audit accounting: “Raw” counts mechanical matches before scope exclusions, while “In scope” counts candidates retained for contextual review.These definitions are used in Table 3’s candidate accounting.
- A.3 Audit accounting: Parentheses identify the reviewed sample when review was incomplete.This notation appears in the candidate-count reporting.
- A.3 Audit accounting: “Confirmed” indicates that source review established the code pattern, not that exploitability was proven.Confirmation is distinct from the later reachability and runtime-validation stage.
- A.3 Audit accounting: The final accounting column reports reachability and runtime validation, whereas targeted source reading and patch-review lack a comparable raw-candidate denominator.The accounting therefore does not combine these routes into one false-positive rate.
- A.4 Experimental setup: Experiment duration and stopping conditions are reported instead of end-to-end audit time because early audit records did not consistently capture operator time.The reporting choice addresses incomplete operator-time records.
- A.3 Audit accounting: A dash in Table 3 means that the later stage was not applicable or was not performed.This notation qualifies entries in the candidate-accounting table.
- A.4 Experimental setup: Table 4 summarizes the experimental setup for each reported runtime result across the three case studies.The table is specifically described as covering the three case studies.