Uncovering Threats and Exposing Vulnerabilities in Next-Gen Cellular RAN

Uncovering Threats and Exposing Vulnerabilities in Next-Gen Cellular RAN

Speakers: Tianchang (PhD Student, Penn State University) and Kai (PhD Student, Penn State University)

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=rqzK1xd3wng

Reading time: ~8 minutes

Type: Briefing

TL;DR

Penn State University researchers Tianchang and Kai discovered 26 vulnerabilities — 22 of which received CVE assignments — across leading open-source and commercial Open RAN (O-RAN) implementations, including the O-RAN Software Community reference RIC, SD-RAN, and OpenAirInterface disaggregated RAN nodes. Their end-to-end fuzzing framework, delivered via the standardized E2 interface, enabled a malicious user device or compromised RAN node to crash the Central Unit (CU) or the E2 Termination (E2T) message router — knocking all connected users off the network in demonstrated live attacks.

Introduction

When most people think about cellular network security, they think about the handset. But the infrastructure supporting wireless communication — the Radio Access Network, or RAN — is equally critical and far less scrutinized. The RAN connects user devices to the mobile core network through cell towers and the baseband processing equipment behind them.

Open RAN (O-RAN) is a rapidly evolving shift that disaggregates previously monolithic, proprietary cell hardware into standardized, virtualized software components running on commodity servers. The analogy to software-defined networking in the internet world is direct: just as SDN separated routing logic from hardware in the mid-2010s, O-RAN separates baseband functions from proprietary radio hardware, enabling mix-and-match deployments from multiple vendors. This openness brings significant economic and operational benefits — and, as Tianchang and Kai demonstrated, a dramatically expanded attack surface in infrastructure that underpins national emergency services and communications.

The O-RAN Architecture and Its New Attack Surface

A standard O-RAN deployment disaggregates the traditional base station into three components: the Radio Unit (RU), which handles physical radio transmission; the Distributed Unit (DU), which processes lower-layer protocol functions; and the Central Unit (CU), which handles higher-layer control and user-plane tasks. Atop these sits the RAN Intelligent Controller (RIC), an O-RAN-specific component that optimizes network behavior through standardized interfaces.

▶ Watch: O-RAN Architecture Overview (04:00)

The RIC hosts two types of applications: rApps, which handle latency-tolerant tasks like policy configuration and AI/ML model management, and xApps, which handle real-time functions including device control, scheduling, load balancing, and handover decisions. The RIC communicates with RAN nodes (DU and CU) via the E2 interface, a standardized message-passing channel.

The key security concern stems from this openness. In previous closed-RAN generations, proprietary hardware and software meant the internals were largely inaccessible to outside parties. O-RAN components run as virtualized functions on general-purpose cloud infrastructure, communicate over standardized interfaces, and accept software from third-party xApp developers. This creates multiple paths for an attacker: a user device (UE) can send malformed radio-layer inputs to the RU, which typically forwards them without inspection to the DU/CU; a compromised or malicious RAN node can inject unexpected messages into the RIC via the E2 interface; and supply-chain vulnerabilities in third-party components or xApps can propagate through the system.

26 Vulnerabilities Across Open-Source and Commercial O-RAN

The researchers tested three mature open-source implementations: the O-RAN Software Community (OSC) RIC (considered the official reference implementation), SD-RAN (another O-RAN-compliant RIC), and OpenAirInterface (OAI) disaggregated RAN nodes. They also collaborated with Trend Micro to test a closed-source, commercially provided RIC under NDA.

▶ Watch: Vulnerability Findings Summary (12:00)

Across the open-source targets, they found 19 flaws in the two RIC implementations and 7 flaws in OAI's RAN, resulting in 22 CVE assignments. Vulnerability types included assertion failures, memory safety violations, runtime panics, and logical errors in xApps. The logical errors were particularly insidious: they caused communication channels to become permanently blocked — meaning the affected RAN nodes would never receive messages from a broken xApp — without generating any explicit error message. This stealthy denial-of-service would be difficult to diagnose in a production network.

The memory vulnerabilities arise partly from O-RAN's mixed-language codebases. Many components use Go for memory safety, but call into C/C++ libraries via CGo — and vulnerabilities in those C code paths can still cause memory violations in the Go component, potentially leading to remote code execution if ASLR or stack canaries are absent or misconfigured. The commercial RIC, despite being closed-source and designed around a zero-trust model, yielded four additional vulnerabilities through black-box API testing alone — triggered by overly long requests or malformed inputs, causing denial-of-service and unexpected component behaviors.

The End-to-End Fuzzing Framework

