CVE-2026-44322
BaseFortify
Publication date: 2026-05-27
Last updated on: 2026-05-27
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| free5gc | free5gc | to 4.2.2 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-476 | The product dereferences a pointer that it expects to be valid but is NULL. |
| CWE-754 | The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in free5GC, an open-source 5G core network implementation, specifically in versions prior to 4.2.2. The issue occurs in the NEF PATCH handler for the endpoint /3gpp-pfd-management/v1/{afId}/transactions/{transId}/applications/{appId}. When an upstream UDR call fails and the consumer wrapper returns an error along with a nil ProblemDetails object, the handler attempts to read a field from this nil object, causing a nil-pointer dereference panic. This panic results in the server returning an HTTP 500 error instead of a controlled error response.
How can this vulnerability impact me? :
The vulnerability can cause the affected free5GC service to panic and return HTTP 500 errors when certain upstream calls fail. This can lead to denial of service conditions for clients attempting to use the affected PATCH endpoint, potentially disrupting 5G core network operations that rely on this functionality.
What immediate steps should I take to mitigate this vulnerability?
The vulnerability is fixed in free5GC version 4.2.2. To mitigate this vulnerability, you should upgrade your free5GC deployment to version 4.2.2 or later.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability causes a denial-of-service (DoS) condition by crashing the free5GC NEF component when the UDR access fails, resulting in HTTP 500 errors. It does not impact confidentiality or persistent integrity of data.
Since the vulnerability only affects availability during UDR failures and does not expose or compromise sensitive data, it primarily relates to availability requirements in standards like GDPR and HIPAA rather than confidentiality or data protection mandates.
Organizations relying on free5GC might face challenges in maintaining continuous service availability, which could affect compliance with availability and service continuity requirements under such regulations.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by sending a PATCH request to the vulnerable endpoint and observing if the service panics and returns an HTTP 500 Internal Server Error when the upstream UDR call fails.
Specifically, the vulnerable endpoint is: PATCH /3gpp-pfd-management/v1/{afId}/transactions/{transId}/applications/{appId}.
A practical detection method involves simulating a failure in the UDR or NRF service (e.g., stopping the NRF service) and then issuing a PATCH request to the endpoint. If the NEF component crashes or returns a 500 error due to a panic, the vulnerability is present.
Example command using curl to test the endpoint (replace placeholders with actual values):
- curl -X PATCH "http://<nef-host>:<port>/3gpp-pfd-management/v1/<afId>/transactions/<transId>/applications/<appId>" -d '<payload>' -H "Content-Type: application/json"
Ensure that the UDR or NRF service is unavailable or failing to trigger the error condition that leads to the panic.