O componente AUSF de livre 5 O GC armazena o estado de autenticação por inscrição em um `sync.Map` global apenas com chaves SUP. Cada pedido de autenticação entrante cria um novo `AusfUeContext` e armazena- o sob essa chave SUPI sem verificar se um procedimento de autenticação já está em andamento e sem gerar um identificador único por sessão. Um atacante com acesso ao SBI/N AUSF 12 interface pode enviar simultaneamente ` POST / nausf- auth/v 1 /ue- authentications` solicitações para o mesmo SUP de alvo. Cada pedido é aceito e sobrescreve o contexto de autenticação anterior. Uma resposta válida do EAP-AKA para um desafio anterior é então verificada com o contexto mais recente sobrescrito, cujos `K_aut`, `XRES` e `EapID` não mais correspondem ao desafio. O resultado é uma negação de serviço de autenticação direcionada para esse SUPI enquanto o enchente do pedido é mantido. Este problema foi confirmado no `github.com/free 5 gc/ausf` v 1.4.4 e principal atual a partir de junho 2026. O conjunto de contextos vulneráveis está definido em `internal/context/context.go`. "UePool" é um `sync.Map`, que torna seguras as operações individuais do mapa, mas não torna seguro o estado do processo de autenticação. O problema é o design da sessão: a chave é apenas o SUPI, e `Store()` substitui incondicionalmente qualquer contexto ativo para esse SUPI. ````go type AUSFContext struct { suciSupiMap sync.Map UePool sync.Map //... }. digite AusfUeContext struct { Supi string //...

// para EAP-AKA' K_aut string XRES string Rand string EapID uint 8 Bool sincronizado } func NewAusfUeContext(identificator string) (ausfUeContext *AusfUeContext) { ausfUeContext = new(AusfUeContext) ausfUeContext.Supi = identificador retorna ausfUeContext } Func AddAusfUeContextToPool(ausfUeContext *AusfUeContext) { ausfContext.UePool.Store(ausfUeContext.Supi, ausfUeContext) } ```. A sequência vulnerável é executada para cada pedido de autenticação em `internal/sbi/processor/ue_authentication.go`: ```go ueid:= authInfoResult.Supi ausfUeContexto:= ausf_context.NovaAusfUeContexto(ueid) ausfUeContext.ServingNetworkName = snName ausfUeContext.AuthStatus = modelos.AusfUeAuthenticationAuthResult_ONGING ausfUeContext.UdmUeauUrl = udmUrl ausf_context.AdicionarAusfUeContextToPool(ausfUeContext) `` Não há guardas como `LoadOrStore`, nenhuma resposta `AUTENTICATION_IN_PROGRESS`, nenhum limite de taxa por SUP, e nenhum ID de sessão de autenticação único na URL do contexto. Para EAP-AKA', o URL de contexto retornado é derivado diretamente do caminho SICI/SUPI: ``` texto / nausf- auth/v 1 /ue- authentications/ {suci}/eap- sessão ```. Todas as tentativas de autenticação simultâneas para o mesmo subscritor apontam para o mesmo contexto lógico URL, enquanto o backup de `AusfUeContext` em `UePool` é repetidamente substituído.

Quando a resposta do EAP for processada mais tarde, o AUSF procura o contexto atual por SUPI: ``` go currentSupi:= ausf_context.GetSupiFromSuciSupiMapa(eapSessionID) ausfCurrentContext:= ausf_context.GetAusfUeContext(currentSupi) ```. A resposta EAP-AKA é então verificada em relação ao contexto atual `K_aut` e `XRES`: ```go K_autStr:= ausfCurrentContext.K_aut XMAC:= CalcularAtMAC(K_aut, decodeEapAkaPrimePkt.MACInput) MAC:= decodeEapAkaPrimePkt.Attributes[ausf_context.AT_MAC_ATTRIBUTE].Valora XRES:= ausfCurrentContext.XRES RES:= hex.EncodeToString(decodeEapAkaPrimePkt.Attributes[ausf_context.AT_RES_ATTRIBUTE].Valora. if!bytes.Equal(MAC, XMAC) { eapOK = falso eapErrStr = "EAP-AKA' integrity check fail" } se o XRES for o mesmo que o XRES. Se outro pedido tiver substituído o contexto entre a emissão do desafio e o processamento da resposta, a resposta legítima é verificada contra o errado `K_aut` e falha na verificação AT_MAC. O ataque é seletivo para um SUPI alvo. 1. O procedimento legítimo começa e a AUSF armazena `ctx_LEGIT` em `UePool[target_supi]`. 2. O atacante envia muitos pedidos de autenticação simultâneos para o mesmo alvo SICI/SUPI. 3. Cada pedido obtém um novo vetor de autenticação e armazena um novo contexto sob a mesma chave SUP. 4. `ctx_LEGIT` é substituído por `ctx_ATTACK`. 5. A resposta legítima do EAP, calculada com `K_aut_ LEGIT`, atinge `/ eap- sessão`. 6. A AUSF recupera `ctx_ATTACK` pelo SUPI e calcula `XMAC` com `K_aut_ATTACK`. 7. A verificação AT_MAC falha e a AUSF retorna uma falha de notificação do EAP-AKA. Quando contextos posteriores carregam material de sessão diferente, uma inundação contínua impede o subscritor alvo de completar a autenticação, porque o contexto armazenado da AUSF continua mudando antes da resposta ser processada.

O problema foi reproduzido em duas fases em um livre controlado 5 Laboratório GC. Fase 1: sobrescrito do contexto. - 3 rodadas de 8 Simultâneo ` POST / nausf- auth/ v 1 /ue- authentications` solicitações. - Mesmo alvo SUCI: `suci- 0 - 001 - 01 - 0 - 0 - 0 - 0000000002 `. - AUSF ouvindo em ` 0.0.0.0: 8100 `; PoC conectado a ` 127.0.0.1: 8100 `. - 24 / 24 solicitações retornadas HTTP 201. - 24 EapIDs distintos foram emitidos: ``` texto [ 131, 11, 157, 99, 182, 232, 127, 228, 119, 36, 104, 10, 107, 61, 66, 26, 110, 9, 210, 202, 53, 224, 237, 86 ] ``` - Todas as respostas usaram a mesma URL de contexto de auth. ``` texto / nausf- auth/v 1 /ue- authentications/suci- 0 - 001 - 01 - 0 - 0 - 0 - 0000000002 /eap- sessão ```.

- Os registros AUSF mostraram criação de contexto repetida para o mesmo SICI/SUPI em um curto intervalo: ``` Texto Adicionar SuciSupiPair (suci- 0 - 001 - 01 - 0 - 0 - 0 - 0000000002, issi- 001010000000002 ) para mapear. Usar o método de autificação EAP-AKA' 201 POSTO / nausf- auth/v 1 /ue- autentications... ``` Isto confirma que os pedidos de autenticação concorrente para o mesmo SUP são aceitos independentemente, mas colapsam em uma chave de contexto compartilhada. Fase 2: resposta válida do EAP falha após sobrescrever. O segundo PoC usou um UDM simulado com o h 2 c suporte que retorna diferentes vetores do EAP- AKA por contador de pedidos para o mesmo SUCI. Isto torna a sobrescrição diretamente observável: . Solicitar. Classe vetor. XRES Efeito........................................................................................................................ 1 stLEGITH ` 0102030405060708 `. Cliente de resposta computa AT_MAC com ` K_aut_LEGIT`. 2 e depois ATAQUE ` beefcafe morto 0000 `. inundação sobrescreve contexto AUSF com ` K_aut_ATTACK`.

```text POST /ue-autentications -> EapID= 120, contexto com o K_aut_LEGIT armazenado. POST /eap-session com AT_MAC(K_aut_LEGIT) -> log AUSF: valor correto de RES, auth EAP-AKA' sucesso -> HTTP 200, sucesso do PAE ``` ```text POST /ue-autentications -> EapID= 243, contexto com o K_aut_LEGIT armazenado. 20 pedidos de POST /ue-autentications concorrentes para o mesmo SICI -> 20 / 20 aceitado -> O K_aut_ATTACK sobrescreve o K_aut_LEGIT em UePool POST /eap-session com AT_MAC(K_aut_LEGIT) -> AUSF valida contra K_aut_ATTACK -> AUSF log: EAP-AKA' falhou: EAP-AKA' verificação de integridade falha -> HTTP 200, falha na notificação do EAP ``` Extrato crítico do log AUSF. ``` Texto Adicionar SuciSupiPair (suci- 0 - 001 - 01 - 0 - 0 - 0 - 0000000002, issi- 001010000000002 ) para mapear.... repetido para o mesmo SICI/SUPI... EapAuthComfirmRequest [WARN] Falha no EAP-AKA': falha na verificação da integridade do EAP-AKA' 200 | 127.0.0.1 POSTO / nausf- auth/v 1 /ue- authentications/.../eap- sessão. ``` Os registros de base e de ataque estão no pacote de evidências privadas:.

``` texto hallazgos/fisking 13 - ausf- auth- race/ evidencia/ 20260527 - 195933 -condição-raça- p 2 - final/ `` O PoC final usa um cliente Python que constrói uma resposta sintética EAP-AKA válida para protocolo a partir de vetores conhecidos. Não é um traço completo do UERANSIM/AMF, e o P 2 a execução usa um simulado UDM retornando vetores distintos do LEGIT/ ATTACK para tornar a sobrescrita observável. A resposta sintética é suficiente para provar o erro de estado AUSF porque a linha de base é bem- sucedida com o mesmo cliente e vetores, enquanto a execução da inundação falha na verificação exata AT_MAC prevista pelo código. O impacto confirmado é a negação direcionada do serviço de autenticação para um SUPI escolhido. Um atacante com acesso ao SBI/N AUSF 12 interface pode impedir que um subscritor autêntico sobrescreva continuamente o contexto AUSF desse subscritor. O processo AUSF continua em execução; isto não é um falhado de processo e não expõe material de autenticação ao atacante. O impacto da disponibilidade é na função de segurança primária da AUSF para o assinante alvo. No padrão livre 5 Implementação GC observada no laboratório, a AUSF relatou OAuth 2 desativado e ouvido no ` 0.0.0.0: 8100 `. Em uma implantação de produção com isolamento rigoroso do SBI, mTLS, OAuth 2, ou firewalling, o atacante precisaria de acesso à rede interna SBA ou controle de uma função de rede que possa enviar pedidos de autenticação AUSF.

### Remediação sugerida. A correção mais robusta é parar de usar o SUPI como única chave de sessões de autenticação. 1. Gere um identificador de sessão único para cada pedido de autenticação. 2. Armazene o `AusfUeContext` sob esse identificador de sessão. 3. Retorne o identificador de sessão na URL do contexto de auth. 4. Em `/ eap- sessão ' ou `/ 5 g- aka- confirmation`, recupere o contexto exato da sessão por ID da sessão em vez de por SUPI. ``` go sessionID:= uuid.New().String() ausfUeContexto:= ausf_context.NewAusfUeContext(sessionID) ausfUeContext.Supi = ueid // populate context... ausf_context.AddAusfUeContextToPool(ausfUeContext) // Retornar: // / nausf- auth/ v 1 /ue- authentications/ {sessionID}/ eap- session ``` Se o comportamento pretendido é permitir apenas um procedimento de autenticação ativa por SUPI, use uma operação de verificação e inserção atômica e rejeite explicitamente tentativas concorrentes:.

``` go se existente, carregado:= ausf_context.LoadOrStoreAusfUeContext(ueid, newCtx); carregado { se existente.AuthStatus == modelos.AusfUeAuthenticationAuthResultat_ONGING { c.JSON(http.StatusConflict, models.ProblemDetails{ Status: http.StatusConflict, Cause: "AUTENTICATION_IN_PROGRESS", }) retorna } } ````````` Um mutex dentro do `AusfUeContext` por si só não é suficiente se novos pedidos ainda forem permitidos substituir a entrada global do mapa para o mesmo SUPI. Endurecimento adicional. - Aplicar limitação de taxa por-SUPI em ` POST /ue-autentications`. - Activar e executar OAuth 2 / mTLS para o acesso do SBI em implantações. - Adicionar testes para solicitações de autenticação concorrentes visando o mesmo SUP. ### Nota de Antecedentes / não duplicação. Os problemas relacionados conhecidos parecem ser diferentes: - CVE- 2026 - 33063 / GHSA- 4 Jrw- 92 fg- 4 jwx afeta livremente 5 GC AUSF, mas diz respeito a uma conversão de interface nula / DoS em `GetSupiFromSuciSupiMap`. Ele não cobre o contexto de autenticação sobrescrito por solicitações concorrentes. - CVE- 2026 - 44318 afeta livremente 5 GC BSF e diz respeito a uma questão de concorrencia diferente em um NF diferente. Ele não cobre o estado de autenticação AUSF `UePool` chaveado pelo SUPI.

Registro de aconselhamento: GHSA- 334 q- h 5 g 3 - fpxv. Identificadores relacionados: CVE- 2026 - 55784. Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 28 T 22: 24: 11.000 Z e lista a sua última modificação como 2026 - 08 - 28 T 22: 24: 12.000 Z. Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Software afetado e informações de versão: Go pacote github.com/free 5 gc/ausf — ECOSISTEM: introduzido 0, última afetada 1.4.4. Classificação e evidência: identificadores de fraqueza CWE- 362. O registro contém 2 suporte de referências nestes tipos: WEB, PACKAGE.