Existing protocol fuzzers like AFLNet test one component at a time and require significant manual harness work to adapt to each implementation's internal message formats. Because O-RAN's internal communication protocols are not standardized, this approach cannot scale across different implementations.

▶ Watch: Fuzzing Methodology (16:00)

The researchers designed an end-to-end approach that tests the entire RIC stack by sending inputs exclusively through the E2 interface — the standardized boundary between RAN nodes and the RIC. Because E2 messages are well-defined by the O-RAN specification, test input generation can be automated and applied identically across different implementations without per-component harness work. Every bug found through this interface is, by definition, exploitable by a misbehaving RAN node.

The framework uses a layered testing strategy. Starting with the E2 Termination (E2T) — the first component reached via E2 — the system collects constraints that cause messages to be accepted rather than discarded, then uses those constraints to generate inputs targeting deeper components like individual xApps. Dynamic tracing during normal operation reveals component dependencies and message routing paths. For static analysis, the team applied program dependency graphs (PDGs) and backward data-flow analysis to extract message validation constraints, focusing only on code paths relevant to message acceptance decisions.

▶ Watch: Static Analysis Heuristics for Function Selection (22:01)

A key insight addressed the challenge of analyzing very large codebases — a single SD-RAN component contains over 500,000 lines of code and more than 6,000 non-test functions. The team observed that validation functions specific to a message type tend to be invoked in narrow contexts (one or two call sites, from a single package), while generic utility functions are invoked broadly across many packages. This simple heuristic let the fuzzer focus static analysis on the functions that actually matter for input validation.

Live Attack Demonstrations

Demo 1 — Malicious User Crashes the CU: An attacker using a software-defined radio (SDR) with a standard SIM card connects to the RAN as a malicious user device. A carefully crafted malformed input traverses the RU (which forwards it without inspection) and reaches the CU. The CU crashes immediately upon processing the payload. Both legitimate phones connected to the cell lose network connectivity, even though the DU and RU continue running — causing the phones to display a false 5G signal while actually receiving no service.

▶ Watch: CU Crash Demo (24:01)

Demo 2 — Malicious RAN Node Crashes the E2T: A compromised RAN node (representing a backdoored base station or a cloud-infrastructure compromise) sends a malicious message to the RIC. The E2T message router — the central hub through which all RAN-to-RIC communication flows — crashes. The benign RAN node, deployed in Kubernetes, continues running but can no longer send or receive any messages from the RIC. Even after Kubernetes restarts the E2T pod, the benign RAN must also be manually restarted to reestablish the connection, extending the outage window.

The second scenario is especially concerning: a single compromised node connected to the same RIC can silently disable optimization and control services for all other nodes it serves.

Notable Quotes

"With this sudden shift to openness in Open RAN — since it is really critical infrastructure for national security, for emergency service distribution, and just as a message distribution system — basically any vulnerability can lead to disastrous outcomes." — Tianchang, 08:00

"5G and Open RAN's aggressive shift to openness means a great number of attack surfaces are opening up, and we believe not nearly enough people are talking about these huge security concerns, considering the attacks this could cause for such a nation-critical infrastructure." — Tianchang, 28:01

"The O-RAN specification concludes that the RIC should not assume that the data received is valid or trusted, and some validation should be enforced to ensure its robustness." — Tianchang, 10:00

"Even in memory-safe languages, we found some Go programs using CGo calls to invoke APIs in C++, and vulnerabilities in those C code can still make this Go component vulnerable to memory violations." — Kai, 14:00

Key Takeaways

• O-RAN's openness creates a fundamentally new attack surface for critical national infrastructure. Inputs from any user device can reach CU/DU processing logic; compromised or malicious RAN nodes can attack the RIC. Neither attack requires physical access to the base station.
• Zero-trust design does not guarantee security. The commercial RIC, explicitly designed around zero-trust principles and closed-source, still yielded denial-of-service vulnerabilities through basic black-box API testing.
• End-to-end fuzzing via the E2 interface is a scalable, implementation-agnostic testing approach. By targeting the standardized boundary rather than internal message formats, the framework found bugs across both open-source and commercial implementations without per-target harness development.
• E2T is a single point of failure. Crashing the E2T message router silences all xApps simultaneously, rendering the entire RIC non-operational even if xApps themselves are healthy. E2T resilience and crash recovery require priority attention in production deployments.
• The O-RAN security community is nascent. All components tested are open-source and Kubernetes-deployable. Security researchers can start contributing now — the O-RAN Software Community published a new RIC release just two weeks before this talk.

Slides

No slides PDF was available for this talk.