CVE-2026-33192: Free5gc Udm Information Disclosure Flaw

CVE-2026-33192 Overview

CVE-2026-33192 is an Information Exposure vulnerability (CWE-209) affecting Free5GC, an open-source Linux Foundation project for 5th generation (5G) mobile core networks. The vulnerability exists in the Unified Data Management (UDM) component, which incorrectly converts downstream 400 Bad Request responses from the Unified Data Repository (UDR) into 500 Internal Server Error responses when handling PATCH requests with an empty supi path parameter. Additionally, the UDM incorrectly translates the PATCH method to PUT when forwarding requests to the UDR, indicating a deeper architectural issue in request handling.

Critical Impact

This vulnerability leaks internal error handling behavior through improper HTTP status code translation, making it difficult for clients to distinguish between client-side errors and server-side failures. Attackers could leverage this information disclosure to fingerprint internal architecture and potentially identify additional attack surfaces in 5G core network deployments.

Affected Products

• Free5GC UDM versions prior to 1.4.2

Discovery Timeline

• March 20, 2026 - CVE-2026-33192 published to NVD
• March 23, 2026 - Last updated in NVD database

Technical Details for CVE-2026-33192

Vulnerability Analysis

The vulnerability stems from improper error handling and HTTP method translation within the Free5GC UDM component. When the UDM receives a PATCH request with an empty supi (Subscription Permanent Identifier) path parameter, it forwards this malformed request to the UDR. The UDR correctly responds with a 400 Bad Request status, indicating a client-side error. However, the UDM incorrectly transforms this response into a 500 Internal Server Error before returning it to the client.

This behavior violates HTTP semantics where 4xx errors indicate client-side issues and 5xx errors indicate server-side failures. The information leakage allows attackers to infer details about the internal architecture, including the presence of downstream services and their error handling patterns. In 5G network deployments, this could expose sensitive architectural information about the core network infrastructure.

Root Cause

The root cause involves two distinct issues in the UDM request handling logic:

1. Improper HTTP Status Code Translation: The UDM fails to properly propagate 400 Bad Request responses from the UDR, instead converting them to 500 Internal Server Error responses. This masks the true nature of the error and leaks information about internal error handling mechanisms.

2. Incorrect HTTP Method Conversion: When forwarding requests to the UDR, the UDM incorrectly translates PATCH requests to PUT requests. This indicates a fundamental architectural flaw in the request routing logic that could lead to unintended data modifications or additional error conditions.

Attack Vector

The vulnerability is exploitable via network access without requiring authentication or user interaction. An attacker can send specially crafted PATCH requests to the UDM with empty or malformed supi path parameters. By analyzing the HTTP response status codes and error messages, attackers can:

1. Fingerprint the internal architecture of the 5G core network
2. Identify the presence and behavior of downstream services (UDR)
3. Map error handling patterns to identify additional vulnerabilities
4. Distinguish between different failure modes to refine attack strategies

The attack requires network access to the UDM service endpoint, which in production 5G deployments should be restricted to authorized network functions but may be exposed in improperly configured environments.

Detection Methods for CVE-2026-33192

Indicators of Compromise

• Unusual patterns of HTTP 500 errors in UDM logs that correspond to malformed PATCH requests with empty supi parameters
• Reconnaissance activity involving sequential requests to the UDM with variations of empty or invalid path parameters
• Log entries showing discrepancies between incoming PATCH requests and outgoing PUT requests to the UDR
• Increased error rates on the UDM-to-UDR communication path without corresponding client-side error indicators

Detection Strategies

• Monitor UDM access logs for PATCH requests with empty or missing supi path parameters
• Implement correlation rules to detect patterns of requests designed to trigger error responses for fingerprinting purposes
• Deploy application-layer monitoring to track HTTP method translations between UDM and UDR communications
• Analyze response code patterns to identify anomalous 500 error spikes that may indicate exploitation attempts

Monitoring Recommendations

• Enable detailed logging on the UDM component to capture request/response patterns including path parameters and HTTP methods
• Configure alerting for unusual volumes of 500 Internal Server Error responses from the UDM
• Monitor inter-service communication between UDM and UDR for HTTP method inconsistencies
• Implement log aggregation and analysis across all Free5GC network functions to correlate potential reconnaissance activities

How to Mitigate CVE-2026-33192

Immediate Actions Required

• Upgrade Free5GC UDM to version 1.4.2 or later immediately
• Review network segmentation to ensure UDM endpoints are not exposed to untrusted networks
• Implement input validation at the API gateway level to reject requests with empty supi parameters before they reach the UDM
• Enable comprehensive logging to detect any exploitation attempts before patching

Patch Information

The Free5GC project has released version 1.4.2 which addresses this vulnerability. The fix corrects the HTTP status code propagation logic in the UDM component and resolves the incorrect PATCH-to-PUT method translation issue.

For detailed patch information, refer to:

• GitHub Security Advisory GHSA-5rvc-5cwx-g5x8
• GitHub Pull Request #79
• GitHub Issue #784

Workarounds

• Deploy an API gateway or reverse proxy in front of the UDM to validate incoming requests and reject those with empty or missing supi parameters
• Implement network-level access controls to restrict UDM access to authorized network functions only
• Configure custom error handling at the load balancer level to normalize error responses and prevent information leakage
• Consider temporarily disabling PATCH operations on affected endpoints if operationally feasible until patching is complete

# Example: nginx reverse proxy configuration to reject empty supi parameters
location ~ ^/nudm-sdm/v1/([^/]+)/nssai$ {
    if ($1 = "") {
        return 400 '{"error": "Invalid supi parameter"}';
    }
    proxy_pass http://udm-backend;
}