Telecom networks have quietly become distributed software systems, and the CVEs piling up against them prove it. This open RAN 5G core CVE analysis starts with the most consequential public case study to date: 5Ghoul, a family of implementation flaws in 5G NR modem basebands from Qualcomm and MediaTek, disclosed in December 2023 by the ASSET Research Group at the Singapore University of Technology and Design (SUTD). The bugs let an attacker with nothing more than a software-defined radio configured as a rogue base station crash or stall a target device's 5G connection before authentication ever completes — no SIM, no operator credentials, no user interaction. It is a clean illustration of why disaggregated, software-defined radio and core infrastructure needs the same vulnerability discipline as any other piece of internet-facing software.
Why This Open RAN 5G Core CVE Analysis Matters Now
Open RAN and cloud-native 5G core deployments replace monolithic, vendor-locked baseband and packet-core appliances with modular software running on commodity hardware, connected over open interfaces (O1, A1, E2, Open Fronthaul) defined by the O-RAN ALLIANCE. That disaggregation is the entire point — it lets operators mix vendors and avoid lock-in — but it also multiplies the attack surface. Every interface, every open-source reference stack, and every modem firmware blob is now a discrete piece of software with its own patch cadence, its own maintainers, and its own CVE history. 5Ghoul sits on the radio-access side of that surface; a parallel set of concerns sits inside the 5G core network functions themselves — the AMF, SMF, and UPF — where fuzzing research against open-source implementations has repeatedly turned up crash-inducing malformed-message handling. Together they represent a fairly complete picture of a 5G core network vulnerability class: protocol-parsing code, written to a large and ambiguous 3GPP specification, running at the edge of trust boundaries where an unauthenticated peer gets the first say.
Affected Versions and Components
5Ghoul is not a single bug but a cluster of more than a dozen distinct implementation weaknesses spanning improper input validation and out-of-bounds handling in RRC (Radio Resource Control) and NAS (Non-Access Stratum) message parsing during the pre-authentication phase of a 5G NR session. The affected components are baseband modem firmware, not application code: several generations of Qualcomm Snapdragon 5G modem-RF systems and MediaTek Dimensity 5G basebands used across a wide range of commercial smartphones, fixed-wireless CPE, and cellular IoT modules. SUTD's own testing reported the flaws were reproducible across hundreds of commercial device models, underscoring how a single chipset-level bug propagates across dozens of OEM SKUs that all license the same modem silicon.
Zoom out from the handset side and the same pattern shows up in the core. Open-source 5G core stacks such as Open5GS and free5GC are widely deployed in university test beds, private 5G networks, and O-RAN integration labs precisely because they implement the same 3GPP-defined AMF/SMF/UPF and NAS/GTP-U message handling that commercial cores use. Academic fuzzing efforts targeting these stacks have surfaced crash conditions in NAS and GTP-U message parsing paths — the same class of "trust the wire format" bug that produced 5Ghoul, just on the core-network side of the split rather than the radio side. Separately, the O-RAN Software Community (an O-RAN ALLIANCE and Linux Foundation project) maintains reference implementations of the Near-RT RIC, SMO, and E2 interface that operators and vendors build commercial O-RAN products on top of; any O-RAN security flaw discovered in that reference code has outsized downstream reach for the same reason a chipset bug does — one upstream defect, many derivative deployments.
CVSS, EPSS, and KEV Context
Public advisories from Qualcomm and MediaTek placed most of the individual 5Ghoul CVEs in the high-severity band. That's consistent with how CVSS scoring treats this bug class even though the outcome is denial-of-service rather than code execution: an adjacent-network attack vector, low attack complexity, no privileges required, and no user interaction are exactly the vector-string ingredients that push a score above 7.0 under CVSS 3.1, regardless of whether the payoff is a crashed baseband process or a full compromise.
That said, exploitability in the wild looks different from exploitability on paper. None of the 5Ghoul CVEs we've reviewed carry elevated EPSS scores, and as of this writing none appear on CISA's Known Exploited Vulnerabilities (KEV) catalog. That's not surprising: mass exploitation requires an attacker to build or acquire a rogue gNB and be within radio range of the target, which is a meaningfully higher bar than firing a remote HTTP request at an internet-facing service. It's a useful reminder that CVSS severity and real-world exploitation probability are different signals, and a telecom infrastructure exploit that needs specialized RF equipment and physical proximity will generally sit lower on an EPSS-driven priority list than a remote, unauthenticated web vulnerability — even when both carry a "high" CVSS label. Prioritization frameworks that blend CVSS with EPSS and KEV status matter here as much as they do in any other software estate.
Timeline
- 2019–2021 — The O-RAN ALLIANCE formalizes open interfaces (A1, E2, O1, Open Fronthaul), expanding vendor interoperability and, with it, the number of discrete software components an operator's network now depends on.
- 2022–2023 — Academic and industry research intensifies around 5G protocol-implementation fuzzing, targeting both commercial basebands and open-source 5G core stacks; the U.S. Enduring Security Framework (a partnership between NSA, CISA, and industry) publishes guidance on Open RAN security considerations for federal and critical-infrastructure use.
- Mid-to-late 2023 — SUTD's ASSET Research Group completes responsible disclosure to Qualcomm and MediaTek ahead of public release.
- December 2023 — 5Ghoul is publicly disclosed, with a technical paper, proof-of-concept tooling, and CVE identifiers assigned through the respective chipset vendors' security bulletin processes.
- Following patch cycles — Qualcomm and MediaTek roll fixes into their vendor security bulletins; OEMs incorporate the corrected baseband firmware into subsequent Android security patch levels on their own release timelines, meaning real-world remediation trails the disclosure by months and varies by device maker.
Remediation Steps
- Patch the baseband, not just the OS. Track chipset vendor security bulletins (Qualcomm, MediaTek) alongside the monthly Android Security Bulletin, since the fix for a modem-firmware bug ships as a baseband update bundled into a device OTA, not as an app-layer patch.
- Inventory what you can't see by default. Build and maintain an SBOM that extends into firmware — baseband, RAN unit, and O-RAN component versions — for fleets of phones, CPE, small cells, and cellular IoT modules, so a new advisory can be matched against actual deployed versions instead of guesswork.
- Harden O-RAN interfaces per WG11 guidance. Enforce mutual TLS and OAuth2-based authorization on O1, A1, and E2 interfaces rather than relying on vendor default configurations, and don't assume a fronthaul link is implicitly trusted just because it's "internal."
- Segment RAN from core, and core function from core function. Apply network segmentation and least-privilege access between DU/CU, the Near-RT RIC, and core network functions (AMF, SMF, UPF) so a compromised or crashed component in one domain can't cascade into another.
- Patch open-source 5G core deployments on a real cadence. If you're running Open5GS, free5GC, or O-RAN SC reference components in a lab, private network, or integration environment, subscribe to upstream security advisories and apply updates rather than treating a lab deployment as exempt from patch management.
- Add RF-layer monitoring where it's feasible. Rogue base station and RF-anomaly detection won't stop every implementation bug, but it raises the cost of the physical-proximity attacks that this bug class depends on.
How Safeguard Helps
The throughline in this open RAN 5G core CVE analysis is that telecom infrastructure is now a software supply chain problem: chipset firmware, open-source 5G core stacks, and O-RAN reference implementations all flow into production networks the same way any other third-party dependency does, and they need the same continuous scrutiny. Safeguard helps teams building or operating this infrastructure generate and maintain accurate SBOMs across firmware and software components — not just application dependencies — so that when the next 5Ghoul-style disclosure lands, you can answer "are we affected, and where?" in minutes instead of days.
Beyond inventory, Safeguard continuously correlates your component graph against new CVE disclosures and enriches them with EPSS and CISA KEV status, so your team isn't triaging purely on CVSS severity in isolation — you're prioritizing the handful of vulnerabilities that are both severe and realistically exploitable against your actual deployment. For organizations running open-source 5G core software or integrating O-RAN Software Community components, Safeguard's supply chain monitoring flags upstream advisories against the exact versions in your environment and can gate CI/CD pipelines on policy before a vulnerable component ever reaches a production network function. In an industry moving from closed appliances to open, disaggregated software, that continuous visibility is what turns a chipset vendor's advisory into an actionable, prioritized patch plan rather than a headline you read after the fact.