CVE-2024-24430 Overview
CVE-2024-24430 is a reachable assertion vulnerability in Open5GS, an open source implementation of 4G LTE and 5G Core Network components. The flaw resides in the mme_ue_find_by_imsi function within the Mobility Management Entity (MME). A remote attacker can send a crafted Non-Access Stratum (NAS) packet to trigger the assertion, terminating the MME process. The issue affects Open5GS versions 2.6.4 and earlier and results in a Denial of Service (DoS) condition against the cellular core network.
Critical Impact
A single crafted NAS packet can crash the MME process and disrupt mobility management for all subscribers served by the affected core network instance.
Affected Products
- Open5GS versions up to and including 2.6.4
- Deployments exposing the MME NAS interface to untrusted networks
- 4G LTE core network components built on the vulnerable Open5GS releases
Discovery Timeline
- 2025-01-22 - CVE-2024-24430 published to NVD
- 2025-04-22 - Last updated in NVD database
Technical Details for CVE-2024-24430
Vulnerability Analysis
The vulnerability is classified under [CWE-617] Reachable Assertion. The mme_ue_find_by_imsi function in the Open5GS MME contains an assertion that an attacker can reach through a crafted NAS packet. When the assertion condition fails, the process aborts, terminating the MME service.
The MME is the primary signaling node in an LTE Evolved Packet Core. Crashing it disconnects attached User Equipment (UE) and prevents new attach, paging, and handover procedures from completing. Recovery requires restarting the service and re-establishing subscriber state.
The attack requires no authentication and no user interaction. Network reachability to the MME NAS interface is the only prerequisite. EPSS data places the exploitation probability at 0.721%.
Root Cause
The defect stems from improper input validation in the IMSI lookup path. The function uses an assertion to enforce an invariant that an attacker-controlled NAS message can violate. Assertions are intended for unreachable program states, so reaching one through external input collapses the process instead of returning an error.
Attack Vector
The attack vector is network-based. An attacker delivers a malformed or unexpected NAS payload, such as an Attach Request or Identity Response with manipulated IMSI fields, to the MME. Processing the message routes execution to mme_ue_find_by_imsi, where the assertion fires and the MME terminates. Repeated delivery sustains the outage and amplifies impact on dependent eNodeBs and subscribers. Refer to the Cellular Security Analysis for additional context on the RANsacked research that disclosed this class of issues.
Detection Methods for CVE-2024-24430
Indicators of Compromise
- Unexpected MME process termination with assertion failure messages referencing mme_ue_find_by_imsi in Open5GS logs
- Spikes in NAS Attach Request or Identity Response messages from a single or small set of source identifiers
- Mass UE detach events and signaling storms on connected eNodeBs following an MME restart
Detection Strategies
- Monitor MME service status and restart counts for anomalies that correlate with inbound S1-MME traffic patterns
- Inspect NAS-layer telemetry for malformed IMSI Information Elements or non-conforming Attach signaling
- Alert on assert or abort strings in open5gs-mmed stderr and systemd journal output
Monitoring Recommendations
- Forward Open5GS MME logs and process supervision events to a centralized SIEM for correlation
- Track S1-MME packet rates per peer eNodeB and flag deviations from baselines
- Instrument health checks that verify MME availability and trigger investigation on repeated crashes
How to Mitigate CVE-2024-24430
Immediate Actions Required
- Upgrade Open5GS to a release later than 2.6.4 that includes the fix for the mme_ue_find_by_imsi assertion
- Restrict network reachability to the S1-MME interface to authorized eNodeB peers only
- Audit MME log retention and ensure crash events generate alerts to operations teams
Patch Information
Users should update to a fixed Open5GS release published after version 2.6.4. Confirm the patched commit in the project repository and rebuild any custom packaging from the corrected source. Review the Cellular Security Analysis for related findings that may require concurrent remediation.
Workarounds
- Place the MME behind network access controls that permit only trusted eNodeB source addresses on SCTP port 36412
- Deploy process supervision such as systemd with automatic restart to shorten outage windows until patching completes
- Rate-limit or filter NAS Attach traffic at the transport layer where signaling firewalls support deep inspection
# Example systemd override to auto-restart the MME on crash
# /etc/systemd/system/open5gs-mmed.service.d/restart.conf
[Service]
Restart=always
RestartSec=2s
StartLimitIntervalSec=0
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
