CVE-2026-37228
Received Received - Intake
Assertion Failure in FlexRIC v2.0.0 SCTP Message Handling

Publication date: 2026-06-01

Last updated on: 2026-06-01

Assigner: MITRE

Description
FlexRIC v2.0.0 contains a reachable assertion in e2ap_recv_sctp_msg() (src/lib/ep/e2ap_ep.c). The function allocates a fixed 32KB receive buffer and enforces assert(rc < len) on the sctp_recvmsg() return value. A remote unauthenticated attacker can send a single SCTP message with payload >= 32,768 bytes to crash the near-RT RIC, iApp, E2 Agent, or xApp process via SIGABRT. No valid E2AP PDU is required. All four SCTP endpoint types (ports 36421 and 36422) share this vulnerable code path. In Release builds (NDEBUG), the stripped assertion leads to a signed-to-unsigned integer overflow and potential out-of-bounds read.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-01
Last Modified
2026-06-01
Generated
2026-06-02
AI Q&A
2026-06-01
EPSS Evaluated
N/A
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
flexric flexric to 6a595d8b (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.


Can you explain this vulnerability to me?

CVE-2026-37228 is a vulnerability in FlexRIC v2.0.0 involving a reachable assertion in the function e2ap_recv_sctp_msg(). This function allocates a fixed 32 KB receive buffer and asserts that the size of the received SCTP message is smaller than this buffer.

A remote unauthenticated attacker can exploit this by sending a single SCTP message with a payload of 32,768 bytes or more to ports 36421 or 36422. This causes the assertion to fail, triggering a SIGABRT signal that crashes the near-RT RIC, iApp, E2 Agent, or xApp processes.

In release builds where assertions are stripped, the vulnerability can lead to a signed-to-unsigned integer overflow and potential out-of-bounds memory reads, which may cause undefined behavior or further crashes.


How can this vulnerability impact me? :

This vulnerability can cause a denial of service by crashing critical FlexRIC components such as near-RT RIC, iApp, E2 Agent, or xApp processes when exploited.

Since the attacker does not need to be authenticated and no valid E2AP PDU is required, it can be triggered remotely by sending a specially crafted SCTP message to the affected ports.

In release builds, the vulnerability may also lead to memory corruption due to out-of-bounds reads, potentially causing instability or further security issues.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring SCTP traffic on ports 36421 and 36422 for unusually large payloads. Specifically, look for SCTP messages with payload sizes of 32,768 bytes or more, which can trigger the vulnerability.

You can use network packet capture tools such as tcpdump or tshark to filter and identify such large SCTP messages.

  • tcpdump -i <interface> 'sctp and (port 36421 or port 36422) and greater 32768'
  • tshark -i <interface> -Y 'sctp && (sctp.port == 36421 || sctp.port == 36422) && frame.len >= 32768'

Additionally, monitoring application logs for crashes or SIGABRT signals in near-RT RIC, iApp, E2 Agent, or xApp processes can help detect exploitation attempts.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include restricting access to the vulnerable SCTP ports (36421 and 36422) to trusted peers only.

Implement filtering rules on network devices or host firewalls to block SCTP messages with payload sizes equal to or greater than 32,768 bytes.

Monitoring and blocking oversized SCTP messages can prevent triggering the assertion failure or out-of-bounds read.

Since no upstream fix was available at the time of disclosure, these network-level restrictions are critical to reduce risk.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart