CVE-2026-41136: Free5gc AMF RCE Vulnerability

CVE-2026-41136 Overview

CVE-2026-41136 is an Input Validation Error vulnerability in free5GC AMF, the Access & Mobility Management Function component of the free5GC open-source 5G mobile core network project. Prior to version 1.4.3, the HTTPUEContextTransfer handler in internal/sbi/api_communication.go does not include a default case in the Content-Type switch statement. When a request arrives with an unsupported Content-Type, the deserialization step is silently skipped, err remains nil, and the processor is invoked with a completely uninitialized UeContextTransferRequest object.

Critical Impact

An attacker can send requests with unsupported Content-Type headers to bypass input validation and invoke the AMF processor with uninitialized data, potentially disrupting 5G network mobility management functions.

Affected Products

• free5GC AMF versions prior to 1.4.3
• free5GC free5gc (5G mobile core network)

Discovery Timeline

• 2026-04-22 - CVE-2026-41136 published to NVD
• 2026-04-23 - Last updated in NVD database

Technical Details for CVE-2026-41136

Vulnerability Analysis

This vulnerability stems from CWE-440 (Expected Behavior Violation) where the application fails to handle unexpected input conditions properly. The HTTPUEContextTransfer handler implements a switch statement to determine how to deserialize incoming requests based on the Content-Type header. However, the switch statement lacks a default case to handle unsupported or malformed Content-Type values.

When an attacker sends a request with an unexpected Content-Type header that doesn't match any of the defined cases, the deserialization logic is completely bypassed. The critical flaw is that the error variable (err) remains nil despite no valid deserialization occurring, which allows execution to continue with a UeContextTransferRequest object containing zero-initialized or undefined values.

This affects the integrity of 5G network operations as the AMF component is responsible for critical mobility management functions including UE (User Equipment) registration, connection management, and handover procedures.

Root Cause

The root cause is the absence of a default case in the Content-Type switch statement within the HTTPUEContextTransfer function located in internal/sbi/api_communication.go. In Go, switch statements without a default case silently fall through when no cases match, leaving the request object uninitialized while error handling assumes success.

This programming oversight allows the processor to operate on an empty or uninitialized UeContextTransferRequest struct, which violates the expected behavior of the API endpoint and can lead to undefined application behavior.

Attack Vector

The vulnerability is exploitable over the network without authentication. An attacker can craft HTTP requests to the AMF's SBI (Service-Based Interface) endpoint with an arbitrary or malformed Content-Type header value that doesn't match the expected types (such as application/json).

The attack does not require user interaction and can be executed remotely against exposed free5GC AMF instances. The attacker sends a request like:

POST /ue-context-transfer HTTP/1.1
Content-Type: text/invalid
Host: target-amf:8080

{malicious or empty payload}

Since no code examples are available from verified sources, refer to the GitHub Security Advisory for technical implementation details of the fix introduced in version 1.4.3.

Detection Methods for CVE-2026-41136

Indicators of Compromise

• HTTP requests to AMF SBI endpoints with unusual or non-standard Content-Type headers
• Log entries showing requests processed without proper deserialization
• Anomalous UE context transfer operations with empty or default field values
• Unexpected error responses or behavior from AMF mobility management functions

Detection Strategies

• Monitor HTTP traffic to AMF SBI interfaces for requests with uncommon Content-Type headers
• Implement application-layer logging to track deserialization success/failure states
• Deploy network intrusion detection rules to flag requests with malformed Content-Type values targeting 5G core network components
• Review AMF access logs for patterns of requests that bypass normal processing flows

Monitoring Recommendations

• Enable verbose logging on free5GC AMF instances to capture incoming request headers
• Implement Content-Type header validation at the load balancer or API gateway level
• Set up alerts for requests to /ue-context-transfer endpoints with non-standard Content-Types
• Monitor for increases in failed or anomalous UE context transfer operations

How to Mitigate CVE-2026-41136

Immediate Actions Required

• Upgrade free5GC AMF to version 1.4.3 or later immediately
• Review AMF logs for evidence of exploitation attempts using malformed Content-Type headers
• Implement network-level filtering to restrict access to AMF SBI interfaces
• Consider deploying a Web Application Firewall (WAF) to validate Content-Type headers before they reach the AMF

Patch Information

The vulnerability has been fixed in free5GC AMF version 1.4.3. The patch adds proper handling for unsupported Content-Type values by implementing a default case in the switch statement that returns an appropriate error response.

Update your free5GC AMF deployment by downloading the patched version from the official release. For complete details on the vulnerability and fix, refer to the GitHub Security Advisory GHSA-r99v-75p9-xqm5.

Workarounds

• Deploy an API gateway or reverse proxy that strictly validates and filters Content-Type headers before forwarding requests to the AMF
• Implement network segmentation to limit access to AMF SBI interfaces to trusted network components only
• Use firewall rules to restrict incoming connections to the AMF service from untrusted sources
• If upgrading is not immediately possible, consider temporarily restricting access to the affected /ue-context-transfer endpoint

# Example: Nginx configuration to validate Content-Type headers
location /ue-context-transfer {
    if ($content_type !~ "^application/json") {
        return 415;
    }
    proxy_pass http://amf-backend:8080;
}