Uncovering Threats and Exposing Vulnerabilities in Next-Gen Cellular RAN
Tianchang YangKai TuSyed Md Mukit RashidAli RanjbarGang TanSyed Rafiul Hussain
5G Radio Access Networks (RANs) are undergoing a major shift from tightly integrated, vendor-specific systems to disaggregated, software-driven architectures.
Summary
## Overview
The presentation explores the emerging security landscape of Open Radio Access Networks (Open RAN / O-RAN) in 5G and next-generation mobile infrastructure. Moving from traditional, proprietary, monolithic cellular base stations toward open, virtualized, and modular architectures mirrors the historical shift seen in software-defined networking (SDN). In O-RAN, the monolithic RAN is disaggregated into distinct components: - **Radio Unit (RU)**: Handles physical layer radio functions. - **Distributed Unit (DU)** and **Central Unit (CU)**: Execute higher-level protocol, control, and user-plane tasks on general-purpose servers or cloud infrastructure. - **RAN Intelligent Controller (RIC)**: Standardizes network optimization via the **E2 interface**, hosting near-real-time **xApps** (latency-sensitive controls such as scheduling, handover, and load balancing) and non-real-time **rApps** (latency-insensitive policies and AI/ML model management). Within the RIC, the **E2 Termination (E2T)** serves as the primary endpoint and message router for all communications with RAN nodes.
## O-RAN Threat Landscape & Attack Vectors
While virtualization introduces flexibility and prevents vendor lock-in, disaggregation introduces several key attack surfaces:
1. **Malicious User Input over the Air**: Attackers using software-defined radios (SDRs) and valid SIM cards can transmit malformed or unexpected payloads over the air interface. Because RUs typically forward raw traffic without inspection, these payloads reach the DU and CU, where protocol parser bugs can trigger crashes and localized Denial-of-Service (DoS). 2. **Heterogeneous Supply Chain & Cascading Failures**: Multi-vendor deployments necessitate a zero-trust architecture. If an input crashes a shared component like the E2T router, communication between all RAN nodes and xApps is severed, rendering the entire RIC non-operational. 3. **Cloud and Virtualization Flaws**: Co-locating O-RAN functions inside virtual machines (VMs) or containers exposes the system to hypervisor escapes and lateral movement across the control plane.
## Vulnerability Findings & Empirical Evaluation
The speakers tested three prominent open-source O-RAN implementations: - **O-RAN Software Community (OSC) RIC**: The official reference implementation. - **SD-RAN (ONF)**: Another O-RAN-compliant open-source RIC. - **OpenAirInterface (OAI)**: Disaggregated RAN nodes (CU/DU).
### Key Results - **26 Flaws Identified**: The team uncovered 19 flaws across the RIC platforms and xApps, plus 7 flaws in OAI's RAN components. - **22 CVEs Assigned**: Resulting in 22 distinct CVE identifiers tracking these issues. - **Failure Categories**: - *Assertion failures, memory safety issues, and runtime panics*: Directly crashed CU, DU, RIC platform services, or xApps. - *Logical errors in xApps*: Silently blocked communication channels, causing silent DoS where RAN nodes stopped receiving control messages without explicit error alerts. - *Encoder/Decoder dependency bugs*: Parser and codec libraries (both in-house and third-party) handling complex ASN.1 and E2 serialization suffered from unhandled edge cases. - *Cross-Language Memory Violations*: Even when using memory-safe languages like Go, implementations used `cgo` bindings to invoke C/C++ APIs, reintroducing memory violation and remote code execution (RCE) risks if defenses such as ASLR or stack canaries are absent.
### Commercial RIC Assessment In collaboration with Trend Micro, the researchers conducted black-box API testing against an NDA-protected commercial, closed-source O-RAN RIC built with a zero-trust model. Even without source code access, simple black-box testing with oversized inputs and malformed formats (e.g., passing a JSON payload where a string was expected) uncovered **4 implementation-level vulnerabilities** capable of triggering DoS and erratic component behaviors.
## Testing Insights & Methodology Takeaways
Standard protocol testing tools such as `AFLNet` are limited because they typically target only one isolated process at a time. In contrast, O-RAN architectures rely on multi-stage, distributed microservices communicating over standardized E2 interfaces and unstandardized internal messaging mechanisms (such as gRPC). The speakers highlighted the necessity of end-to-end, multi-component testing methodologies that can propagate malformed payloads across intermediate handlers (like the E2T router) to thoroughly evaluate the robustness of downstream xApps and disaggregated RAN nodes.
Related talks
Briefings·36 min
Fikret Garipay
Post-quantum cryptographic (PQC) algorithms are being integrated into firmware, bootloaders, and other embedded systems as a replacement for RSA and ECC.
Briefings·24 min
Qinrun Dai · Yifei Xie
Vulnerability discovery traditionally relies on two primary approaches: manual auditing and fuzzing.
Briefings·33 min
Ibrahim El-sayed
Explores the security foundations of Signal, one of the commonly used end-to-end encrypted (E2EE) messaging applications.


