CVE-2026-33192
Improper Error Handling and Method Misuse in Free5GC UDM
Publication date: 2026-03-20
Last updated on: 2026-03-23
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| free5gc | udm | to 1.4.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-209 | The product generates an error message that includes sensitive information about its environment, users, or associated data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-33192 is a vulnerability in the Unified Data Management (UDM) component of free5GC, an open-source 5G core network project. The issue occurs when the UDM handles PATCH requests to the sdm-subscriptions endpoint with an empty SUPI (Subscriber Permanent Identifier) path parameter, represented by double slashes "//" in the URL.'}, {'type': 'paragraph', 'content': 'Instead of properly validating the empty SUPI parameter and returning a 400 Bad Request error, the UDM incorrectly translates the PATCH HTTP method to a PUT method when forwarding the request to the Unified Data Repository (UDR). The UDR then returns a 400 Bad Request due to the malformed path, but the UDM converts this 400 error into a 500 Internal Server Error response to the client.'}, {'type': 'paragraph', 'content': 'This improper error handling leaks internal server error details and violates REST API best practices by obscuring the distinction between client-side errors and server-side failures, making it difficult for clients to handle errors correctly.'}, {'type': 'paragraph', 'content': 'The vulnerability affects free5GC versions prior to 1.4.2 and has been patched in version 1.4.2.'}] [1, 2]
How can this vulnerability impact me? :
This vulnerability can impact you by causing improper error responses from the UDM component when processing PATCH requests with empty SUPI path parameters.
Specifically, clients will receive a 500 Internal Server Error instead of a 400 Bad Request, which can lead to confusion and difficulty in diagnosing whether the error is due to client input or server failure.
This improper error handling can complicate client-side error handling logic, potentially causing incorrect retry behavior or masking underlying issues.
Additionally, the incorrect translation of PATCH to PUT requests may cause unexpected behavior in the backend Unified Data Repository, potentially affecting data consistency or integrity.
There is no direct application-level workaround, but implementing API gateway-level validation to reject PATCH requests with empty path parameters before they reach the UDM is recommended.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by sending PATCH requests to the UDM Nudm_SDM service\'s sdm-subscriptions endpoint with an empty SUPI path parameter (represented by double slashes "//" in the URL) and observing the response behavior.'}, {'type': 'paragraph', 'content': 'For example, a test command using curl might be:'}, {'type': 'list_item', 'content': 'curl -X PATCH "http://<UDM_IP>:<PORT>/nudm-sdm/v2//sdm-subscriptions/1?supported-features=1a2b" -v'}, {'type': 'paragraph', 'content': 'If the UDM incorrectly returns a 500 Internal Server Error instead of a 400 Bad Request, this indicates the presence of the vulnerability.'}, {'type': 'paragraph', 'content': 'Additionally, monitoring logs for sequences where the UDM receives a PATCH request with an empty SUPI, forwards a PUT request to the UDR which returns 400, and then responds with 500 to the client can help detect the issue.'}] [1, 2]
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade free5GC to version 1.4.2 or later, where this vulnerability has been patched.
Since no direct application-level workaround exists, it is recommended to implement API gateway-level validation to reject PATCH requests with empty SUPI path parameters before they reach the UDM component.
This validation prevents malformed requests from triggering the improper error handling behavior in the UDM.