FivGeeFuzz: Dual 5G Fuzzing Frameworks

• FivGeeFuzz is a label for two complementary 5G fuzzing frameworks that target vulnerabilities in radio access protocols and core network service interfaces.
• The digital-twin multi-fuzzing framework deploys three strategies (LAL, SyAL, SoAL) to detect RRC and protocol anomalies efficiently using adaptive mutation techniques.
• The grammar-guided fuzzer extracts formal grammars from 3GPP OpenAPI specifications to drive stateful REST API testing, exposing crashes and authorization issues.

Searching arXiv for the named papers and related FivGeeFuzz work. Attempting to retrieve arXiv metadata for FivGeeFuzz-related entries. FivGeeFuzz is the name used in recent 5G security literature for two distinct, technically specialized fuzzing frameworks that target different layers of the 5G stack. One framework is a unified digital-twin-based multi-fuzzing platform for detecting radio-access protocol and implementation vulnerabilities under three attacker prior-knowledge models—Listen-and-Learn (LAL), Synchronize-and-Learn (SyAL), and Source-and-Learn (SoAL). The other is a grammar-based framework for exercising 5G Core Service-Based Interfaces (SBIs), automatically deriving formal grammars from 3GPP OpenAPI specifications and using stateful REST API fuzzing to expose crashes, authorization failures, and unexpected behaviors in inter-network-function communication (Yang et al., 2023, Chen et al., 10 Sep 2025).

1. Scope, nomenclature, and security context

In the cited literature, the name FivGeeFuzz does not denote a single invariant implementation. Rather, it labels two 5G-focused fuzzing systems developed for different threat surfaces. The earlier work addresses the virtualization and softwarization of 5G and NextG as a source of protocol and implementation attack surface, with emphasis on RRC-centric vulnerability discovery and defense simulation. The later work addresses the 5G Core’s Service-Based Architecture (SBA), in which Network Functions (NFs) interact over HTTP-based Service-Based Interfaces and rely on OAuth for access control, creating opportunities for faults in API validation and token enforcement (Yang et al., 2023, Chen et al., 10 Sep 2025).

Paper	Target surface	Core mechanism
"Systematic Meets Unintended: Prior Knowledge Adaptive 5G Vulnerability Detection via Multi-Fuzzing" (Yang et al., 2023)	RRC and related 5G protocol/implementation behavior	Unified digital-twin-based multi-fuzzing with LAL, SyAL, and SoAL
"Cross-Service Token: Finding Attacks in 5G Core Networks" (Chen et al., 10 Sep 2025)	5G Core SBIs across 48 services and 10 NFs	Formal grammar derivation plus stateful, grammar-guided REST API fuzzing

This naming overlap is significant because it can obscure methodological differences. One line of work is centered on protocol-state mutation in UE–gNB exchanges; the other centers on formal grammar construction for HTTP/2 + OAuth2 SBI traffic. At the same time, both share a common objective: systematic, automatable discovery of vulnerabilities in increasingly software-defined cellular infrastructure.

2. Unified digital-twin multi-fuzzing for 5G radio access

The RRC-oriented FivGeeFuzz is defined as a unified digital-twin-based fuzz testing framework designed to detect 5G protocol and implementation vulnerabilities under three attacker prior-knowledge models: LAL as black-box with no prior knowledge, SyAL as gray-box with partial protocol and identifier knowledge, and SoAL as white-box with full source-code access. The three strategies share a common architecture—message capture, state tracking, mutation engine, and result assessment—and differ only in mutation selection and feedback policies (Yang et al., 2023).

At a high level, the framework contains four subsystems: Relay Interface, Sniffer & Decoder, Mutation Engine, and Result Monitor & Database. The Relay Interface mediates UE↔gNB message exchange over TCP or OTA. The Sniffer & Decoder captures and parses RRC/NAS/MAC messages into “states.” The Mutation Engine selects commands or bits to fuzz according to LAL, SyAL, or SoAL policy. The Result Monitor & Database records connection outcomes and updates mutation probabilities.

The architecture is described as a relay-centered pipeline. Two endpoints, UE and gNB, communicate through a Relay containing Sniffer, Decoder, Mutation Engine, and Probability Manager modules. The Sniffer reads raw bytes on uplink and downlink sockets, and the Decoder maps raw bytes to RRC message identifiers. Given an RRC state and fuzzing policy, the Mutation Engine chooses a replacement command or bit mask and injects it into the stream. The Result Monitor observes whether the RRC connection completes through rrcConnectionSetupComplete or times out, and logs the outcome to the Database. The Probability Manager then reads the Database and updates mutation probabilities for SyAL.

