AI
O-RAN Disaggregates the Cell Tower
Before 5G, a cell tower was a single proprietary hardware box. Operators had no visibility inside it. O-RAN disaggregates that box into a Radio Unit (RU) and software-based DU and CU nodes running on commodity cloud servers. A RAN Intelligent Controller (RIC) connects to those nodes over a standardized E2 interface and hosts third-party xApps for scheduling and handover decisions.
Major carriers still buy from a single vendor,
“to make sure they have someone to blame” — Tianchang Yang
but private 5G deployments are already running disaggregated stacks. That openness is the point. It is also the problem.
Three Attack Surfaces Created by the Shift to Openness
Closed proprietary hardware had one security property: nobody could interact with its internals. O-RAN removes that. A phone with a SIM card and a software-defined radio can send malformed payloads over the air. The RU forwards them without inspection. A bug in the DU or CU turns one user’s radio into a denial-of-service weapon against every phone on that cell.
Supply chain is the second exposure. RAN vendors pull in libraries, open-source and closed-source, any of which can carry backdoors. A malformed message from one compromised node can crash the E2T router and take the entire RIC offline.
22 CVEs Across Open-Source and Commercial RICs
The team tested two O-RAN-compliant RIC implementations (the O-RAN Software Community reference and SD-RAN) plus OpenAirInterface’s disaggregated RAN nodes. Those targets produced 19 RIC flaws and 7 OAI RAN flaws, earning 22 CVE assignments. Most bugs cause crashes: memory violations in CGo-linked Go code and xApp logic errors that silently block control channels with no error message to the RAN.
In parallel, a commercial RIC tested with Trend Micro under NDA yielded 4 more vulnerabilities via black-box API calls alone, triggered by oversized requests or wrong field types such as a JSON object where a plain string was expected.
End-to-End Fuzzing Through the E2 Interface
Existing fuzzers like AFLNet test one program at a time and need hand-written harnesses for each internal protocol. The team bypassed that by sending all test inputs through the standardized E2 interface. Any bug found is reachable by a real misbehaving RAN node, and the same fuzzer runs against any O-RAN implementation.
Reaching xApps means passing checks from the E2T router first. Dynamic tracing maps message flows through the RIC. Static analysis then extracts field constraints for each component. A call-site heuristic keeps that tractable: functions called from one package are validators. Functions called from many are utilities to skip.
Live Demos: CU Crash and E2T Takedown
Two live demos. In the CU crash via malicious UE over the air (25:54), an attacker-controlled software-defined radio sends one malicious message to the RAN. The CU crashes immediately. Both connected phones lose network service. The DU and RU keep running, so the phones still show signal bars while receiving nothing.
The E2T segfault via rogue RAN node (27:49) shows what happens when an attacker compromises a different RAN node on the same RIC. One unexpected message causes a segmentation fault:
“message causing a segmentation fault.” — Tianchang Yang
The E2T message router crashes. The benign RAN node can no longer send or receive anything. Kubernetes restarts the E2T pod, but the benign RAN must also restart to reestablish its connection.
Notable Quotes
to make sure they have someone to blame Tianchang Yang · ▶ 7:18
we have found 19 Tianchang Yang · ▶ 12:43
message causing a segmentation fault. Tianchang Yang · ▶ 27:59
Key Takeaways
- O-RAN’s open, software-centric design expands the 5G attack surface to anyone with a SIM card or a vendor relationship.
- 22 CVEs found across two open-source RICs and one OAI RAN stack; a closed-source commercial RIC yielded 4 more via black-box testing alone.
- End-to-end fuzzing through the standardized E2 interface reaches deep RIC components without implementation-specific test harnesses.