Two Open5GS AMF Vulnerabilities: Memory Corruption, DoS, and Response

Open5GS implements 4G EPC and 5G core network functions. Two CVE records published on August 30, 2026 affect the Access and Mobility Management Function. One concerns memory corruption while decoding a UE mobility-context list; the other can interrupt service while handling an N1-N2 message-transfer request. Both affect Open5GS 2.7.0 through 2.7.7 and identify 2.8.0 as the fixed boundary.

AMF handles device access, mobility procedures, NAS signaling, and control-plane coordination with gNBs. A process failure can therefore affect registration and control traffic handled by that instance. Deployment review must cover the actual AMF binaries, replicas, standby images, and rolling-upgrade state rather than a package manifest alone.

CVE-2026-82587: memory corruption

CVE-2026-82587 affects amf_namf_comm_decode_ue_mm_context_list in src/amf/namf-handler.c. The record describes memory corruption while processing allowedNssai values inside the UE mmContextList structure. Because the input can arrive remotely, upstream request validation does not replace the need to fix the C-level decoding boundary.

CVE-2026-82589: message-handling denial of service

CVE-2026-82589 affects amf_namf_comm_handle_n1_n2_message_transfer. Processing the ngapIeType nested under N1N2MessageTransferReqData can lead to denial of service. The two flaws share the same handler source file but require separate validation: one exercises mobility-context decoding, while the other covers normal N1-N2 transfer behavior.

Scope and update

• AMF instances running Open5GS 2.7.0 through 2.7.7
• Deployments that process UE mobility-context lists over Namf Communication
• AMF services receiving N1-N2 message-transfer requests
• Standby or disaster-recovery images that still contain an affected binary
• Rolling upgrades in which fixed and affected AMF nodes coexist

The official fixed boundary is Open5GS 2.8.0. Its release notes include an AMF memory-overflow fix along with broader protocol and network-function changes. Test those release changes in staging, rebuild from the approved source, and replace every AMF replica. Redundancy and automatic restart improve resilience but do not correct unsafe input handling.

1. Confirm the actual Open5GS version in production, standby, and recovery AMF images.
2. Review the 2.8.0 release changes and configuration compatibility in staging.
3. Build and deploy the official fixed release to every AMF instance.
4. Verify AMF startup, NRF registration, SBI connectivity, and gNB connections.
5. Run normal 5G device registration and mobility procedures.
6. Test normal N1-N2 transfers while monitoring errors, restarts, and memory use.

Post-deployment observation

Correlate AMF restart counts, SBI error rates, N1-N2 failures, device-registration success, and memory consumption on one timeline. During a rolling deployment, direct test traffic to fixed nodes first and expand gradually. If a rollback is required, avoid returning blindly to an affected 2.7.x image; separate configuration, protocol, and build causes while preserving the fixed security boundary.

These vulnerabilities show that structured control-plane input is also a memory-safety and availability boundary. Prioritize based on whether the affected code is present and which network functions can reach the Namf interface, not only on public Internet exposure. The response is complete when 2.8.0 is deployed, registration and N1-N2 workflows pass, and operational telemetry stays stable.