This design gives the framework a dual role. It is presented not only as a vulnerability detector but also as a digital twin platform for system testing and defense simulation pipeline. A plausible implication is that the architecture was intended to support both offensive evaluation and operational validation in controlled environments.

3. LAL, SyAL, and SoAL as complementary fuzzing strategies

LAL is a pure black-box, command-level fuzzer. It builds a pool of observed legitimate messages and, for each RRC setup attempt, randomly picks one stored message and replaces an upcoming command of the same channel or type. No protocol or identifier knowledge is assumed. Applied to srsRAN RRC, LAL discovered 129 unintended RRC vulnerabilities over 205 total cases, with average detection time of 0.072 s (Yang et al., 2023).

SyAL adds one piece of domain knowledge, such as a fixed RNTI, so that command identifiers remain synchronized across fuzzing attempts. Its central mechanism is a probability-based prioritization of command replacements. If the set of observed command types is indexed by $i = 1 \ldots N$, SyAL maintains a probability matrix $P \in [0,1]^{N \times N}$, where $P_{i,j}$ estimates the probability that replacing command $i$ with command $j$ will cause a failure. Initially, $P_{i,j} = 1/N$. After each trial on $(i \rightarrow j)$ with outcome $o \in \{0:\text{success}, 1:\text{failure}\}$, the update rule is

$$P_{i,j}^{(t+1)} = \begin{cases} P_{i,j}^{(t)} + \alpha\bigl(1 - P_{i,j}^{(t)}\bigr) & \text{if failure}, \ P_{i,j}^{(t)} - \beta\,P_{i,j}^{(t)} & \text{if success}. \end{cases}$$

Here, $\alpha \in (0,1)$ is the failure-gain learning rate and $P \in [0,1]^{N \times N}$0 is the success-decay rate. In evaluation, the total legal no-CRC-break command permutations were 3,037, and the number of real downlink vulnerabilities was 43. A random baseline required approximately 2,811 trials to find all 43, whereas SyAL with $P \in [0,1]^{N \times N}$1 and $P \in [0,1]^{N \times N}$2 required approximately 1,027 trials, with logarithmic versus linear scaling, and achieved precision approximately $P \in [0,1]^{N \times N}$3 and recall approximately $P \in [0,1]^{N \times N}$4, averaged over 20 runs.

SoAL is white-box bit-level fuzzing. The code base is instrumented so that mutated packets pass all integrity checks. It focuses on high-risk commands identified by LAL and SyAL and performs bit flips or value substitutions on significant fields. The example given is RRCSetupRequest, where the field EstablishmentCause was fuzzed in 16 possible values; certain values caused silent service downgrade or allowed unauthorized calls. SoAL detected three man-in-the-middle vulnerabilities stemming from 5G protocol vulnerabilities. In the quantitative summary, these appear as three MITM issues involving command-level bypass and MAC CRC preservation, confirmed in fewer than 100 bit-level tests.

Taken together, these strategies cover black-box discovery, probability-guided gray-box prioritization, and white-box explanatory analysis. This layered construction is central to the framework’s claim of handling vulnerabilities “with and without prior knowledge assumptions from attackers.”

4. Tool design, deployment modes, and evaluation on srsRAN

The RRC-oriented implementation is delivered as a modular toolset consisting of RelayDaemon, Sniffer & Decoder, MutationEngine, ResultMonitor, Neo4j Database, and Dashboard. RelayDaemon is implemented in C++/ZeroMQ and intercepts and forwards messages while hooking mutation calls. Sniffer & Decoder uses Python/pycrate for real-time ASN.1 parsing to map traffic to RRC state IDs. MutationEngine is implemented in Python/C++ and contains the LAL, SyAL, and SoAL policies together with the probability manager. ResultMonitor is written in Go and subscribes to gNB log output or OTA status to label success or failure. Neo4j stores state graphs, probability matrices, and mutation history. The Dashboard is implemented in ReactJS and visualizes state-transition graphs, vulnerability heatmaps, and ROC curves (Yang et al., 2023).

