Soumettre #883023: Open5GS v2.8.0 Improper Authorization

A vulnerability exists in the Open5GS AMF implementation in the NGAP UEContextReleaseRequest handling path. The issue allows a UE context that is owned and controlled by one NG-RAN/gNB association to be released after a UEContextReleaseRequest is received from a different NG-RAN/SCTP association. This behavior indicates an improper authorization check and insufficient validation of UE context ownership inside the AMF.
In a normal NGAP procedure, the UE Context Release Request procedure is expected to be initiated by the NG-RAN node that controls the UE-associated logical NG-connection. However, in the affected Open5GS AMF implementation, the AMF appears to perform a lookup of the UE context using the supplied NGAP identifiers without sufficiently verifying that the sending NG-RAN association is the same association that owns or controls the referenced UE context.
The issue was reproduced against Open5GS main at commit 7d0405476. In the reproduced test environment, an original gNB first established an NGAP association with the AMF and completed NGSetup. A UE was then registered through this original gNB, resulting in an active UE-associated logical NG-connection and an established UE context under that original gNB association. The affected UE was assigned an AMF_UE_NGAP_ID and a RAN_UE_NGAP_ID.
A second gNB then established a separate SCTP/NGAP association with the same AMF and completed NGSetup as a different NG-RAN peer. This second association did not own or control the previously established UE-associated logical NG-connection. Despite this, the second gNB association was able to send a UEContextReleaseRequest containing the active UE’s AMF_UE_NGAP_ID and RAN_UE_NGAP_ID. The AMF accepted this request and applied the release operation to the UE context owned by the original gNB association.
As a result, the AMF sent a UEContextReleaseCommand to the original UE-owning gNB association, and the original gNB completed the release procedure by returning UEContextReleaseComplete. This confirms that the release request was received from one NG-RAN association but was applied to a UE context controlled by another association.
The vulnerability is caused by missing or incomplete authorization validation in the UEContextReleaseRequest processing path. The AMF should verify that the NG-RAN/SCTP association submitting the UEContextReleaseRequest is authorized to operate on the referenced UE-associated logical NG-connection. If the request is received from a different NG-RAN association that does not control the UE context, the AMF should reject, ignore, or otherwise fail the request instead of applying the release to the original UE-owning association.
The affected behavior is especially relevant because the observed release was not part of a handover, mobility, or path-switch procedure. No PathSwitchRequest, HandoverRequired, HandoverRequest, or HandoverNotify procedure was involved in the reproduced packet flow. The second NG-RAN association therefore had no legitimate control relationship with the affected UE-associated logical NG-connection, but the AMF still processed its release request.
Successful exploitation requires access to the N2 / NG-RAN-side interface and the ability to establish a separate SCTP/NGAP association to the AMF as an NG-RAN peer. The attacker must also know or be able to reuse an active UE’s AMF_UE_NGAP_ID and RAN_UE_NGAP_ID. Under these conditions, a malicious or unauthorized NG-RAN peer may force the AMF to release a UE context that belongs to another gNB association.
The primary security impact is targeted availability loss for the affected UE. A malicious NG-RAN peer could disrupt service for a selected UE by triggering an unauthorized UE context release. The issue also affects AMF state integrity because the AMF applies a state-changing operation to a UE context based on a request from an association that does not own or control that context.
This vulnerability does not imply remote code execution, AMF process crash, subscriber data disclosure, NAS security bypass, or bypass of N2 network access controls. The issue is not that an attacker can access the N2 interface by itself; the issue is that, once a separate NG-RAN association exists, the AMF may incorrectly process a UE-associated release request for a UE context controlled by another association.
The expected behavior is that Open5GS AMF should enforce UE context ownership validation for UEContextReleaseRequest messages. For an existing UE-associated logical NG-connection, the AMF should only accept a UEContextReleaseRequest from the NG-RAN node that controls or is otherwise authorized for that UE context. Cross-association release requests should not result in release of another gNB’s UE context.

• La source: ⚠️ https://github.com/open5gs/open5gs/security/advisories/GHSA-mg8r-2cvv-xq9j
• Utilisateur: dwxll (UID 99637)
• Soumission: 08/07/2026 15:40 (il y a 2 mois)
• Modérer: 23/08/2026 13:34 (2 months later)
• Statut: Accepté
• Entrée VulDB: 394541 [Open5GS 2.8.0 AMF UEContextReleaseRequest Path élévation de privilèges]
• Points: 20