Skip to main content
CVE-2024-34045VulnerabilityPublished Updated

CVE-2024-34045: n/a

Source CVE Database V5

0

Not known to be exploited · CVSS 7.5 High.

Data as of 26 Oct 2026, 07:57 UTC

CVSS 3.1 base score
7.5High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.5% chance of exploitation in 30 days – higher than 43% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 29 Apr 2024

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-26.

What to do

AI-suggested

To mitigate CVE-2024-34045, organizations should implement the following specific measures: 1) Immediately monitor O-RAN E2T I-Release instances for abnormal crashes or SCTP thread failures, focusing on Prometheus metric increments related to E2 setup procedures. 2) Employ network-level protections such as rate limiting and traffic filtering to restrict potentially malicious or malformed SCTP messages that could trigger the vulnerability. 3) Isolate critical O-RAN components within segmented network zones to limit exposure to untrusted networks. 4) Engage with O-RAN software vendors and community to obtain patches or updates as soon as they become available, and prioritize timely deployment. 5) Consider implementing application-layer watchdogs or process supervisors that can automatically restart crashed components to minimize downtime. 6) Conduct thorough testing of O-RAN E2T deployments in controlled environments to identify and address any stability issues related to metric handling. 7) Maintain up-to-date incident response plans tailored to telecom infrastructure to quickly respond to potential denial-of-service incidents. These targeted actions go beyond generic advice by focusing on the specific metric increment function and SCTP thread behavior implicated in this vulnerability.

Description

The O-RAN E2T I-Release Prometheus metric Increment function can crash in sctpThread.cpp for message.peerInfo->counters[IN_INITI][MSG_COUNTER][ProcedureCode_id_E2setup]->Increment().

References

Community reviews

Loading reviews…