CVE-2026-37222: FlexRIC E2AP Denial-of-Service Vulnerability – Analysis & Remediation

Technical summary

FlexRIC v2.0.0 uses assertion-based validation for Information Element (IE) counts in decoded E2AP (E2 Application Protocol) messages rather than range-based validation aligned with the E2AP standard. The vulnerability manifests in the near-RT RIC service (port 36421) and iApp service (port 36422), which terminate E2AP connections from RAN nodes. When a remote attacker sends a valid E2AP PDU—such as an E2setupRequest with additional optional IEs within protocol boundaries—the hardcoded assertion fails, triggering SIGABRT and terminating the process. The root cause is a logic error (CWE-617: Reachable Assertion) that enforces exact field counts rather than validating against the permissible ranges defined in the E2AP specification. This creates a mismatch between the implementation's strict assumptions and the protocol's flexibility for optional and extensible elements.

Business impact

A successful attack disrupts the near-real-time RIC, which is critical to radio resource management, interference mitigation, and closed-loop optimization in 5G/6G networks. Repeated denial-of-service attacks force manual service restarts, degrading network performance and availability. RAN nodes dependent on the RIC may fall back to suboptimal configurations or lose intelligent optimization capabilities entirely. In production environments, this translates to reduced network efficiency, potential SLA breaches, and operational overhead for mitigation and recovery.

Affected systems

FlexRIC v2.0.0 is directly vulnerable. The vulnerability is reachable via the E2AP protocol on port 36421 (near-RT RIC) and port 36422 (iApp). Any deployment running this version with network exposure to untrusted sources—including internet-facing RIC instances or insufficiently isolated test environments—is at risk.

Exploitability

Exploitability is straightforward. The attack requires only network access, no authentication, and no user interaction. An attacker can craft a valid E2AP PDU with a non-matching IE count using standard protocol libraries or tools. The low complexity and absence of preconditions make this vulnerability trivial to exploit. No advanced techniques, privilege escalation, or social engineering are needed. The primary barrier is network reachability to the RIC ports; environments with proper network segmentation and access controls reduce but do not eliminate risk.

Remediation

Upgrade FlexRIC to a patched version released after v2.0.0 (verify the exact version number against the vendor advisory). The fix should replace hardcoded assertion-based validation with protocol-compliant range checking that allows valid IE count variations specified in the E2AP standard. Until patching is feasible, implement network-level controls: restrict E2AP traffic to authorized RAN nodes only, deploy perimeter firewalls to block external E2AP connections to ports 36421 and 36422, and monitor connection logs for anomalous message patterns.

Patch guidance

Contact the FlexRIC vendor or check their security advisories for the available patch version(s). Apply patches during a maintenance window to avoid service interruption. Before production deployment, validate the patched version in a test environment to confirm IE count handling aligns with E2AP specifications. Post-patch, monitor RIC logs for any IE count warnings or anomalies to detect residual edge cases.

Detection guidance

Monitor the near-RT RIC and iApp services for unexpected terminations (SIGABRT signals) correlated with E2AP message receipt. Log E2AP PDU parsing errors or warnings indicating IE count mismatches. Implement alerting for crashes on ports 36421 and 36422. Packet analysis tools can inspect E2AP message payloads to identify PDUs with unusual IE counts sent by external sources. Establish baseline traffic profiles for IE counts in normal operations to spot anomalies.

Why prioritize this

This vulnerability merits immediate attention due to its high CVSS score (7.5), the critical role of the RIC in network operations, trivial exploitability, and lack of authentication barriers. In any environment where the RIC is exposed—even accidentally—to untrusted network segments, an attacker can cause repeated outages with minimal effort. The impact on network intelligence and optimization capabilities justifies rapid patching.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects: Network accessibility (AV:N) with no authentication required (PR:N), low attack complexity (AC:L), and unavoidable availability impact (A:H) affecting the entire RIC service. Confidentiality and integrity are not compromised, limiting the score below 8.0, but the denial-of-service impact on a critical network control function is substantial.

Frequently asked questions