Fuzzing the Mobile Core: How Malformed 5G/4G Signaling Crashes Production Networks

1. Why the mobile core is a fuzzing goldmine

When most people think of "5G security," they picture air-interface eavesdropping, IMSI catchers, or radio-side jamming. The reality of modern mobile networks is that the most catastrophic failures live deeper in the stack inside the signaling protocols that are critical for the smooth operation of the core network functions.

A 5G core (5GC) is a collection of many network functions, serving different purposes:

• AMF (Access and Mobility Management Function) — the entry point for every UE attaching to the network.
• SMF (Session Management Function) — establishes and manages PDU sessions, which provides data connectivity to users.
• UPF (User Plane Function) — forwards user traffic.
• AUSF / UDM / NRF / PCF / NSSF / … — authentication, subscriber data, service discovery, policy, slicing.

Between them, several signaling protocols carry billions of messages a day:

• NGAP (NG Application Protocol) over SCTP — between gNB and AMF.
• NAS (Non-Access Stratum) — end-to-end UE-to-AMF signaling, carried over RRC on the radio side and transported inside NGAP between the gNB and AMF.
• PFCP — between SMF and UPF.
• HTTP/2 + JSON (SBI) — between core network functions.
• GTP-U — user-plane tunneling on N3/N9.
• GTP-C — mainly EPC/NSA/interworking control-plane tunneling (e.g., N26-based on S10 inter-MME link).

Most of these protocols are ASN.1 based with length-prefixed encodings, optional IEs, conditional fields, and nested sub-containers. SBI is different: HTTP/2 uses binary framing, the application payload is typically JSON/OpenAPI-defined. There are other protocols present, which are non-ASN.1 but still typically binary based, e.g., NAS or PFCP. All of these protocols are highly structured and stateful — exactly the kind of surface that rewards fuzzing with high-impact memory-safety, panic, parser, and state-machine bugs.

2. What fuzzing buys you in a telco stack

Fuzzing is the practice of generating large volumes of malformed, mutated, or generationally-crafted inputs and feeding them to a target while monitoring for crashes, hangs, asserts, panics, or state corruption.

For mobile core software, fuzzing is valuable because:

1. The protocols are highly complex. 3GPP TS 38.413 (NGAP), TS 24.501 (5G NAS), TS 24.301 (LTE NAS), and TS 29.244 (PFCP) collectively define thousands of IEs and hundreds of message types. Manual review will not catch every length-check or optional-IE bug.
2. Implementations trust the wire. Many open-source and commercial stacks were written assuming the peer is completely compliant to the specifications. Real attackers are not.
3. A single panic = large outage. A single panic in an AMF/MME instance can cause a major local or regional control-plane outage, depending on pooling, redundancy, restart behavior, and UE distribution.
4. The blast radius extends past the lab. Open-source projects like Open5GS, Free5GC, OpenAirInterface, and Magma act as reference implementations, integration platforms, and building blocks for labs, private 5G deployments, research networks, and some commercial products.

A stateful, telco-aware fuzzer that can speak SCTP/NGAP/NAS, register a fake UE up through authentication and security mode, and then start mutating individual IEs is one of the most efficient bug-finding tools you can build for this domain.

3. Case study: six AMF panics in Ella Core

Ella Core is a Go-based open-source 5G core. Six remote denial-of-service vulnerabilities were uncovered against its AMF — each is a typical fuzzing find: missing length checks, unchecked optional IEs, mandatory IEs that aren't actually checked for, and trusting attacker-controlled elements to be compliant.

3.1 Unauthenticated AMF DoS via undersized integrity-protected NAS payload (CVE-2026-32319)

Advisory: GHSA-m9pm-w3gv-c68f

In internal/amf/nas/handler.go, the AMF validates only that an incoming NAS payload is at least 2 bytes:

if len(payload) < 2 {
    return nil, fmt.Errorf("nas payload is too short")
}

It then inspects the NAS security header and, for IntegrityProtected NAS, slices at offset 7:

case nas.SecurityHeaderTypeIntegrityProtected:
    p := payload[7:]

There is no length check before that slice. A 2-byte payload such as 7e 01 — wrapped in an InitialUEMessage — produces:

panic: runtime error: slice bounds out of range [7:2]
goroutine 37273 [running]:
github.com/ellanetworks/core/internal/amf/nas.fetchUeContextWithMobileIdentity(...)
        /root/parts/core/build/internal/amf/nas/handler.go:109 +0x16f2

