CVE-2026-8269
Denial of Service in Open5GS SMF Component
Publication date: 2026-05-11
Last updated on: 2026-05-11
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| open5gs | open5gs | to 2.7.7 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-404 | The product does not release or incorrectly releases a resource before it is made available for re-use. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in Open5GS up to version 2.7.7, specifically in the SMF (Session Management Function) component's function smf_nsmf_handle_create_sm_context.
The issue occurs when the SMF processes a POST request to create a session context with a non-full Data Network Name (DNN) in Home-Routed mode. The SMF initially accepts a short DNN like "internet" and returns a 201 Created response, but later crashes asynchronously due to an assertion failure when forwarding the request to the Home-SMF.
This crash causes a denial of service, making the SMF unstable. The expected behavior would be to reject such requests with a proper HTTP error instead of crashing.
How can this vulnerability impact me? :
The vulnerability can be remotely exploited to cause a denial of service in the Open5GS SMF component.
This means that an attacker can send specially crafted requests that cause the SMF to crash, leading to instability or unavailability of the session management function in the 5G core network.
Such denial of service could disrupt network services relying on Open5GS, potentially affecting connectivity and session management for users.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for crashes or abnormal terminations of the SMF component in Open5GS when processing POST requests to the endpoint `/nsmf-pdusession/v1/sm-contexts`.
Specifically, sending a POST request with a minimal or non-full Data Network Name (DNN), such as "internet", in Home-Routed (HR) mode can trigger the issue.
A practical detection method is to simulate or monitor for such POST requests and observe if the SMF process crashes with exit code 139.
Example command to test the vulnerability (using curl):
- curl -X POST http://<smf-ip>:<port>/nsmf-pdusession/v1/sm-contexts -d '{"dnn": "internet", ...}' -H 'Content-Type: application/json'
Monitoring system logs for SMF crashes or core dumps after such requests can help detect exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include restricting or filtering incoming POST requests to the SMF endpoint `/nsmf-pdusession/v1/sm-contexts` to prevent requests with minimal or non-full DNN values.
Implement network-level controls such as firewall rules or API gateway filters to block suspicious or malformed requests that could trigger the crash.
Monitor the SMF service for crashes and restart it promptly if it fails, while investigating the source of the problematic requests.
Since the project has not yet responded with a fix, consider isolating the vulnerable SMF component or limiting its exposure to untrusted networks.