The data pipeline is specified stepwise. RelayDaemon streams raw packets to Sniffer; Sniffer decodes to state ID and appends to case history in Neo4j; MutationEngine queries Neo4j for the next mutation choice and applies it to the relay stream; ResultMonitor writes outcomes to Neo4j and triggers probability update for SyAL or RiskList update for SoAL; the Dashboard charts real-time metrics including “cases per bug,” “average detection time,” precision/recall, and AUC.

The experimental platform is srsRAN v20.12.0 with Tyrannosaur Relay on Linux x86_64. Reported results include the following: LAL discovered 129 RRC-connection anomalies out of 205 fuzz cases, with recall $P \in [0,1]^{N \times N}$5 for these implementation flaws and average detection time 0.072 s. SyAL on downlink found 43 vulnerabilities in 1,027 cases versus 2,811 in random, corresponding to approximately $P \in [0,1]^{N \times N}$6 speed-up, with precision $P \in [0,1]^{N \times N}$7 and recall $P \in [0,1]^{N \times N}$8. SoAL confirmed 3 MITM issues in fewer than 100 bit-level tests. Relative to baselines, LAL used 39% fewer cases to find the first critical bug, SyAL’s case count scaled $P \in [0,1]^{N \times N}$9 versus $P_{i,j}$0 for a linear strategy, and guided SoAL reduced search by more than 80% compared with unguided bit-flip.

The deployment scenarios are broader than a single lab setup. The framework is described for lab use with srsRAN on virtualized USRPs and RelayDaemon over TCP sockets, OTA field tests replacing gNB with Amarisoft CallBox and using SSH logs, CI/CD integration in nightly builds of 5G protocol stacks for regression fuzzing, and an ORAN RIC plugin adaptation in which MutationEngine acts as an xApp with minimal L1 impact. These scenarios indicate that the design was intended to be operationally extensible beyond an isolated prototype.

5. Grammar-guided FivGeeFuzz for 5G Core Service-Based Interfaces

The later FivGeeFuzz is organized around three core ideas: automatically extracting a formal grammar from 3GPP OpenAPI definitions, driving a stateful grammar-guided REST API fuzzer to generate both conformant and malformed inter-NF messages, and automatically detecting crashes, authorization failures, and unexpected behaviors, followed by manual root-cause analysis to classify vulnerabilities (Chen et al., 10 Sep 2025).

Its formal foundation is a context-free grammar

$P_{i,j}$1

constructed from the 3GPP Release-17 OpenAPI v3 specifications for all 48 SBI services covering 10 NFs. The nonterminal set $P_{i,j}$2 includes elements such as Request, Method, Path, QueryParams, HeaderList, Body, Token, JWT_Header, JWT_Payload, and JWT_Signature. The terminal set $P_{i,j}$3 includes HTTP methods, URI fragments, header names, JSON tokens, numeric and string literals, and punctuation symbols. Production rules $P_{i,j}$4 are derived automatically from the specifications. For example, a defined operation such as GET /nudm-sdm/v2/shared-data?supported-features={list} yields a request production with method, path, query parameter, headers, and optional body components. A subgrammar is defined for OAuth2 JWT tokens:

$P_{i,j}$5