This is pre-authentication, pre-UE-context — anyone able to reach the N2 interface can crash the AMF with two bytes.

3.2 AMF DoS via PathSwitchRequest with empty NR security capability bitstrings (CVE-2026-32320)

Advisory: GHSA-j478-p7vq-3347

In handle_path_switch_request.go, the AMF reads the first byte of NR encryption and integrity capability bitstrings unconditionally:

amfUe.UESecurityCapability.SetEA1_128_5G(
    (uESecurityCapabilities.NRencryptionAlgorithms.Value.Bytes[0] & 0x80) >> 7)
...
amfUe.UESecurityCapability.SetIA3_128_5G(
    (uESecurityCapabilities.NRintegrityProtectionAlgorithms.Value.Bytes[0] & 0x20) >> 5)

If the ASN.1-decoded bitstrings are empty, Bytes[0] panics:

panic: runtime error: index out of range [0] with length 0
goroutine 134 [running]:
github.com/ellanetworks/core/internal/amf/ngap.HandlePathSwitchRequest(...)
        /root/parts/core/build/internal/amf/ngap/handle_path_switch_request.go:121 +0x218f

A crafted PathSwitchRequest with zero-length NR encryption/integrity algorithm bitstrings drops the AMF.

3.3 Registered UE crashes AMF with malformed ULNASTransport NAS-SM (CVE-2026-33283)

Advisory: GHSA-3366-gw57-fcm5

In internal/amf/nas/gmm/handle_ul_nas_transport.go, transport5GSMMessage() allows the RequestType IE to be absent — but later, in the no-SM-context branch, it dereferences it anyway:

switch requestType.GetRequestTypeValue() {

When a registered UE sends a ULNASTransport carrying an NAS SM payload for a PDU session ID with no AMF-side SM context and without a RequestType IE, the AMF panics:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xaa8490]
github.com/free5gc/nas/nasType.(*RequestType).GetRequestTypeValue(...)
github.com/ellanetworks/core/internal/amf/nas/gmm.transport5GSMMessage(...)
        /root/parts/core/build/internal/amf/nas/gmm/handle_ul_nas_transport.go:191 +0xe30

In the reproduced path, this requires only a successfully registered UE — exactly the threat model of a malicious subscriber, a stolen SIM, or a compromised IoT device.

3.4 gNB-triggered AMF DoS via malformed LocationReport (CVE-2026-33282)

Advisory: GHSA-826q-wrq4-p23x

handle_location_report.go parses UEPresenceInAreaOfInterestList as optional and only logs a warning if it's missing — but later iterates over .List unconditionally when the event type is ue-presence-in-area-of-interest:

panic: runtime error: invalid memory address or nil pointer dereference
github.com/ellanetworks/core/internal/amf/ngap.HandleLocationReport(...)
        /root/parts/core/build/internal/amf/ngap/handle_location_report.go:87 +0x764

Any rogue or compromised gNB on the N2 interface can drop the AMF with one crafted LocationReport.

3.5 UE-triggered AMF denial of service through invalid PDU Session state (CVE-2026-33281)

Advisory: GHSA-q669-4gmv-g8mf

The AMF stores UE-supplied PduSessionID2Value (a uint8) into ue.SmContextList without range-checking it against the valid NAS PSI window. Later, in handle_service_request.go, it uses each stored PDU session ID to index a fixed [16]bool array (uplinkDataPsi, reactivationResult, psiArray, acceptPduSessionPsi):

panic: runtime error: index out of range [255] with length 16
github.com/ellanetworks/core/internal/amf/nas/gmm.handleServiceRequest(...)
        /root/parts/core/build/internal/amf/nas/gmm/handle_service_request.go:235 +0x21f8

A registered UE creates state with PSI=255, then sends a data ServiceRequest carrying UplinkDataStatus — and the AMF terminates.

3.6 AMF crash via NGReset missing the mandatory ResetType IE

Issue: ellanetworks/core#1059

3GPP TS 38.413 §8.7.4 and §9.4.4 mandate that every NGReset message carry a ResetType IE — it is what tells the AMF whether to reset all UE associations on the interface or only a specified subset. The Ella Core AMF doesn't enforce this. After a normal NGSetupRequest, a connected gNB can send a 13-byte NGReset PDU containing only the optional id-Cause IE (advertising, e.g., radioNetwork: successful-handover) and skip ResetType entirely:

NGAP-PDU: initiatingMessage
    procedureCode: id-NGReset (20)
    criticality: reject (0)
    NGReset
        protocolIEs: 1 item
            Item 0: id-Cause (15) → radioNetwork: successful-handover (2)

