CVE-2026-42081

The AMF in Free5GC v4.2.1 does not verify the UE Security Capabilities received in NGAP PathSwitchRequest messages against its locally stored values, as mandated by 3GPP TS 33.501 §6.7.3.1. A malicious gNB can overwrite the AMF's stored UE security capabilities with arbitrary values, which are then propagated in PathSwitchRequest Acknowledge messages and subsequent Handover Request messages. This leads to persistent handover denial-of-service for affected UEs.

Details

Affected File: amf/internal/ngap/handler.go, handlePathSwitchRequestMain function

Root Cause:

When the AMF receives a PathSwitchRequest during an Xn-handover, it processes the UESecurityCapabilities IE by directly overwriting the stored values without comparing them to the previously stored capabilities:

if uESecurityCapabilities != nil {
    amfUe.UESecurityCapability.SetEA1_128_5G(uESecurityCapabilities.NRencryptionAlgorithms.Value.Bytes[0] & 0x80)
    amfUe.UESecurityCapability.SetEA2_128_5G(uESecurityCapabilities.NRencryptionAlgorithms.Value.Bytes[0] & 0x40)
    amfUe.UESecurityCapability.SetEA3_128_5G(uESecurityCapabilities.NRencryptionAlgorithms.Value.Bytes[0] & 0x20)
    amfUe.UESecurityCapability.SetIA1_128_5G(uESecurityCapabilities.NRintegrityProtectionAlgorithms.Value.Bytes[0] & 0x80)
    amfUe.UESecurityCapability.SetIA2_128_5G(uESecurityCapabilities.NRintegrityProtectionAlgorithms.Value.Bytes[0] & 0x40)
    amfUe.UESecurityCapability.SetIA3_128_5G(uESecurityCapabilities.NRintegrityProtectionAlgorithms.Value.Bytes[0] & 0x20)
}

3GPP TS 33.501 §6.7.3.1 requires three actions, none of which are implemented:

1. Verification (SHALL): "The AMF shall verify that the UE's 5G security capabilities received from the target gNB/ng-eNB are the same as the UE's 5G security capabilities that the AMF has locally stored."
   → Not implemented. The AMF unconditionally overwrites stored values.

2. Correction (SHALL): "If there is a mismatch, the AMF shall send its locally stored 5G security capabilities of the UE to the target gNB/ng-eNB in the Path-Switch Acknowledge message."
   → Not implemented. The PathSwitchRequestAcknowledge contains the corrupted values.

3. Logging (SHALL): "The AMF shall support logging capabilities for this event and may take additional measures, such as raising an alarm."
   → Not implemented. No mismatch detection or logging exists.

Propagation:

The corrupted values are propagated in:

• PathSwitchRequestAcknowledge: Contains corrupted UESecurityCapabilities (demonstrated in pcap)
• Subsequent HandoverRequest messages: AMF sends corrupted capabilities to target gNBs

Per TS 38.413 §8.4.2.4, if the supported algorithms in the UE Security Capabilities do not match any allowed algorithms configured in the target gNB, the target gNB is required to reject the procedure using a HANDOVER FAILURE message.

PoC

Environment:

• Free5GC v4.2.1 AMF (Docker container) with full NF stack (NRF, AUSF, UDM, UDR, NSSF, PCF, SMF, UPF)
• UERANSIM v3.2.7 gNB with custom inspection-tool extension
• tshark for packet capture

Reproduction Steps:

1. Start Free5GC full stack and register a UE through a gNB (NG Setup → Registration → PDU Session Setup).

2. Send a normal HandoverRequired from the gNB. Capture the resulting HandoverRequest from the AMF and confirm nRintegrityProtectionAlgorithms = 0xe000 (NIA1, NIA2, NIA3 all supported). This is the baseline.

3. Send a PathSwitchRequest with nRintegrityProtectionAlgorithms = 0x0000 (all integrity algorithms set to not supported). The AMF responds with PathSwitchRequestAcknowledge.

4. Observe that the PathSwitchRequestAcknowledge contains nRintegrityProtectionAlgorithms = 0x0000, the corrupted values are propagated back.

Observed Result (from pcap capture):

Availability (HIGH): A malicious gNB can send a single PathSwitchRequest message to corrupt the AMF's stored UE security capabilities for any UE. All subsequent inter-gNB handovers for the affected UE are expected to fail (per TS 38.413 §8.4.2.4), resulting in denial-of-service that persists until the UE performs a new registration.

Integrity (LOW): The AMF's internal UE security context is corrupted with attacker-controlled values. These corrupted values are propagated to other network elements via PathSwitchRequestAcknowledge and HandoverRequest messages.

Who is impacted: Any deployment using Free5GC as the AMF where a gNB could be compromised or where untrusted gNBs exist (e.g., O-RAN multi-vendor deployments).

CVE-2026-42081 has a CVSS score of 6.1 (Medium). The vector is reachable from an adjacent network, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.

Kodem intelligence

1. What is CVE-2026-42081? CVE-2026-42081 is a medium-severity security vulnerability in github.com/free5gc/amf (go), affecting versions <= 1.4.3. No fixed version is listed yet.
2. How severe is CVE-2026-42081? CVE-2026-42081 has a CVSS score of 6.1 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/free5gc/amf are affected by CVE-2026-42081? github.com/free5gc/amf (go) versions <= 1.4.3 is affected.
4. Is there a fix for CVE-2026-42081? No fixed version is listed for CVE-2026-42081 yet. Monitor the advisory for updates and apply mitigations in the interim.
5. Is CVE-2026-42081 exploitable, and should I be worried? Whether CVE-2026-42081 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-42081 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.