{"id":"CVE-2026-55784","aliases":["EUVD-2026-68016","GHSA-334q-h5g3-fpxv","GO-2026-6326","SUSE-SU-2026:23692-1","SUSE-SU-2026:23712-1","openSUSE-SU-2026:21812-1"],"status":"published","title":"free5GC AUSF authentication contexts can be overwritten by concurrent requests for the same SUPI","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.","severity":{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00419,"percentile":0.36461,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-362"],"published":"2026-08-28T22:23:41Z","modified":"2026-10-20T16:13:56Z","affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/free5gc/ausf","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.4.4"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/free5gc/ausf","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"last_affected":"1.4.4"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/free5gc/ausf","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39}],"products":[{"vendor":"free5gc","product":"free5gc"}],"references":[{"url":"https://github.com/free5gc/free5gc/security/advisories/GHSA-334q-h5g3-fpxv","tags":["x_refsource_CONFIRM","exploit","web","advisory"]},{"url":"https://github.com/advisories/GHSA-334q-h5g3-fpxv"},{"url":"https://github.com/free5gc/free5gc","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623692-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-20909","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-22547","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-24690","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25712","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25718","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26232","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26247","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26307","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27657","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27878","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-28705","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54746","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54754","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54755","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54766","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55064","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55065","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55066","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55067","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55068","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55108","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55245","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55484","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55569","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55588","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55621","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55622","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55678","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55761","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55763","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55764","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55784","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55785","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55834","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55873","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55874","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56854","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56855","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-78662","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623712-1/","tags":["advisory"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-55784","title":"free5GC AUSF authentication contexts can be overwritten by concurrent requests for the same SUPI","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.","status":"published","published":"2026-08-28T22:23:41.923Z","modified":"2026-09-01T02:04:02.754Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-362"],"updated_at":"2026-11-02T14:20:11.925815Z"}],"euvd":[{"id":"EUVD-2026-68016","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.","status":"published","published":"2026-08-28T22:23:41Z","modified":"2026-09-01T02:04:02Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T18:01:19.285273Z"}],"ghsa":[{"id":"GHSA-334q-h5g3-fpxv","title":"free5GC AUSF authentication contexts can be overwritten by concurrent requests for the same SUPI","description":"### Summary\n\nThe 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.\n\nAn 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.\n\nThis issue was confirmed on `github.com/free5gc/ausf` v1.4.4 and current main as of June 2026.\n\n### Details\n\nThe vulnerable context pool is defined in `internal/context/context.go`.\n\n`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.\n\n```go\ntype AUSFContext struct {\n    suciSupiMap sync.Map\n    UePool      sync.Map\n    // ...\n}\n\ntype AusfUeContext struct {\n    Supi string\n    // ...\n\n    // for EAP-AKA'\n    K_aut    string\n    XRES     string\n    Rand     string\n    EapID    uint8\n    Resynced bool\n}\n\nfunc NewAusfUeContext(identifier string) (ausfUeContext *AusfUeContext) {\n    ausfUeContext = new(AusfUeContext)\n    ausfUeContext.Supi = identifier\n    return ausfUeContext\n}\n\nfunc AddAusfUeContextToPool(ausfUeContext *AusfUeContext) {\n    ausfContext.UePool.Store(ausfUeContext.Supi, ausfUeContext)\n}\n```\n\nThe vulnerable sequence is executed for every authentication request in `internal/sbi/processor/ue_authentication.go`:\n\n```go\nueid := authInfoResult.Supi\nausfUeContext := ausf_context.NewAusfUeContext(ueid)\nausfUeContext.ServingNetworkName = snName\nausfUeContext.AuthStatus = models.AusfUeAuthenticationAuthResult_ONGOING\nausfUeContext.UdmUeauUrl = udmUrl\nausf_context.AddAusfUeContextToPool(ausfUeContext)\n```\n\nThere 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:\n\n```text\n/nausf-auth/v1/ue-authentications/{suci}/eap-session\n```\n\nAll concurrent authentication attempts for the same subscriber therefore point to the same logical context URL, while the backing `AusfUeContext` in `UePool` is repeatedly replaced.\n\nWhen the EAP response is later processed, the AUSF looks up the current context by SUPI:\n\n```go\ncurrentSupi := ausf_context.GetSupiFromSuciSupiMap(eapSessionID)\nausfCurrentContext := ausf_context.GetAusfUeContext(currentSupi)\n```\n\nThe EAP-AKA' response is then verified against the current context's `K_aut` and `XRES`:\n\n```go\nK_autStr := ausfCurrentContext.K_aut\nXMAC := CalculateAtMAC(K_aut, decodeEapAkaPrimePkt.MACInput)\nMAC := decodeEapAkaPrimePkt.Attributes[ausf_context.AT_MAC_ATTRIBUTE].Value\nXRES := ausfCurrentContext.XRES\nRES := hex.EncodeToString(decodeEapAkaPrimePkt.Attributes[ausf_context.AT_RES_ATTRIBUTE].Value)\n\nif !bytes.Equal(MAC, XMAC) {\n    eapOK = false\n    eapErrStr = \"EAP-AKA' integrity check fail\"\n} else if XRES == RES {\n    logger.AuthELog.Infoln(\"Correct RES value, EAP-AKA' auth succeed\")\n    // ...\n}\n```\n\nIf 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.\n\n### Attack flow\n\nThe attack is selective for a target SUPI:\n\n1. The legitimate procedure starts and the AUSF stores `ctx_LEGIT` under `UePool[target_supi]`.\n2. The attacker sends many concurrent authentication requests for the same target SUCI/SUPI.\n3. Each request obtains a new authentication vector and stores a new context under the same SUPI key.\n4. `ctx_LEGIT` is overwritten by `ctx_ATTACK`.\n5. The legitimate EAP response, computed with `K_aut_LEGIT`, reaches `/eap-session`.\n6. The AUSF retrieves `ctx_ATTACK` by SUPI and computes `XMAC` with `K_aut_ATTACK`.\n7. AT_MAC verification fails and the AUSF returns an EAP-AKA' notification failure.\n\n\nWhen 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.\n\n### PoC and evidence\n\nThe issue was reproduced in two phases in a controlled free5GC lab.\n\n#### Phase 1: context overwrite\n\nExperiment:\n\n- 3 rounds of 8 concurrent `POST /nausf-auth/v1/ue-authentications` requests.\n- Same target SUCI: `suci-0-001-01-0-0-0-0000000002`.\n- AUSF listening on `0.0.0.0:8100`; PoC connected to `127.0.0.1:8100`.\n\nObserved result:\n\n- 24/24 requests returned HTTP 201.\n- 24 distinct EapIDs were issued:\n\n```text\n[131, 11, 157, 99, 182, 232, 127, 228, 119, 36, 104, 10,\n 107, 61, 66, 26, 110, 9, 210, 202, 53, 224, 237, 86]\n```\n\n- All responses used the same auth context URL:\n\n```text\n/nausf-auth/v1/ue-authentications/suci-0-001-01-0-0-0-0000000002/eap-session\n```\n\n- AUSF logs showed repeated context creation for the same SUCI/SUPI in a short interval:\n\n```text\nAdd SuciSupiPair (suci-0-001-01-0-0-0-0000000002, imsi-001010000000002) to map.\nUse EAP-AKA' auth method\n| 201 | POST | /nausf-auth/v1/ue-authentications\n...\n```\n\nThis confirms that concurrent authentication requests for the same SUPI are accepted independently but collapse onto one shared context key.\n\n#### Phase 2: valid EAP response fails after overwrite\n\nThe second PoC used a mock UDM with h2c support that returns different EAP-AKA' vectors by request counter for the same SUCI. This makes the overwrite directly observable:\n\n| Request | Vector class | XRES | Effect |\n|---|---|---|---|\n| 1st | LEGIT | `0102030405060708` | response client computes AT_MAC with `K_aut_LEGIT` |\n| 2nd and later | ATTACK | `deadbeefcafe0000` | flood overwrites AUSF context with `K_aut_ATTACK` |\n\nBaseline without flood:\n\n```text\nPOST /ue-authentications\n  -\u003e EapID=120, context with K_aut_LEGIT stored\n\nPOST /eap-session with AT_MAC(K_aut_LEGIT)\n  -\u003e AUSF log: Correct RES value, EAP-AKA' auth succeed\n  -\u003e HTTP 200, EAP success\n```\n\nRace condition run:\n\n```text\nPOST /ue-authentications\n  -\u003e EapID=243, context with K_aut_LEGIT stored\n\n20 concurrent POST /ue-authentications requests for the same SUCI\n  -\u003e 20/20 accepted\n  -\u003e K_aut_ATTACK overwrites K_aut_LEGIT in UePool\n\nPOST /eap-session with AT_MAC(K_aut_LEGIT)\n  -\u003e AUSF validates against K_aut_ATTACK\n  -\u003e AUSF log: EAP-AKA' failure: EAP-AKA' integrity check fail\n  -\u003e HTTP 200, EAP notification failure\n```\n\nCritical AUSF log excerpt:\n\n```text\nAdd SuciSupiPair (suci-0-001-01-0-0-0-0000000002, imsi-001010000000002) to map.\n... repeated for the same SUCI/SUPI ...\nEapAuthComfirmRequest\n[WARN] EAP-AKA' failure: EAP-AKA' integrity check fail\n| 200 | 127.0.0.1 | POST | /nausf-auth/v1/ue-authentications/.../eap-session |\n```\n\nBaseline and attack logs are in the private evidence bundle:\n\n```text\nhallazgos/finding13-ausf-auth-race/evidencia/20260527-195933-race-condition-p2-final/\n```\n\nThe final PoC uses a Python client that constructs a protocol-valid synthetic EAP-AKA' response from known vectors. It is not a full UERANSIM/AMF trace, and the P2 run uses a mock UDM returning distinct LEGIT/ATTACK vectors to make the overwrite observable. The synthetic response is sufficient to prove the AUSF state bug because the baseline succeeds with the same client and vectors, while the flood run fails at the exact AT_MAC check predicted by the code.\n\n### Impact\n\nThe confirmed impact is targeted denial of authentication service for a chosen SUPI.\n\nAn attacker with access to the AUSF SBI/N12 interface can keep a subscriber from authenticating by continuously overwriting that subscriber's AUSF context. The AUSF process remains running; this is not a process crash and does not expose authentication material to the attacker. The availability impact is on the AUSF's primary security function for the targeted subscriber.\n\nIn the default free5GC deployment observed in the lab, the AUSF reported OAuth2 disabled and listened on `0.0.0.0:8100`. In a production deployment with strict SBI isolation, mTLS, OAuth2, or firewalling, the attacker would need access to the internal SBA network or control of a network function that can send AUSF authentication requests.\n\n### Suggested remediation\n\nThe most robust fix is to stop using SUPI as the sole authentication-session key.\n\nRecommended design:\n\n1. Generate a unique session identifier for every authentication request.\n2. Store the `AusfUeContext` under that session identifier.\n3. Return the session identifier in the auth context URL.\n4. On `/eap-session` or `/5g-aka-confirmation`, retrieve the exact session context by session ID rather than by SUPI.\n\nConceptual example:\n\n```go\nsessionID := uuid.New().String()\nausfUeContext := ausf_context.NewAusfUeContext(sessionID)\nausfUeContext.Supi = ueid\n// populate context...\nausf_context.AddAusfUeContextToPool(ausfUeContext)\n\n// Return:\n// /nausf-auth/v1/ue-authentications/{sessionID}/eap-session\n```\n\nIf the intended behavior is to allow only one active authentication procedure per SUPI, use an atomic check-and-insert operation and reject concurrent attempts explicitly:\n\n```go\nif existing, loaded := ausf_context.LoadOrStoreAusfUeContext(ueid, newCtx); loaded {\n    if existing.AuthStatus == models.AusfUeAuthenticationAuthResult_ONGOING {\n        c.JSON(http.StatusConflict, models.ProblemDetails{\n            Status: http.StatusConflict,\n            Cause:  \"AUTHENTICATION_IN_PROGRESS\",\n        })\n        return\n    }\n}\n```\n\nA mutex inside `AusfUeContext` alone is not sufficient if new requests are still allowed to replace the global map entry for the same SUPI.\n\nAdditional hardening:\n\n- Apply per-SUPI rate limiting on `POST /ue-authentications`.\n- Enable and enforce OAuth2/mTLS for SBI access in deployments.\n- Add tests for concurrent authentication requests targeting the same SUPI.\n\n### Prior art / non-duplication note\n\nKnown related issues appear to be different:\n\n- CVE-2026-33063 / GHSA-4jrw-92fg-4jwx affects free5GC AUSF, but concerns a nil interface conversion / DoS in `GetSupiFromSuciSupiMap`. It does not cover authentication context overwrite by concurrent requests.\n- CVE-2026-44318 affects free5GC BSF and concerns a different concurrency issue in a different NF. It does not cover AUSF `UePool` authentication state keyed by SUPI.","status":"published","published":"2026-08-28T22:24:11Z","modified":"2026-08-28T22:24:13Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-362"],"updated_at":"2026-11-02T14:41:08.084849Z"}],"nvd":[{"id":"CVE-2026-55784","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.","status":"published","published":"2026-08-28T23:17:07.517Z","modified":"2026-10-20T16:13:56.927Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-362"],"updated_at":"2026-11-02T14:12:42.366888Z"}],"osv":[{"id":"GHSA-334q-h5g3-fpxv","title":"free5GC AUSF authentication contexts can be overwritten by concurrent requests for the same SUPI","description":"### Summary\n\nThe 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.\n\nAn 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.\n\nThis issue was confirmed on `github.com/free5gc/ausf` v1.4.4 and current main as of June 2026.\n\n### Details\n\nThe vulnerable context pool is defined in `internal/context/context.go`.\n\n`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.\n\n```go\ntype AUSFContext struct {\n    suciSupiMap sync.Map\n    UePool      sync.Map\n    // ...\n}\n\ntype AusfUeContext struct {\n    Supi string\n    // ...\n\n    // for EAP-AKA'\n    K_aut    string\n    XRES     string\n    Rand     string\n    EapID    uint8\n    Resynced bool\n}\n\nfunc NewAusfUeContext(identifier string) (ausfUeContext *AusfUeContext) {\n    ausfUeContext = new(AusfUeContext)\n    ausfUeContext.Supi = identifier\n    return ausfUeContext\n}\n\nfunc AddAusfUeContextToPool(ausfUeContext *AusfUeContext) {\n    ausfContext.UePool.Store(ausfUeContext.Supi, ausfUeContext)\n}\n```\n\nThe vulnerable sequence is executed for every authentication request in `internal/sbi/processor/ue_authentication.go`:\n\n```go\nueid := authInfoResult.Supi\nausfUeContext := ausf_context.NewAusfUeContext(ueid)\nausfUeContext.ServingNetworkName = snName\nausfUeContext.AuthStatus = models.AusfUeAuthenticationAuthResult_ONGOING\nausfUeContext.UdmUeauUrl = udmUrl\nausf_context.AddAusfUeContextToPool(ausfUeContext)\n```\n\nThere 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:\n\n```text\n/nausf-auth/v1/ue-authentications/{suci}/eap-session\n```\n\nAll concurrent authentication attempts for the same subscriber therefore point to the same logical context URL, while the backing `AusfUeContext` in `UePool` is repeatedly replaced.\n\nWhen the EAP response is later processed, the AUSF looks up the current context by SUPI:\n\n```go\ncurrentSupi := ausf_context.GetSupiFromSuciSupiMap(eapSessionID)\nausfCurrentContext := ausf_context.GetAusfUeContext(currentSupi)\n```\n\nThe EAP-AKA' response is then verified against the current context's `K_aut` and `XRES`:\n\n```go\nK_autStr := ausfCurrentContext.K_aut\nXMAC := CalculateAtMAC(K_aut, decodeEapAkaPrimePkt.MACInput)\nMAC := decodeEapAkaPrimePkt.Attributes[ausf_context.AT_MAC_ATTRIBUTE].Value\nXRES := ausfCurrentContext.XRES\nRES := hex.EncodeToString(decodeEapAkaPrimePkt.Attributes[ausf_context.AT_RES_ATTRIBUTE].Value)\n\nif !bytes.Equal(MAC, XMAC) {\n    eapOK = false\n    eapErrStr = \"EAP-AKA' integrity check fail\"\n} else if XRES == RES {\n    logger.AuthELog.Infoln(\"Correct RES value, EAP-AKA' auth succeed\")\n    // ...\n}\n```\n\nIf 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.\n\n### Attack flow\n\nThe attack is selective for a target SUPI:\n\n1. The legitimate procedure starts and the AUSF stores `ctx_LEGIT` under `UePool[target_supi]`.\n2. The attacker sends many concurrent authentication requests for the same target SUCI/SUPI.\n3. Each request obtains a new authentication vector and stores a new context under the same SUPI key.\n4. `ctx_LEGIT` is overwritten by `ctx_ATTACK`.\n5. The legitimate EAP response, computed with `K_aut_LEGIT`, reaches `/eap-session`.\n6. The AUSF retrieves `ctx_ATTACK` by SUPI and computes `XMAC` with `K_aut_ATTACK`.\n7. AT_MAC verification fails and the AUSF returns an EAP-AKA' notification failure.\n\n\nWhen 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.\n\n### PoC and evidence\n\nThe issue was reproduced in two phases in a controlled free5GC lab.\n\n#### Phase 1: context overwrite\n\nExperiment:\n\n- 3 rounds of 8 concurrent `POST /nausf-auth/v1/ue-authentications` requests.\n- Same target SUCI: `suci-0-001-01-0-0-0-0000000002`.\n- AUSF listening on `0.0.0.0:8100`; PoC connected to `127.0.0.1:8100`.\n\nObserved result:\n\n- 24/24 requests returned HTTP 201.\n- 24 distinct EapIDs were issued:\n\n```text\n[131, 11, 157, 99, 182, 232, 127, 228, 119, 36, 104, 10,\n 107, 61, 66, 26, 110, 9, 210, 202, 53, 224, 237, 86]\n```\n\n- All responses used the same auth context URL:\n\n```text\n/nausf-auth/v1/ue-authentications/suci-0-001-01-0-0-0-0000000002/eap-session\n```\n\n- AUSF logs showed repeated context creation for the same SUCI/SUPI in a short interval:\n\n```text\nAdd SuciSupiPair (suci-0-001-01-0-0-0-0000000002, imsi-001010000000002) to map.\nUse EAP-AKA' auth method\n| 201 | POST | /nausf-auth/v1/ue-authentications\n...\n```\n\nThis confirms that concurrent authentication requests for the same SUPI are accepted independently but collapse onto one shared context key.\n\n#### Phase 2: valid EAP response fails after overwrite\n\nThe second PoC used a mock UDM with h2c support that returns different EAP-AKA' vectors by request counter for the same SUCI. This makes the overwrite directly observable:\n\n| Request | Vector class | XRES | Effect |\n|---|---|---|---|\n| 1st | LEGIT | `0102030405060708` | response client computes AT_MAC with `K_aut_LEGIT` |\n| 2nd and later | ATTACK | `deadbeefcafe0000` | flood overwrites AUSF context with `K_aut_ATTACK` |\n\nBaseline without flood:\n\n```text\nPOST /ue-authentications\n  -\u003e EapID=120, context with K_aut_LEGIT stored\n\nPOST /eap-session with AT_MAC(K_aut_LEGIT)\n  -\u003e AUSF log: Correct RES value, EAP-AKA' auth succeed\n  -\u003e HTTP 200, EAP success\n```\n\nRace condition run:\n\n```text\nPOST /ue-authentications\n  -\u003e EapID=243, context with K_aut_LEGIT stored\n\n20 concurrent POST /ue-authentications requests for the same SUCI\n  -\u003e 20/20 accepted\n  -\u003e K_aut_ATTACK overwrites K_aut_LEGIT in UePool\n\nPOST /eap-session with AT_MAC(K_aut_LEGIT)\n  -\u003e AUSF validates against K_aut_ATTACK\n  -\u003e AUSF log: EAP-AKA' failure: EAP-AKA' integrity check fail\n  -\u003e HTTP 200, EAP notification failure\n```\n\nCritical AUSF log excerpt:\n\n```text\nAdd SuciSupiPair (suci-0-001-01-0-0-0-0000000002, imsi-001010000000002) to map.\n... repeated for the same SUCI/SUPI ...\nEapAuthComfirmRequest\n[WARN] EAP-AKA' failure: EAP-AKA' integrity check fail\n| 200 | 127.0.0.1 | POST | /nausf-auth/v1/ue-authentications/.../eap-session |\n```\n\nBaseline and attack logs are in the private evidence bundle:\n\n```text\nhallazgos/finding13-ausf-auth-race/evidencia/20260527-195933-race-condition-p2-final/\n```\n\nThe final PoC uses a Python client that constructs a protocol-valid synthetic EAP-AKA' response from known vectors. It is not a full UERANSIM/AMF trace, and the P2 run uses a mock UDM returning distinct LEGIT/ATTACK vectors to make the overwrite observable. The synthetic response is sufficient to prove the AUSF state bug because the baseline succeeds with the same client and vectors, while the flood run fails at the exact AT_MAC check predicted by the code.\n\n### Impact\n\nThe confirmed impact is targeted denial of authentication service for a chosen SUPI.\n\nAn attacker with access to the AUSF SBI/N12 interface can keep a subscriber from authenticating by continuously overwriting that subscriber's AUSF context. The AUSF process remains running; this is not a process crash and does not expose authentication material to the attacker. The availability impact is on the AUSF's primary security function for the targeted subscriber.\n\nIn the default free5GC deployment observed in the lab, the AUSF reported OAuth2 disabled and listened on `0.0.0.0:8100`. In a production deployment with strict SBI isolation, mTLS, OAuth2, or firewalling, the attacker would need access to the internal SBA network or control of a network function that can send AUSF authentication requests.\n\n### Suggested remediation\n\nThe most robust fix is to stop using SUPI as the sole authentication-session key.\n\nRecommended design:\n\n1. Generate a unique session identifier for every authentication request.\n2. Store the `AusfUeContext` under that session identifier.\n3. Return the session identifier in the auth context URL.\n4. On `/eap-session` or `/5g-aka-confirmation`, retrieve the exact session context by session ID rather than by SUPI.\n\nConceptual example:\n\n```go\nsessionID := uuid.New().String()\nausfUeContext := ausf_context.NewAusfUeContext(sessionID)\nausfUeContext.Supi = ueid\n// populate context...\nausf_context.AddAusfUeContextToPool(ausfUeContext)\n\n// Return:\n// /nausf-auth/v1/ue-authentications/{sessionID}/eap-session\n```\n\nIf the intended behavior is to allow only one active authentication procedure per SUPI, use an atomic check-and-insert operation and reject concurrent attempts explicitly:\n\n```go\nif existing, loaded := ausf_context.LoadOrStoreAusfUeContext(ueid, newCtx); loaded {\n    if existing.AuthStatus == models.AusfUeAuthenticationAuthResult_ONGOING {\n        c.JSON(http.StatusConflict, models.ProblemDetails{\n            Status: http.StatusConflict,\n            Cause:  \"AUTHENTICATION_IN_PROGRESS\",\n        })\n        return\n    }\n}\n```\n\nA mutex inside `AusfUeContext` alone is not sufficient if new requests are still allowed to replace the global map entry for the same SUPI.\n\nAdditional hardening:\n\n- Apply per-SUPI rate limiting on `POST /ue-authentications`.\n- Enable and enforce OAuth2/mTLS for SBI access in deployments.\n- Add tests for concurrent authentication requests targeting the same SUPI.\n\n### Prior art / non-duplication note\n\nKnown related issues appear to be different:\n\n- CVE-2026-33063 / GHSA-4jrw-92fg-4jwx affects free5GC AUSF, but concerns a nil interface conversion / DoS in `GetSupiFromSuciSupiMap`. It does not cover authentication context overwrite by concurrent requests.\n- CVE-2026-44318 affects free5GC BSF and concerns a different concurrency issue in a different NF. It does not cover AUSF `UePool` authentication state keyed by SUPI.","status":"published","published":"2026-08-28T22:24:11Z","modified":"2026-09-02T19:55:41.418108937Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-362"],"updated_at":"2026-11-02T15:46:35.050232Z"},{"id":"GO-2026-6326","title":"free5GC AUSF authentication contexts can be overwritten by concurrent requests for the same SUPI in github.com/free5gc/ausf","description":"free5GC AUSF authentication contexts can be overwritten by concurrent requests for the same SUPI in github.com/free5gc/ausf","status":"published","published":"2026-09-02T18:37:27Z","modified":"2026-09-02T19:45:13.187644264Z","updated_at":"2026-11-02T15:47:03.11707Z"},{"id":"openSUSE-SU-2026:21812-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:52:09Z","modified":"2026-09-10T18:23:18.964541257Z","updated_at":"2026-11-02T16:58:42.426393Z"},{"id":"SUSE-SU-2026:23692-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.31116925Z","updated_at":"2026-11-02T15:54:03.991985Z"},{"id":"SUSE-SU-2026:23712-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.805639295Z","updated_at":"2026-11-02T15:54:03.991985Z"}]}}