handle_ng_reset.go then dereferences the missing ResetType field without a nil check:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xaf72e0]
goroutine 325 [running]:
github.com/ellanetworks/core/internal/amf/ngap.HandleNGReset(...)
        /root/parts/core/build/internal/amf/ngap/handle_ng_reset.go:47 +0x2a0
github.com/ellanetworks/core/internal/amf/ngap.dispatchNgapMsg(...)
        /root/parts/core/build/internal/amf/ngap/dispatcher.go:116 +0x21c

The correct behavior, per 3GPP, would be to reject the PDU with a transfer-syntax-error cause indicating the missing mandatory IE. Instead, the AMF dies — and with it, every UE attached through any gNB it serves.

This is the same style of bug as 3.1 and 3.4, just on a different message type. The recurring lesson: mandatory IEs in 3GPP specs are mandatory to the spec, not to attackers. Every NGAP handler needs to validate presence of mandatory IEs before touching them, with no exceptions.

Pattern summary

Across these six Ella Core findings, every bug is a variation of one theme: the AMF treats a protocol input as if a well-behaved peer produced it. No bounds check before a slice, no nil check before a dereference, no validation on an attacker-controlled identifier, no enforcement of mandatory IEs. Stateful protocol fuzzing surfaces all of them, manual code review historically does not.

4. Case study: Open5GS SMF crash via malformed EPCO

Open5GS is one of the most widely deployed open-source 5G/EPC stacks. It is a reference, a development platform, and through forks and integrations a building block in numerous commercial products.

Issue: open5gs/open5gs#4341 Version: v2.7.6 Component: open5gs-smfd

The SMF crashes when parsing a malformed Extended Protocol Configuration Options (EPCO) IE inside a PDU Session Establishment Request. In lib/proto/types.c, ogs_pco_parse() walks PCO items with a running offset and asserts:

ogs_assert(size + sizeof(id->len) <= data_len);

When the outer PCO length is inconsistent with the inner items (truncated, malformed, off-by-one), the assert raises instead of returning a decode error:

