GHSA-77x9-rf64-92gv
MEDIUMGHSA-77x9-rf64-92gv is a medium-severity (CVSS 6.1) CWE-358 vulnerability in github.com/free5gc/amf. O3 Security confirms whether GHSA-77x9-rf64-92gv is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Free5GC AMF Bypasses UE Security Capabilities on NGAP PathSwitchRequest
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-77x9-rf64-92gv.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-77x9-rf64-92gv plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 356,453 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/free5gc/amfReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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:
-
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.
-
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.
-
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:
-
Start Free5GC full stack and register a UE through a gNB (NG Setup → Registration → PDU Session Setup).
-
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. -
Send a PathSwitchRequest with
nRintegrityProtectionAlgorithms = 0x0000(all integrity algorithms set to not supported). The AMF responds with PathSwitchRequestAcknowledge. -
Observe that the PathSwitchRequestAcknowledge contains
nRintegrityProtectionAlgorithms = 0x0000— the corrupted values are propagated back.
Observed Result (from pcap capture):
| Packet | Message | nRintegrityProtectionAlgorithms |
|---|---|---|
| #20 | HandoverRequest (AMF→gNB) | 0xe000 (NIA1 ✓ NIA2 ✓ NIA3 ✓) — baseline |
| #30 | PathSwitchRequest (gNB→AMF) | 0x0000 — poison |
| #47 | PathSwitchRequestAcknowledge (AMF→gNB) | 0x0000 (NIA1 ✗ NIA2 ✗ NIA3 ✗) — corrupted |
Impact
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).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/free5gc/amf | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/free5gc/amf. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of github.com/free5gc/amf has shipped for GHSA-77x9-rf64-92gv yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-77x9-rf64-92gv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-77x9-rf64-92gv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-77x9-rf64-92gv in your dependencies?
O3 detects GHSA-77x9-rf64-92gv across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.