CWE-362
Allowed-with-ReviewConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Abstraction: Class · Status: Draft
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
3085 vulnerabilities reference this CWE, most recent first.
GHSA-326H-W5X2-4VRM
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2025-09-22 21:30A vulnerability has been found in Smartstore up to 6.2.0. The affected element is an unknown function of the file /checkout/confirm/ of the component Gift Voucher Handler. The manipulation leads to race condition. The attack may be initiated remotely. The attack's complexity is rated as high. The exploitability is described as difficult. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-10778"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-22T03:15:56Z",
"severity": "LOW"
},
"details": "A vulnerability has been found in Smartstore up to 6.2.0. The affected element is an unknown function of the file /checkout/confirm/ of the component Gift Voucher Handler. The manipulation leads to race condition. The attack may be initiated remotely. The attack\u0027s complexity is rated as high. The exploitability is described as difficult. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-326h-w5x2-4vrm",
"modified": "2025-09-22T21:30:20Z",
"published": "2025-09-22T21:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10778"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.325134"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.325134"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.640785"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-32CG-QPW6-CVVP
Vulnerability from github – Published: 2026-08-11 18:31 – Updated: 2026-08-11 18:31Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Telephony Service allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-59122"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-11T17:18:06Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Telephony Service allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-32cg-qpw6-cvvp",
"modified": "2026-08-11T18:31:00Z",
"published": "2026-08-11T18:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59122"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-59122"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-32H2-5PXQ-28CX
Vulnerability from github – Published: 2022-05-13 01:26 – Updated: 2022-05-13 01:26Race condition in the sandbox launcher implementation in Google Chrome before 11.0.696.57 on Linux allows remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors.
{
"affected": [],
"aliases": [
"CVE-2011-1444"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-05-03T22:55:00Z",
"severity": "MODERATE"
},
"details": "Race condition in the sandbox launcher implementation in Google Chrome before 11.0.696.57 on Linux allows remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors.",
"id": "GHSA-32h2-5pxq-28cx",
"modified": "2022-05-13T01:26:13Z",
"published": "2022-05-13T01:26:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-1444"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/67151"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14372"
},
{
"type": "WEB",
"url": "http://code.google.com/p/chromium/issues/detail?id=76542"
},
{
"type": "WEB",
"url": "http://googlechromereleases.blogspot.com/2011/04/chrome-stable-update.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2011/dsa-2245"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-32M9-JM89-HM8P
Vulnerability from github – Published: 2026-06-09 18:30 – Updated: 2026-06-09 18:30Use after free in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-45596"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T17:17:27Z",
"severity": "HIGH"
},
"details": "Use after free in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-32m9-jm89-hm8p",
"modified": "2026-06-09T18:30:51Z",
"published": "2026-06-09T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45596"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45596"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-32MX-364X-QGQ2
Vulnerability from github – Published: 2022-10-12 12:00 – Updated: 2025-01-03 00:31Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-22035, CVE-2022-24504, CVE-2022-30198, CVE-2022-33634, CVE-2022-38047, CVE-2022-41081.
{
"affected": [],
"aliases": [
"CVE-2022-38000"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-11T19:15:00Z",
"severity": "HIGH"
},
"details": "Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability. This CVE ID is unique from CVE-2022-22035, CVE-2022-24504, CVE-2022-30198, CVE-2022-33634, CVE-2022-38047, CVE-2022-41081.",
"id": "GHSA-32mx-364x-qgq2",
"modified": "2025-01-03T00:31:07Z",
"published": "2022-10-12T12:00:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38000"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-38000"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-38000"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-32PG-5795-JH5M
Vulnerability from github – Published: 2022-05-02 06:13 – Updated: 2022-05-02 06:13Race condition in the installation package in Apple iTunes before 9.1 on Windows allows local users to gain privileges by replacing an unspecified file with a Trojan horse.
{
"affected": [],
"aliases": [
"CVE-2010-0532"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-03-31T18:30:00Z",
"severity": "MODERATE"
},
"details": "Race condition in the installation package in Apple iTunes before 9.1 on Windows allows local users to gain privileges by replacing an unspecified file with a Trojan horse.",
"id": "GHSA-32pg-5795-jh5m",
"modified": "2022-05-02T06:13:29Z",
"published": "2022-05-02T06:13:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-0532"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A7110"
},
{
"type": "WEB",
"url": "http://lists.apple.com/archives/security-announce/2010//Mar/msg00003.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/39135"
},
{
"type": "WEB",
"url": "http://support.apple.com/kb/HT4105"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-32PV-2J2R-JJWX
Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Network File System allows an unauthorized attacker to execute code over a network.
{
"affected": [],
"aliases": [
"CVE-2026-56649"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T18:18:31Z",
"severity": "MODERATE"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Network File System allows an unauthorized attacker to execute code over a network.",
"id": "GHSA-32pv-2j2r-jjwx",
"modified": "2026-07-14T18:32:38Z",
"published": "2026-07-14T18:32:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56649"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-56649"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-32QQ-4Q5R-H4XR
Vulnerability from github – Published: 2022-03-11 00:02 – Updated: 2022-03-18 00:01Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042
{
"affected": [],
"aliases": [
"CVE-2022-23036"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-10T20:15:00Z",
"severity": "HIGH"
},
"details": "Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn\u0027t check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042",
"id": "GHSA-32qq-4q5r-h4xr",
"modified": "2022-03-18T00:01:19Z",
"published": "2022-03-11T00:02:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23036"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html"
},
{
"type": "WEB",
"url": "https://xenbits.xenproject.org/xsa/advisory-396.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-32QR-RH8P-QFQ7
Vulnerability from github – Published: 2022-08-27 00:00 – Updated: 2022-09-02 00:01A race condition was found in vdsm. Functionality to obfuscate sensitive values in log files that may lead to values being stored in clear text.
{
"affected": [],
"aliases": [
"CVE-2022-0207"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-26T18:15:00Z",
"severity": "MODERATE"
},
"details": "A race condition was found in vdsm. Functionality to obfuscate sensitive values in log files that may lead to values being stored in clear text.",
"id": "GHSA-32qr-rh8p-qfq7",
"modified": "2022-09-02T00:01:10Z",
"published": "2022-08-27T00:00:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0207"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2022:4764"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2022-0207"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2033697"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2039248"
},
{
"type": "WEB",
"url": "https://gerrit.ovirt.org/c/vdsm/+/118025"
},
{
"type": "WEB",
"url": "https://gerrit.ovirt.org/gitweb?p=vdsm.git%3Ba=commit%3Bh=53b0036fc72d3b8877d4e7f047d705e5a4c722e8"
},
{
"type": "WEB",
"url": "https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=53b0036fc72d3b8877d4e7f047d705e5a4c722e8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-334Q-H5G3-FPXV
Vulnerability from github – Published: 2026-08-28 22:24 – Updated: 2026-08-28 22:24Summary
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.
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:
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:
/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:
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:
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:
- The legitimate procedure starts and the AUSF stores
ctx_LEGITunderUePool[target_supi]. - The attacker sends many concurrent authentication requests for the same target SUCI/SUPI.
- Each request obtains a new authentication vector and stores a new context under the same SUPI key.
ctx_LEGITis overwritten byctx_ATTACK.- The legitimate EAP response, computed with
K_aut_LEGIT, reaches/eap-session. - The AUSF retrieves
ctx_ATTACKby SUPI and computesXMACwithK_aut_ATTACK. - 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-authenticationsrequests. - Same target SUCI:
suci-0-001-01-0-0-0-0000000002. - AUSF listening on
0.0.0.0:8100; PoC connected to127.0.0.1:8100.
Observed result:
- 24/24 requests returned HTTP 201.
- 24 distinct EapIDs were issued:
[131, 11, 157, 99, 182, 232, 127, 228, 119, 36, 104, 10,
107, 61, 66, 26, 110, 9, 210, 202, 53, 224, 237, 86]
- All responses used the same auth context URL:
/nausf-auth/v1/ue-authentications/suci-0-001-01-0-0-0-0000000002/eap-session
- AUSF logs showed repeated context creation for the same SUCI/SUPI in a short interval:
Add SuciSupiPair (suci-0-001-01-0-0-0-0000000002, imsi-001010000000002) to map.
Use EAP-AKA' auth method
| 201 | POST | /nausf-auth/v1/ue-authentications
...
This confirms that concurrent authentication requests for the same SUPI are accepted independently but collapse onto one shared context key.
Phase 2: valid EAP response fails after overwrite
The 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:
| Request | Vector class | XRES | Effect |
|---|---|---|---|
| 1st | LEGIT | 0102030405060708 |
response client computes AT_MAC with K_aut_LEGIT |
| 2nd and later | ATTACK | deadbeefcafe0000 |
flood overwrites AUSF context with K_aut_ATTACK |
Baseline without flood:
POST /ue-authentications
-> EapID=120, context with K_aut_LEGIT stored
POST /eap-session with AT_MAC(K_aut_LEGIT)
-> AUSF log: Correct RES value, EAP-AKA' auth succeed
-> HTTP 200, EAP success
Race condition run:
POST /ue-authentications
-> EapID=243, context with K_aut_LEGIT stored
20 concurrent POST /ue-authentications requests for the same SUCI
-> 20/20 accepted
-> K_aut_ATTACK overwrites K_aut_LEGIT in UePool
POST /eap-session with AT_MAC(K_aut_LEGIT)
-> AUSF validates against K_aut_ATTACK
-> AUSF log: EAP-AKA' failure: EAP-AKA' integrity check fail
-> HTTP 200, EAP notification failure
Critical AUSF log excerpt:
Add SuciSupiPair (suci-0-001-01-0-0-0-0000000002, imsi-001010000000002) to map.
... repeated for the same SUCI/SUPI ...
EapAuthComfirmRequest
[WARN] EAP-AKA' failure: EAP-AKA' integrity check fail
| 200 | 127.0.0.1 | POST | /nausf-auth/v1/ue-authentications/.../eap-session |
Baseline and attack logs are in the private evidence bundle:
hallazgos/finding13-ausf-auth-race/evidencia/20260527-195933-race-condition-p2-final/
The 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.
Impact
The confirmed impact is targeted denial of authentication service for a chosen SUPI.
An 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.
In 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.
Suggested remediation
The most robust fix is to stop using SUPI as the sole authentication-session key.
Recommended design:
- Generate a unique session identifier for every authentication request.
- Store the
AusfUeContextunder that session identifier. - Return the session identifier in the auth context URL.
- On
/eap-sessionor/5g-aka-confirmation, retrieve the exact session context by session ID rather than by SUPI.
Conceptual example:
sessionID := uuid.New().String()
ausfUeContext := ausf_context.NewAusfUeContext(sessionID)
ausfUeContext.Supi = ueid
// populate context...
ausf_context.AddAusfUeContextToPool(ausfUeContext)
// Return:
// /nausf-auth/v1/ue-authentications/{sessionID}/eap-session
If 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:
if existing, loaded := ausf_context.LoadOrStoreAusfUeContext(ueid, newCtx); loaded {
if existing.AuthStatus == models.AusfUeAuthenticationAuthResult_ONGOING {
c.JSON(http.StatusConflict, models.ProblemDetails{
Status: http.StatusConflict,
Cause: "AUTHENTICATION_IN_PROGRESS",
})
return
}
}
A mutex inside AusfUeContext alone is not sufficient if new requests are still allowed to replace the global map entry for the same SUPI.
Additional hardening:
- Apply per-SUPI rate limiting on
POST /ue-authentications. - Enable and enforce OAuth2/mTLS for SBI access in deployments.
- Add tests for concurrent authentication requests targeting the same SUPI.
Prior art / non-duplication note
Known related issues appear to be different:
- 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. - CVE-2026-44318 affects free5GC BSF and concerns a different concurrency issue in a different NF. It does not cover AUSF
UePoolauthentication state keyed by SUPI.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/free5gc/ausf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.4.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55784"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T22:24:11Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### 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\u0027 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\u0027\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\u0027, 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\u0027 response is then verified against the current context\u0027s `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\u0027 integrity check fail\"\n} else if XRES == RES {\n logger.AuthELog.Infoln(\"Correct RES value, EAP-AKA\u0027 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\u0027 notification failure.\n\n\nWhen later contexts carry different session material, a continuous flood prevents the target subscriber from completing authentication because the AUSF\u0027s 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\u0027 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\u0027 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\u0027 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\u0027 failure: EAP-AKA\u0027 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\u0027 failure: EAP-AKA\u0027 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\u0027 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\u0027s 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\u0027s 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.",
"id": "GHSA-334q-h5g3-fpxv",
"modified": "2026-08-28T22:24:12Z",
"published": "2026-08-28T22:24:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-334q-h5g3-fpxv"
},
{
"type": "PACKAGE",
"url": "https://github.com/free5gc/free5gc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "free5GC AUSF authentication contexts can be overwritten by concurrent requests for the same SUPI"
}
Mitigation
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Mitigation
Use thread-safe capabilities such as the data access abstraction in Spring.
Mitigation
- Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
- Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
When using multithreading and operating on shared variables, only use thread-safe functions.
Mitigation
Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
Mitigation
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Mitigation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Mitigation
Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Mitigation
Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.