03/03 14:46:09.930: [core] FATAL: ogs_pco_parse:
    Assertion `size + sizeof(id->len) <= data_len' failed.
    (../lib/proto/types.c:473)
03/03 14:46:09.932: [core] FATAL: backtrace() returned 13 addresses
/usr/lib/x86_64-linux-gnu/libogsproto.so.2(ogs_pco_parse+0x14b) [0x7d7dfe72bf9b]
/usr/bin/open5gs-smfd(+0x1a493) [0x5b6624c75493]
/usr/bin/open5gs-smfd(+0x55645) [0x5b6624cb0645]
/usr/bin/open5gs-smfd(+0x29a5a) [0x5b6624c84a5a]
/usr/lib/x86_64-linux-gnu/libogscore.so.2(ogs_fsm_dispatch+0x25) [0x7d7dfe710fd5]
/usr/lib/x86_64-linux-gnu/libogscore.so.2(ogs_fsm_dispatch+0x25) [0x7d7dfe710fd5]
/usr/bin/open5gs-smfd(+0x1c838) [0x5b6624c77838]
/usr/lib/x86_64-linux-gnu/libogscore.so.2(ogs_fsm_dispatch+0x25) [0x7d7dfe710fd5]
/usr/bin/open5gs-smfd(+0x11b1b) [0x5b6624c6cb1b]
/usr/lib/x86_64-linux-gnu/libogscore.so.2(+0xa1b5) [0x7d7dfe7021b5]
/usr/lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7d7dfd694ac3]
/usr/lib/x86_64-linux-gnu/libc.so.6(+0x1268d0) [0x7d7dfd7268d0]
Open5GS daemon v2.7.6

The assert() triggers abort(). The SMF process dies. PDU session establishment and SMF-controlled session management for that SMF instance are disrupted until the daemon is restarted or recovered. Existing sessions may also be affected depending on watchdog behavior, PFCP state recovery, and deployment architecture.

The architectural lesson is: A single malformed message from a rogue UE can traverse the network and crash a network function that is not directly exposed. Even components that appear to be low-risk can, in one way or another, trigger an outage.

5. Fuzzing doesn't stop at 5G — 4G/LTE is still in production

Most of the world's mobile traffic still touches 4G/LTE somewhere. The protocols there (S1AP, NAS/EMM/ESM, Diameter, GTP) are older, more deployed, and just as fuzzable.

Issue: open5gs/open5gs#4357 Version: v2.7.6 Component: open5gs-mmed

A stateful S1AP/NAS sequence crashes the MME. The trigger is an EPS Attach Request whose EPS Mobile Identity (IMSI) IE has a flipped odd/even flag — the first octet of the encoded mobile identity is 0x91 instead of 0x99, while the IMSI digit payload remains 15 digits.

Open5GS doesn't reject this cleanly. Instead, the malformed Attach participates in a release-and-re-attach sequence, and the MME later treats the UE as a known IMSI. When the next Attach Request arrives, the MME reaches mme_state_operational() with an invalid or unset EMM FSM state and aborts on NAS message type 65:

03/12 13:24:29.958: [mme] INFO: [999700000000001] known UE by IMSI
03/12 13:24:29.958: [mme] FATAL: MESSAGE[65] (../src/mme/mme-sm.c:335)
03/12 13:24:29.958: [mme] FATAL: ENB_UE_S1AP_ID[2] MME_UE_S1AP_ID[3]
03/12 13:24:29.958: [mme] FATAL: context [0x5817b3da3330:0x7f0e02f4b7e0]
03/12 13:24:29.958: [mme] FATAL: IMSI [99970000000000]
03/12 13:24:29.958: [mme] FATAL: mme_state_operational: should not be reached.
03/12 13:24:29.958: [core] FATAL: backtrace() returned 7 addresses
/usr/bin/open5gs-mmed(+0x5c179) [0x5817ab48b179]
/usr/lib/x86_64-linux-gnu/libogscore.so.2(ogs_fsm_dispatch+0x25) [0x7f0e04223fd5]
/usr/bin/open5gs-mmed(+0x9893) [0x5817ab438893]
/usr/lib/x86_64-linux-gnu/libogscore.so.2(+0xa1b5) [0x7f0e042151b5]
/usr/lib/x86_64-linux-gnu/libc.so.6(+0x94ac3) [0x7f0e03a94ac3]
/usr/lib/x86_64-linux-gnu/libc.so.6(+0x1268d0) [0x7f0e03b268d0]
Open5GS daemon v2.7.6

This is a stateful bug. A pure stateless mutation fuzzer would never find it , you have to drive the MME through a full Attach, take down the UE context, and then re-attach with a tweaked identity. Modern protocol fuzzers that maintain telco state machines and replay-with-mutation strategies find these reliably.

6. From open source to production: why this matters beyond GitHub

It is easy to dismiss these findings as “just open-source bugs.” That is the wrong lesson.

Open-source 5G and 4G cores are not isolated lab toys. They are used as reference implementations, integration platforms, research cores, private-network building blocks, and test environments for vendors, operators, universities, enterprises, and security teams. Even when the exact code is not reused in a commercial product, the same protocol surfaces exist everywhere: the same NGAP procedures, the same NAS messages, the same PFCP IEs, the same PCO/EPCO containers, the same optional fields, and the same state-machine transitions.

That is why these bugs matter beyond the individual GitHub repositories.

A crash in Ella Core or Open5GS does not automatically mean that a commercial AMF, SMF, or MME has the same vulnerability. But it is strong evidence that the bug class is realistic:

• missing length checks before parsing attacker-controlled buffers;
• missing nil checks for optional or mandatory-but-absent IEs;
• trusting values decoded from the wire as valid indexes or identifiers;
• treating malformed NAS/NGAP/S1AP/PFCP input as impossible;
• using assertions in production decode paths instead of returning clean protocol errors;
• failing to model invalid but syntactically accepted state transitions.

Commercial cores implement the same 3GPP specifications under the same operational pressure. They must parse the same complex, nested, length-prefixed, optional-field-heavy messages. The implementation language may differ, and the codebase may be proprietary, but the parser and state-machine risks remain the same.

This is especially important in mobile networks because exposure is indirect. A vulnerable function does not need to be Internet-facing to be reachable by malformed input. A rogue or compromised gNB can reach the AMF over N2. A malicious or compromised UE can send NAS messages that traverse the gNB and AMF before reaching deeper functions such as the SMF. A malformed EPCO field can originate from the UE and only crash the SMF because no upstream component parses it deeply enough to reject it.

In other words, the absence of direct exposure is not the same as the absence of attack surface.

The practical lesson for operators and vendors is simple: open-source findings should be treated as early warning signals. They show where the protocol grammar is fragile, where implementations tend to trust peers too much, and where stateful fuzzing is likely to produce high-impact results in commercial-grade deployments.

Proprietary does not mean fuzz-tested. It usually means less visibility. The only reliable way to know whether a mobile core handles malformed signaling safely is to test it with stateful, protocol-aware fuzzing under realistic network conditions.

7. P1 Security: wide-spectrum fuzzing across the mobile stack

This is where P1 Security's tooling earns its keep. P1 has been doing protocol-level security on mobile networks since the SS7 era, and the current generation of P1 fuzzing capability covers:

• Stateful NGAP / N2 fuzzing against AMF — full SCTP transport, NG Setup, multi-UE driving, IE-level mutation, and crash detection. Every Ella Core advisory above is exactly the type of bug this surfaces.
• NAS fuzzing (5G and 4G) — driving registration, authentication, security-mode setup, and PDU session establishment, then mutating individual IEs (IMSI encoding, security header type, RequestType, PDU Session ID, PCO/EPCO) at each step. The Open5GS MME crash is a direct example of a stateful NAS bug only this kind of fuzzer finds.
• PFCP / N4 fuzzing between SMF and UPF — Session Establishment / Modification / Deletion mutation against the control interface that programs user-plane forwarding behavior.
• SBI fuzzing — HTTP/2 + JSON service-based interfaces between AMF/SMF/AUSF/UDM/NRF, where schema-aware fuzzing finds JSON, OpenAPI, and TLS issues that traditional binary protocol fuzzing misses.
• GTP-C / GTP-U fuzzing for the EPC and the user plane in 5G NSA deployments.
• Diameter and S1AP fuzzing for the 4G control plane that is still present and widely deployed.
• Air-interface adjacent fuzzing — RRC/PDCP/RLC where lab access permits, including via SDR-fronted base stations.

Two properties matter more than the protocol coverage list:

1. State awareness. The MME crash in Section 5 only happens after a release and re-attach. The Ella Core ULNASTransport crash only happens after the UE has authenticated and completed SMC. Fuzzing that doesn't model the state machine misses the entire class.
2. Production-grade target support. P1's tooling drives commercial AMF/MME/SMF appliances, vendor cores, and packet-core software in lab and pre-production environments not just open-source reference stacks. Issues uncovered in Ella Core or Open5GS are often just early indicators of similar flaws present in production network deployments.

8. Recommendations

For anyone running a 5G or 4G core — public, private, MVNO, enterprise, or research:

• Assume your core is fuzzable. If it has not been stress-tested with a stateful 3GPP-aware fuzzer, assume latent parser and state-machine bugs remain.
• Treat the N2 interface as untrusted. The recurring assumption in advisories like the Ella Core LocationReport crash is "the gNB is well-behaved." Compromised or rogue base stations are a real threat model.
• Treat authenticated UEs as untrusted. Several of the bugs above need only a registered subscriber. SIMs get stolen, IoT devices get compromised.
• Engage with fuzzing professionally. Whether internally or via a vendor, the cost-to-impact ratio of mobile core fuzzing is among the best in the security business.

9. Closing

Every vulnerability in this post follows the same pattern: a complex signaling protocol, insufficient validation of malformed or unexpected fields, and a small crafted input carried inside an otherwise normal signaling flow. The protocols are not going to get smaller. The implementations are not going to get simpler. The deployment surface public 5G, private 5G, satellite, defense, industrial is only growing.

The good news is that the same fuzzing techniques that found these specific bugs find the next thousand. The bad news, for anyone who hasn't started, is that someone else already has.

References

• Ella Core advisories and issues:
  • GHSA-m9pm-w3gv-c68f — Unauthenticated AMF DoS via undersized integrity-protected NAS payload
  • GHSA-j478-p7vq-3347 — AMF DoS via PathSwitchRequest empty bitstrings
  • GHSA-3366-gw57-fcm5 — Authenticated UE crashes AMF with ULNASTransport
  • GHSA-826q-wrq4-p23x — gNB-triggered AMF DoS via LocationReport
  • GHSA-q669-4gmv-g8mf — Panic on invalid PDU Session IDs in NGAP messages
  • ellanetworks/core#1059 — AMF crash on NGReset missing mandatory ResetType IE
• Open5GS issues:
  • #4341 — SMF crash on malformed EPCO
  • #4357 — MME crash on malformed S1AP/NAS Attach Request
• 3GPP TS 38.413 (NGAP), TS 24.501 (5G NAS), TS 24.301 (LTE NAS), TS 29.244 (PFCP), TS 36.413 (S1AP)