What is the CVSS score of CVE-2026-37231?

CVE-2026-37231 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.1%.

Which versions of FlexRIC are affected by CVE-2026-37231?

FlexRIC v2.0.0 is vulnerable to unauthenticated remote denial-of-service affecting the iApp component (TCP/36422), where attackers can crash the RAN Intelligent Controller service by exhausting the…

How to fix or mitigate CVE-2026-37231?

Within 24 hours: Identify all FlexRIC v2.0.0 deployments and document network exposure of TCP/36422; establish baseline monitoring of E42_SETUP_REQUEST message patterns. Within 7 days: Implement network-level access controls restricting TCP/36422 to authorized RIC nodes; configure rate-limiting on E42_SETUP_REQUEST floods where technically feasible; escalate patch status inquiry to FlexRIC vendor with business impact statement. Within 30 days: Monitor vendor advisories for patch availability; test any released patch in non-production RIC environment; prepare upgrade runbook and execute within 48 hours of vendor patch confirmation.

FlexRIC CVE-2026-37231

HIGH

Integer Underflow (CWE-191)

2026-06-01 mitre

Denial Of Service Integer Overflow N A

7.5

CVSS 3.1 · Vendor: mitre

Severity by source

Vendor (mitre) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Primary rating from Vendor (mitre) · only source for this CVE.

CVSS VectorVendor: mitre

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 02, 2026 - 14:23 vuln.today

CVSS changed

Jun 02, 2026 - 14:22 NVD

7.5 (HIGH)

CVE Published

Jun 01, 2026 - 00:00 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

FlexRIC v2.0.0 uses a uint16_t counter for xapp_id assignment but stores the value in uint32_t message fields. After 65,530+ E42_SETUP_REQUESTs, the 16-bit counter wraps around and produces duplicate xapp_ids. The iApp (port 36422) crashes when attempting to register a duplicate ID in its internal data structure. A remote attacker can trigger this by repeatedly connecting and requesting new xApp registrations.

AnalysisAI

Remote denial-of-service in FlexRIC v2.0.0 allows unauthenticated attackers to crash the iApp component (TCP/36422) by exhausting a 16-bit xapp_id counter through repeated E42_SETUP_REQUEST messages. The integer wraparound produces duplicate xApp identifiers that violate internal data-structure invariants, terminating the RIC service. No public exploit identified at time of analysis, and EPSS estimates exploitation probability at just 0.05%, though the attack is conceptually trivial to script.

Technical ContextAI

FlexRIC is the Mosaic5G/EURECOM open-source implementation of an O-RAN Near-Real-Time RAN Intelligent Controller (Near-RT RIC), which manages xApps that consume E2/E42 service-model interfaces over the iApp endpoint on port 36422. The flaw is a textbook CWE-191 (Integer Underflow/Wraparound) variant where xapp_id is allocated from a uint16_t counter (max 65,535) but propagated into uint32_t protocol fields, hiding the truncation at the API boundary. Once the counter rolls over after roughly 65,530 registrations, the iApp's internal map rejects the duplicate insertion and the process aborts, taking the RIC offline.

RemediationAI

No vendor-released patch identified at time of analysis - the upstream Mosaic5G GitLab repository and the third-party advisory at https://github.com/MinamiKotor1/oran-security-advisories-zhongnan-luo/blob/main/advisories/CVE-2026-37231.md should be monitored for a fixed release that widens the xapp_id allocator to uint32_t (or adds collision handling) consistent with the wire format. Until a patch ships, restrict TCP/36422 (iApp) to the trusted O-RAN management VLAN via host or perimeter firewall rules so untrusted hosts cannot initiate E42_SETUP_REQUEST sessions, accepting the trade-off that legitimate xApps must originate from the allowlisted subnet. As a secondary control, rate-limit new connections to port 36422 (for example via iptables hashlimit) to make the ~65k-request exhaustion economically slow and observable, recognizing this only delays rather than prevents the wraparound, and schedule periodic iApp restarts to reset the counter in long-running deployments.