Description

free5GC is an open-source implementation of the 5G core network. In version 1.4.4 and earlier, the AUSF component stores per-subscriber authentication state in a global sync.Map named AUSFContext.UePool in internal/context/context.go, keyed only by SUPI. Every request handled by internal/sbi/processor/ue_authentication.go creates an AusfUeContext, and AddAusfUeContextToPool executes ausfContext.UePool.Store(ausfUeContext.Supi, ausfUeContext), unconditionally replacing the active context for that SUPI. An attacker with access to the AUSF SBI/N12 interface can send concurrent POST /nausf-auth/v1/ue-authentications requests for the same target SUPI, causing all attempts to share one logical authentication context URL while K_aut, XRES, and EapID are repeatedly overwritten. A valid EAP-AKA' response for an earlier challenge is then checked against the latest context, causing AT_MAC verification to fail and denying authentication to the selected subscriber while the request flood continues. No fixed version is available as of this review.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-28T23:17:07.517Z",
  "pubdate": "2026-08-28T23:17:07.517Z",
  "executiveSummary": "The vulnerability is a race condition vulnerability in the free5GC AUSF component, specifically within the subscriber authentication state management logic. The flaw exists in the handling of concurrent authentication requests for the same SUPI (Subscription Permanent Identifier).\nBy flooding the SBI/N12 interface with concurrent POST /nausf-auth/v1/ue-authentications requests, an attacker can trigger race conditions that cause the overwriting of active authentication parameters, such as K_aut, XRES, and EapID, within the global AUSFContext.UePool sync.Map.\nThe primary impact is a Denial of Service (DoS) for the targeted subscriber's authentication attempts. When the legitimate network response is processed, the integrity check (AT_MAC verification) fails because the authentication context has been updated by the concurrent requests to reflect a newer, mismatched state.\nThis vulnerability affects free5GC version 1.4.4 and earlier. Exploitation requires the attacker to have network access to the AUSF SBI/N12 interface. Successful exploitation results in the disruption of authentication services for targeted subscribers, preventing them from accessing the 5G core network.",
  "technicalDetails": "The root cause of the vulnerability lies in the non-atomic update logic within the AUSF component's context management. Specifically, internal/sbi/processor/ue_authentication.go processes incoming authentication requests by creating an AusfUeContext and inserting it into a global sync.Map, AUSFContext.UePool, located in internal/context/context.go.\nThe insertion is performed using ausfContext.UePool.Store(ausfContext.Supi, ausfUeContext), which lacks synchronization mechanisms to verify if an existing authentication flow is currently active for the provided SUPI. This implementation unconditionally overwrites the existing entry in the sync.Map with the new context provided by the current request.\nThe attack flow begins when an attacker sends multiple, concurrent POST /nausf-auth/v1/ue-authentications requests targeting the same SUPI. As these requests hit the SBI interface, the AUSF service generates new authentication vectors (including K_aut, XRES, and EapID) and stores them in the shared UePool. Because the Store operation is not guarded against existing active sessions, each concurrent request invalidates the parameters of the previous ones.\nWhen the network subsequently receives a valid EAP-AKA' response corresponding to one of the earlier authentication challenges, the AUSF attempts to validate the response against the current state in UePool. Because the final entry in the UePool was overwritten by the last concurrent request in the flood, the validation process uses incorrect, updated cryptographic material. Consequently, the AT_MAC integrity check fails, resulting in a rejected authentication attempt.\nThe vulnerability is exposed through the SBI/N12 interface. There is no requirement for prior authentication by the attacker to initiate these requests, as they leverage the standard authentication initiation procedure of the 5G core. The post-exploitation impact is a targeted disruption of the subscriber's ability to complete the authentication handshake, effectively denying them network access. Because the state is global and lacks per-session validation or sequencing, the AUSF is unable to distinguish between legitimate consecutive re-authentication attempts and malicious request flooding, leading to a consistent state of authentication failure for the target SUPI as long as the flood persists."
}