CVE-2026-37223: FlexRIC E2AP Dispatcher Assertion DoS – High-Severity O-RAN Vulnerability
FlexRIC v2.0.0 has a flaw in how it handles incoming E2AP messages from radio access network controllers. The software uses an assertion check that crashes the entire process if it receives a message type it doesn't recognize. Because the iApp component and the near-RT RIC service run in the same process, crashing iApp takes down the entire RIC service, severing all connections to E2 Nodes and xApps. An attacker on the network can exploit this without authentication by sending a valid but unlisted E2AP message, causing immediate denial of service.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 7.5 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Weaknesses (CWE)
- CWE-617
- Affected products
- 0 configuration(s)
- Published / Modified
- 2026-06-01 / 2026-06-17
NVD description (verbatim)
FlexRIC v2.0.0 contains a reachable assertion in the iApp message dispatcher. The dispatcher validates incoming E2AP messages against a 9-entry whitelist using assert(). A remote unauthenticated attacker can send any decodable E2AP PDU with a message type not in the whitelist to crash the iApp process (port 36422) via SIGABRT. Since iApp and the near-RT RIC share one process, this terminates the entire RIC service and disconnects all E2 Nodes and xApps.
2 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-37223 is a reachable assertion vulnerability (CWE-617) in the E2AP message dispatcher of FlexRIC v2.0.0. The dispatcher validates incoming Protocol Data Units (PDUs) against a hardcoded 9-entry whitelist using assert() statements. When an unauthenticated remote attacker sends any decodable E2AP PDU with a message_type field not present in the whitelist, the assertion fails, triggering SIGABRT and terminating the dispatcher process. Since iApp and the near-RT RIC share a single process space, this crash propagates to the RIC service layer, forcing disconnection of all attached E2 Nodes and xApps and disrupting O-RAN operations.
Business impact
RIC service outages disrupt O-RAN deployments and affect network operations at scale. A single remote packet can force complete service restart, losing transient state and causing E2 node reconnection storms. For operators relying on xApps for dynamic resource allocation, coverage optimization, or network slicing, this becomes a single-point-of-failure vector. Recovery requires manual process restart and E2 node re-registration, introducing operational overhead and potential SLA violations.
Affected systems
FlexRIC v2.0.0 is affected. Verify with the vendor whether later versions or patches have been released. FlexRIC is an open-source near-real-time RAN Intelligent Controller used in O-RAN deployments.
Exploitability
Exploitability is high. The attack requires network reachability to port 36422 (iApp), no authentication, and only the ability to send a valid but unlisted E2AP message. Any host with network path to the RIC can trigger the crash. The barrier to exploitation is minimal: constructing a well-formed E2AP PDU with an out-of-whitelist message type. No special tools or sophisticated techniques are required.
Remediation
Update FlexRIC to a patched version that replaces assertion-based validation with exception handling or logging that allows the dispatcher to safely reject invalid message types without crashing. Contact the FlexRIC project maintainers for available patches. Until patching is possible, implement network segmentation to restrict access to port 36422 to trusted RIC management and E2 node subnets only.
Patch guidance
Check the FlexRIC project repository and vendor advisory for available patches addressing CWE-617 in the E2AP dispatcher. Patches should replace assert() calls with proper error handling that logs the rejection and continues operation. Apply patches to all near-RT RIC instances in your deployment. Verify patch completeness by confirming the whitelist validation logic no longer uses assertions. Test patched systems in a non-production environment before production rollout.
Detection guidance
Monitor RIC process crashes and SIGABRT signals targeting port 36422. Log E2AP message validation failures and rejected message types. Implement network IDS/IPS signatures to detect decodable E2AP messages with unexpected message_type values sent to the RIC. Correlate sudden RIC service restarts with E2 node disconnection events. Baseline normal E2AP traffic patterns and alert on anomalies that precede RIC outages.
Why prioritize this
HIGH severity (CVSS 7.5) combined with zero authentication requirement, network accessibility, and immediate impact on critical RAN infrastructure makes this a priority-1 remediation target. RIC availability is fundamental to O-RAN operations; a trivial remote crash vector poses unacceptable operational risk.
Risk score, explained
CVSS 3.1 score of 7.5 reflects high network attack vector (AV:N), low complexity (AC:L), no privilege requirement (PR:N), no user interaction (UI:N), and high availability impact (A:H). The scope is unchanged (S:U) and there is no confidentiality or integrity impact. The score appropriately captures the ease of exploitation and severity of denial-of-service consequence, but does not account for widespread O-RAN adoption or potential for coordinated attacks across multiple RIC instances.
Frequently asked questions
Does this vulnerability require the attacker to be an authenticated E2 Node or xApp?
No. The vulnerability is reachable by any unauthenticated remote host with network access to port 36422. The E2AP message dispatcher does not perform authentication before validation, so the crash can be triggered without credentials.
Will a patched RIC version continue to operate if it receives an unrecognized E2AP message type?
Yes. A proper patch replaces assertion-based validation with exception handling or explicit rejection logic. The RIC should log the invalid message and continue running, only rejecting the offending PDU. This prevents process termination.
If the RIC crashes, can E2 Nodes and xApps reconnect automatically?
E2 Nodes and xApps can attempt reconnection, but they must re-register with the recovered RIC service. This causes operational delay and transient loss of dynamic RAN intelligence until reconnection completes. Frequent crashes can destabilize the network.
Is patching the only mitigation available?
Patching is the primary fix. Until patches are deployed, network segmentation is essential: restrict access to port 36422 to trusted RIC management subnets and authorized E2 node sources only. This reduces the attack surface significantly but does not eliminate risk from insiders or compromised E2 nodes.
This analysis is based on the CVE record published on 2026-06-01 and modified on 2026-06-17. Patch availability and vendor advisories should be verified directly with FlexRIC project maintainers. CVSS score interpretation is provided for context; organizations should conduct their own risk assessment based on deployment topology and business criticality. No proof-of-concept code is provided. Testing and patching should be performed in controlled environments before production deployment. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).
Weaknesses (CWE)
Related vulnerabilities
- CVE-2026-37220HIGHFlexRIC v2.0.0 Denial of Service via SCTP Assertion Failure
- CVE-2026-37221HIGHFlexRIC v2.0.0 Unauthenticated Denial-of-Service via RIC Message Crash
- CVE-2026-37222HIGHFlexRIC E2AP Denial-of-Service Vulnerability – Analysis & Remediation
- CVE-2026-37224HIGHFlexRIC v2.0.0 Denial of Service Vulnerability (CVE-2026-37224) — E2_SETUP_REQUEST Crash
- CVE-2026-37225HIGHFlexRIC v2.0.0 Remote Denial of Service
- CVE-2026-37227HIGHFlexRIC v2.0.0 Near-RT RIC Denial of Service (CWE-617)
- CVE-2026-37228HIGHFlexRIC v2.0.0 Remote Denial-of-Service via SCTP Buffer Overflow
- CVE-2026-37229HIGHFlexRIC v2.0.0 Remote Denial of Service via Malformed SCTP