CVE-2026-55784: Concurrent Request Context Overwrite in free5GC AUSF

The free5GC system is an open-source implementation of the 5G Core Network, written in Go. Inside a standard 5G architecture, the Authentication Server Function (AUSF) plays a critical role in verifying subscriber identity during network access. The AUSF communicates with other core network elements, such as the Access and Mobility Management Function (AMF), via the Service-Based Interface (SBI) or the N12 reference point.

The vulnerability in free5GC versions 1.4.4 and earlier resides in how the AUSF manages transient subscriber state during the EAP-AKA' or 5G-AKA authentication process. To track ongoing authentication handshakes, the component instantiates a session context. This context contains critical cryptographic variables required to validate subsequent challenge responses.

The attack surface is exposed through the /nausf-auth/v1/ue-authentications HTTP endpoint, which handles initial authentication requests. Because this interface lacks validation rules regarding concurrent registration sessions for the same user, it exposes the system to concurrency anomalies. An attacker with access to the internal network can disrupt target subscribers by interacting with this endpoint.

The root cause of the vulnerability is an improper synchronization mechanism on a shared map. The Go runtime implements a concurrent-safe map container named sync.Map. While Go guarantees memory-level safety under concurrent operations (preventing program panic or map corruption), it does not enforce logical or semantic transaction isolation.

The AUSF context structure represents active authentication handshakes within a global sync.Map named AUSFContext.UePool. This map uses the Subscriber Permanent Identifier (SUPI) as its direct lookup key. When a new initial authentication request is received, the code unconditionally stores the state with UePool.Store(ausfUeContext.Supi, ausfUeContext).

This design creates a severe semantic race condition when multiple requests are initiated concurrently for the same SUPI. If Request B is executed before Request A completes its authentication handshake, the state context for Request B overwrites Request A's context in the map. Consequently, any responses corresponding to Request A are evaluated using the security context of Request B, causing cryptographic validation failures.

To understand the vulnerability mechanics, examine the execution path in internal/sbi/processor/ue_authentication.go. When a client makes an HTTP POST request to initiate authentication, the handler processes the incoming payload and extracts the SUPI. It then initializes a session context and stores it in the global map without verifying if a session is already active.

Below is the conceptual representation of the vulnerable context-handling implementation:

// In internal/context/context.go
type AUSFContext struct {
    UePool sync.Map // Key: SUPI (string), Value: *AusfUeContext
}
 
// In internal/sbi/processor/ue_authentication.go
func AddAusfUeContextToPool(ausfUeContext *context.AusfUeContext) {
    ausfContext := context.GetSelf()
    // Unconditional overwrite of the subscriber's context based solely on SUPI
    ausfContext.UePool.Store(ausfUeContext.Supi, ausfUeContext)
}

A robust mitigation requires refactoring the storage mechanism to support a multi-part key or generating a random UUID for each unique authentication transaction. The updated logic must verify that incoming authentication responses map directly to their corresponding challenge-response pairs rather than lookup coordinates based only on the user's permanent identifier:

// Remediated conceptual approach
type AUSFContext struct {
    // Key is a combination of SUPI and TransactionID to avoid collision
    UePool sync.Map 
}
 
func AddAusfUeContextToPool(txID string, ausfUeContext *context.AusfUeContext) {
    ausfContext := context.GetSelf()
    compositeKey := fmt.Sprintf("%s-%s", ausfUeContext.Supi, txID)
    ausfContext.UePool.Store(compositeKey, ausfUeContext)
}

Without a unique session identifier tracking the individual transaction lifecycle, concurrent requests will always collide. Incorporating unique identifiers ensures that each authentication workflow remains completely isolated, neutralizing the overwrite path.

Exploiting this vulnerability does not require complex state manipulation or target synchronization. The attacker must possess network visibility and access to the Service-Based Interface of the AUSF, typically via an internal network compromise. The attacker initiates the exploit by targeting a known subscriber's SUPI.

The attack begins by issuing a continuous stream of concurrent HTTP POST requests to /nausf-auth/v1/ue-authentications. This process continually replaces the active context mapping on the AUSF side. As a result, the transient variables K_aut, XRES, and EapID are constantly updated with newly generated challenge vectors.

When the legitimate User Equipment (UE) receives its initial challenge and responds with its cryptographic credentials, the verification routine queries UePool using the SUPI. Because of the flood, the map returns the state associated with the attacker's latest request rather than the original context. The verification step detects a mismatch in AT_MAC or RES* values, causing authentication to fail.

The direct consequence of this vulnerability is a targeted Denial of Service (DoS) affecting the availability of individual subscribers on the 5G network. By repeatedly flooding the AUSF with concurrent requests for a target SUPI, an attacker can persistently deny network registration to that subscriber. The affected subscriber cannot establish a connection, send traffic, or receive services.

While the vulnerability results in a high availability impact, it does not lead to a breach of data confidentiality or integrity. The attacker cannot obtain the legitimate user's cryptographic keys or impersonate the target subscriber, because the cryptographic validation itself functions correctly and rejects the mismatched credentials.

The CVSS v3.1 score is evaluated at 7.5, reflecting a High severity profile. The low attack complexity and absence of prerequisite privileges make the vulnerability straightforward to exploit once network access is achieved. However, the requirement for network access to the internal 5G core network control plane acts as an operational barrier in production environments.

As of the time of this publication, no official patched release of free5GC completely addresses this issue. Organizations running free5GC in development or testing environments must implement operational workarounds to secure their deployments. The most immediate mitigation is to enforce strong isolation around the control plane.

Implement network segmentation policies to restrict access to the AUSF Service-Based Interface. Ensure that only designated, authenticated AMF instances can connect to the /nausf-auth/v1/ue-authentications API endpoint. Mutual TLS (mTLS) must be enforced with client certificate verification to block unauthorized network entities from injecting requests.

Additionally, deploying rate limiting on the SBI gateway or internal reverse proxies can mitigate concurrent request floods. Setting strict limits on the number of authentication requests per SUPI per second prevents attackers from successfully maintaining the race condition state.