with payload fields including iss, sub, aud, [scope](https://www.emergentmind.com/topics/scope), and exp. The start symbol is set to RequestSequence, a nonterminal expressing stateful sequences of requests interleaved with responses.

The implementation builds on Microsoft’s RESTler, but layers the derived grammar on top of the stateful REST API fuzzer so that mutations are constrained to the right fields. The workflow initializes a corpus with minimal valid request sequences for target endpoints, selects seed sequences by feedback, instantiates new requests from the grammar with type-consistent literals, mutates only those grammar terminals marked as fuzzable, sends the resulting sequence to the target, records interesting responses as bugs, and preserves successful 2XX interactions for deeper state exploration. Instantiate(·) fills path parameters, query strings, and JSON bodies using a dictionary of valid values such as SNSSAIs and UE IDs, while Mutate(·) may drop optional fields, insert out-of-range numbers, or corrupt JSON structure.

Automated bug detection operates on full request sequences, timestamps, HTTP response codes, response bodies, and gRPC or service logs from NF containers. Crash detection treats HTTP 500 responses as potential unhandled exceptions and also relies on in-container monitoring such as Docker health checks and log-scan hooks to flag runtime panic, stack trace, or fatal log entries. Unauthorized-access detection checks whether a 2XX response is returned for a request whose requested service lies outside the token’s declared scope:

$P_{i,j}$6

Severity is then assigned by a simple formula loosely based on CVSS: crash $P_{i,j}$7, auth_bypass $P_{i,j}$8, client_error_mapped_wrongly $P_{i,j}$9, else $i$0, with further increase possible from temporal and environmental metrics such as multiple NF crashes in cascade.

6. Vulnerabilities in free5GC, mitigations, and interpretive significance

The SBI-oriented evaluation used hardware with 32 vCPUs, 64 GB RAM, and Ubuntu 22.04 LTS. free5GC v4.0.0 was deployed via Docker Compose with 10 core NFs on a private Docker network, OAuth2 enabled, and MongoDB 4.4 as the UDR store. The 48 OpenAPI specifications were preprocessed into the grammar $i$1, and RESTler v9.3.1 with FivGeeFuzz integration ran for 48 hours, reaching approximately 68% line coverage across the 10 NF codebases as measured by Go coverage tools (Chen et al., 10 Sep 2025).

Eight previously unknown vulnerabilities were reported: seven implementation bugs and the Cross-Service Token Attack. The Cross-Service Token Attack is described as an auth bypass with severity 9.8. Its sequence is: AMF → NRF: AccessTokenGet(requester=AMF, target=UDR, scope=nudr-dr) ⇒ token₁(scope=nudr-dr), followed by Attacker → NRF: nnrf-discovery(requester=UDR, target=[SMF](https://www.emergentmind.com/topics/sequential-matched-filter-smf), scope=nnrf-disc, token=token₁) ⇒ 200 OK, SMF instance list. The root cause is that VerifyOAuth always returns nil when parse succeeds even if scope does not match the requested service.

Vulnerability	Failure mode	Affected component
Cross-Service Token Attack	Unauthorized access to resources	NRF / OAuth scope validation
Omission of supported-features in GET /shared-data	Runtime panic (500)	UDM / Nudm_SDM
Omission of single-nssai in GET /{supi}/sm-data	Runtime panic (500)	UDM / Nudm_SDM
Malformed single-nssai in GET /{supi}/sm-data	Panic instead of 400	UDM / Nudm_SDM
Invalid callback URI in POST /shared-data-subscriptions	Panic (500) rather than 4XX	UDM
Missing expiry in POST /nssai-availability/subscriptions	Nil-pointer panic (500)	NSSF
Unsafe type assertion in POST /bdtpolicies	Panic (500)	PCF
Non-existent ueId in GET /{ueId}/id-translation-result	Returns 500 instead of propagating 404	UDM

Each automatically reported issue was then triaged manually by replaying the minimal sequence on a clean deployment, attaching a debugger to the crashing NF container, tracing back to the Go source file and function, and writing a root-cause summary. All crashes were classified as DoS with CVSS 9.3, the Cross-Service Token issue as ES 9.8, and incorrect status code behavior as 5.5. Within two weeks of disclosure, free5GC maintainers had fixed VerifyOAuth to return a new error on scope failure, added nil checks on optional query parameters before indexing arrays, wrapped JSON unmarshal calls with conditional presence checks to return 400 on malformed input, propagated 404 from UDR rather than mapping to SYSTEM_FAILURE, and added safe type assertions in PCF BDT policy logic.

The recommended countermeasures for 5G SBA are explicit. Strict token validation is formulated as: for every request $i$2 with token $i$3, enforce signature verification, non-expiration, audience matching to target NF type or instance, service membership in token scope, and, when SNSSAIs are defined, non-empty intersection between token SNSSAIs and target NF SNSSAIs. Input validation requires presence checks for optional parameters and 400 on malformed values. Robust error handling requires differentiation of client 4XX from server 5XX and suppression of internal panics. Grammar-based fuzzing in CI is recommended for nightly builds to catch regressions.

A common misconception would be to treat FivGeeFuzz as a single technique restricted either to black-box radio fuzzing or to REST API grammar fuzzing. The literature does not support that reduction. Instead, it documents two frameworks sharing a name but operating at different layers of the 5G system: one centered on RRC state transitions and prior-knowledge-adaptive mutation, the other on formal grammar extraction and stateful SBI fuzzing. This suggests that FivGeeFuzz is best understood as a label for a broader research program in 5G vulnerability discovery rather than as one fixed toolchain or one fixed attacker model.