### Summary The AUSF component of free5GC stores per-subscriber authentication state in a global `sync.Map` keyed only by SUPI. Every incoming authentication request creates a new `AusfUeContext` and stores it under that SUPI key without checking whether an authentication procedure is already in progress and without generating a per-session unique identifier. 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. Each request is accepted and overwrites the previous authentication context. A valid EAP-AKA' response for an earlier challenge is then verified against the latest overwritten context, whose `K_aut`, `XRES`, and `EapID` no longer match the challenge. The result is a targeted authentication denial of service for that SUPI while the request flood is maintained. This issue was confirmed on `github.com/free5gc/ausf` v1.4.4 and current main as of June 2026. ### Details The vulnerable context pool is defined in `internal/context/context.go`. `UePool` is a `sync.Map`, which makes individual map operations safe, but it does not make the authentication procedure state safe. The problem is the session design: the key is only the SUPI, and `Store()` unconditionally replaces any active context for that SUPI. ```go type AUSFContext struct { suciSupiMap sync.Map UePool sync.Map // ... } type AusfUeContext struct { Supi string // ... // for EAP-AKA' K_aut string XRES string Rand string EapID uint8 Resynced bool } func NewAusfUeContext(identifier string) (ausfUeContext *AusfUeContext) { ausfUeContext = new(AusfUeContext) ausfUeContext.Supi = identifier return ausfUeContext } func AddAusfUeContextToPool(ausfUeContext *AusfUeContext) { ausfContext.UePool.Store(ausfUeContext.Supi, ausfUeContext) } ``` The vulnerable sequence is executed for every authentication request in `internal/sbi/processor/ue_authentication.go`: ```go ueid := authInfoResult.Supi ausfUeContext := ausf_context.NewAusfUeContext(ueid) ausfUeContext.ServingNetworkName = snName ausfUeContext.AuthStatus = models.AusfUeAuthenticationAuthResult_ONGOING ausfUeContext.UdmUeauUrl = udmUrl ausf_context.AddAusfUeContextToPool(ausfUeContext) ``` There is no guard such as `LoadOrStore`, no `AUTHENTICATION_IN_PROGRESS` response, no rate limit per SUPI, and no unique authentication-session ID in the context URL. For EAP-AKA', the returned context URL is derived directly from the SUCI/SUPI path: ```text /nausf-auth/v1/ue-authentications/{suci}/eap-session ``` All concurrent authentication attempts for the same subscriber therefore point to the same logical context URL, while the backing `AusfUeContext` in `UePool` is repeatedly replaced. When the EAP response is later processed, the AUSF looks up the current context by SUPI: ```go currentSupi := ausf_context.GetSupiFromSuciSupiMap(eapSessionID) ausfCurrentContext := ausf_context.GetAusfUeContext(currentSupi) ``` The EAP-AKA' response is then verified against the current context's `K_aut` and `XRES`: ```go K_autStr := ausfCurrentContext.K_aut XMAC := CalculateAtMAC(K_aut, decodeEapAkaPrimePkt.MACInput) MAC := decodeEapAkaPrimePkt.Attributes[ausf_context.AT_MAC_ATTRIBUTE].Value XRES := ausfCurrentContext.XRES RES := hex.EncodeToString(decodeEapAkaPrimePkt.Attributes[ausf_context.AT_RES_ATTRIBUTE].Value) if !bytes.Equal(MAC, XMAC) { eapOK = false eapErrStr = "EAP-AKA' integrity check fail" } else if XRES == RES { logger.AuthELog.Infoln("Correct RES value, EAP-AKA' auth succeed") // ... } ``` If another request has overwritten the context between challenge issuance and response processing, the legitimate response is checked against the wrong `K_aut` and fails the AT_MAC verification. ### Attack flow The attack is selective for a target SUPI: 1. The legitimate procedure starts and the AUSF stores `ctx_LEGIT` under `UePool[target_supi]`. 2. The attacker sends many concurrent authentication requests for the same target SUCI/SUPI. 3. Each request obtains a new authentication vector and stores a new context under the same SUPI key. 4. `ctx_LEGIT` is overwritten by `ctx_ATTACK`. 5. The legitimate EAP response, computed with `K_aut_LEGIT`, reaches `/eap-session`. 6. The AUSF retrieves `ctx_ATTACK` by SUPI and computes `XMAC` with `K_aut_ATTACK`. 7. AT_MAC verification fails and the AUSF returns an EAP-AKA' notification failure. When later contexts carry different session material, a continuous flood prevents the target subscriber from completing authentication because the AUSF's stored context keeps changing before the response is processed. ### PoC and evidence The issue was reproduced in two phases in a controlled free5GC lab. #### Phase 1: context overwrite Experiment: - 3 rounds of 8 concurrent `POST /nausf-auth/v1/ue-authentications` requests. - Same target SUCI: `suci-0-001-01-0-0-0-0000000002`. - AU