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.
2926 vulnerabilities reference this CWE, most recent first.
GHSA-CPHC-W6QW-F53M
Vulnerability from github – Published: 2022-05-17 01:10 – Updated: 2025-04-12 12:44Race condition in pxz 4.999.99 Beta 3 uses weak file permissions for the output file when compressing a file before changing the permission to match the original file, which allows local users to bypass the intended access restrictions.
{
"affected": [],
"aliases": [
"CVE-2015-1200"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-01-23T15:59:00Z",
"severity": "LOW"
},
"details": "Race condition in pxz 4.999.99 Beta 3 uses weak file permissions for the output file when compressing a file before changing the permission to match the original file, which allows local users to bypass the intended access restrictions.",
"id": "GHSA-cphc-w6qw-f53m",
"modified": "2025-04-12T12:44:40Z",
"published": "2022-05-17T01:10:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-1200"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/100207"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/C3UCBCIN6M5EXFET4RGQTVSSL5S57XCH"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IBKV7AT6O3FGQ735PFOGQ4Q5VODMSHE5"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XDCG7YJRDOR66V3WJDQPLMFSDULQDADC"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/C3UCBCIN6M5EXFET4RGQTVSSL5S57XCH"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IBKV7AT6O3FGQ735PFOGQ4Q5VODMSHE5"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XDCG7YJRDOR66V3WJDQPLMFSDULQDADC"
},
{
"type": "WEB",
"url": "http://seclists.org/oss-sec/2015/q1/177"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/72101"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CPM9-H38M-FG5V
Vulnerability from github – Published: 2022-05-13 01:15 – Updated: 2022-05-13 01:15Race condition in win32k.sys in the kernel-mode drivers in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, and Windows 7 Gold and SP1 allows local users to gain privileges, and consequently read the contents of arbitrary kernel memory locations, via a crafted application, a different vulnerability than other CVEs listed in MS13-016.
{
"affected": [],
"aliases": [
"CVE-2013-1255"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-02-13T12:04:00Z",
"severity": "MODERATE"
},
"details": "Race condition in win32k.sys in the kernel-mode drivers in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, and Windows 7 Gold and SP1 allows local users to gain privileges, and consequently read the contents of arbitrary kernel memory locations, via a crafted application, a different vulnerability than other CVEs listed in MS13-016.",
"id": "GHSA-cpm9-h38m-fg5v",
"modified": "2022-05-13T01:15:44Z",
"published": "2022-05-13T01:15:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-1255"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-016"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A16501"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/cas/techalerts/TA13-043B.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CPVV-8639-Q52M
Vulnerability from github – Published: 2026-06-09 18:30 – Updated: 2026-06-09 18:30Concurrent execution using shared resource with improper synchronization ('race condition') in Function Discovery Service (fdwsd.dll) allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-42836"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T17:17:09Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Function Discovery Service (fdwsd.dll) allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-cpvv-8639-q52m",
"modified": "2026-06-09T18:30:43Z",
"published": "2026-06-09T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42836"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-42836"
}
],
"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-CPWG-X64R-RGWG
Vulnerability from github – Published: 2026-06-12 18:29 – Updated: 2026-06-12 18:29Vulnerability: CWE-362 — Concurrent Map Access Race Condition in InMemorySecret2FA
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)
Affected Component
github.com/pilinux/gorest— Go REST API boilerplate- InMemorySecret2FA — in-memory 2FA secret store
Vulnerability Locations
| File | Line | Role |
|---|---|---|
database/model/twoFA.go |
43 | Global map[uint64]Secret2FA — bare map, no sync.RWMutex |
handler/login.go |
139 | Map write during user login |
handler/twoFA.go |
205 | Map write during 2FA setup |
handler/twoFA.go |
272 | Map write during 2FA activation |
handler/twoFA.go |
575 | Map write during 2FA verification |
handler/twoFA.go |
189 | Map read during 2FA operations |
handler/twoFA.go |
245 | Map read during 2FA operations |
handler/twoFA.go |
491 | Map read during 2FA operations |
service/common.go |
79 | Map delete |
Data Flow
Multiple HTTP goroutines (concurrent requests)
│
├── handler/login.go:139 ─► map write ──┐
├── handler/twoFA.go:205 ─► map write ──┼── InMemorySecret2FA (bare map)
├── handler/twoFA.go:189 ─► map read ───┤ ▲ NO sync.RWMutex
├── handler/twoFA.go:245 ─► map read ───┤ │
├── handler/twoFA.go:491 ─► map read ───┤ │
└── service/common.go:79 ─► map delete ─┘ │
│
Go runtime detects concurrent map │
read+write or write+write │
│ │
▼ │
fatal error: concurrent map read and map write │
fatal error: concurrent map writes │
│ │
▼ │
Process crash (DoS) ──────────────────────┘
Description
The InMemorySecret2FA in database/model/twoFA.go was defined as a package-level map[uint64]Secret2FA — a bare Go map with no synchronization primitive. Multiple HTTP handlers in handler/login.go and handler/twoFA.go read from and wrote to this map concurrently. Go's runtime detects unsynchronized concurrent map access and throws an unrecoverable fatal error, which crashes the entire process.
This is a CWE-362 race condition: the shared resource (the map) is accessed concurrently without proper synchronization, and the failure mode is a hard process crash (denial of service).
Trigger Conditions
- Two users with 2FA enabled logging in simultaneously — concurrent map writes
- One user logging in (map write) while another performs 2FA verification (map read)
- Any concurrent combination of the 9 affected handler locations
Proof of Concept
# Simulate two concurrent logins with 2FA enabled
for i in 1 2; do
curl -X POST http://target:8080/api/v1/login -H "Content-Type: application/json" -d "{"email":"user${i}@example.com","password":"testpass"}" &
done
wait
# Go runtime output:
# fatal error: concurrent map writes
# goroutine 34 [running]:
# runtime.throw({0x...})
# runtime/map.go:...
Impact
- Availability (High): Hard process crash via Go runtime fatal error. No recovery possible — the process exits. An attacker can repeat the concurrent requests to crash the service on demand.
- Confidentiality (None): The crash itself does not leak data.
- Integrity (None): No data corruption (Go prevents it by crashing).
Fix (PR #391)
Introduced Secret2FAStore struct with sync.RWMutex protection:
// BEFORE: database/model/twoFA.go — bare map, no protection
var InMemorySecret2FA map[uint64]Secret2FA
// AFTER: Wrapped with sync.RWMutex
type Secret2FAStore struct {
mu sync.RWMutex
data map[uint64]Secret2FA
}
func (s *Secret2FAStore) Get(key uint64) (Secret2FA, bool) {
s.mu.RLock()
defer s.mu.RUnlock()
v, ok := s.data[key]
return cloneSecret2FA(v), ok
}
func (s *Secret2FAStore) Set(key uint64, value Secret2FA) {
s.mu.Lock()
defer s.mu.Unlock()
s.data[key] = cloneSecret2FA(value)
}
func (s *Secret2FAStore) Delete(key uint64) {
s.mu.Lock()
defer s.mu.Unlock()
delete(s.data, key)
}
// cloneSecret2FA returns a deep copy of a Secret2FA.
// This prevents external code from mutating the store's data
// through shared slice backing arrays.
func cloneSecret2FA(v Secret2FA) Secret2FA {
out := Secret2FA{Image: v.Image}
if v.PassHash != nil {
out.PassHash = append([]byte(nil), v.PassHash...)
}
if v.KeySalt != nil {
out.KeySalt = append([]byte(nil), v.KeySalt...)
}
if v.Secret != nil {
out.Secret = append([]byte(nil), v.Secret...)
}
return out
}
All 9 handler call sites updated from direct map access to store method calls.
Not Vulnerable (verified during audit)
- JWT: RSA keys from files, appleboy/gin-jwt middleware — correct
- Password hashing: Argon2 via pilinux/argon2 — correct
- SQL queries: GORM parameterized — correct
- CORS: validates wildcard+credentials combination at config load — correct
Patched Versions
All versions after PR #391 merge.
Resources
- Fix PR: https://github.com/pilinux/gorest/pull/391
Credit
Reported by @saaa99999999 via manual security audit.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.12.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/pilinux/gorest"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48154"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-12T18:29:08Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Vulnerability: CWE-362 \u2014 Concurrent Map Access Race Condition in InMemorySecret2FA\n\n**CWE:** CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)\n\n### Affected Component\n- `github.com/pilinux/gorest` \u2014 Go REST API boilerplate\n- InMemorySecret2FA \u2014 in-memory 2FA secret store\n\n### Vulnerability Locations\n\n| File | Line | Role |\n|------|------|------|\n| `database/model/twoFA.go` | 43 | Global `map[uint64]Secret2FA` \u2014 bare map, no sync.RWMutex |\n| `handler/login.go` | 139 | Map write during user login |\n| `handler/twoFA.go` | 205 | Map write during 2FA setup |\n| `handler/twoFA.go` | 272 | Map write during 2FA activation |\n| `handler/twoFA.go` | 575 | Map write during 2FA verification |\n| `handler/twoFA.go` | 189 | Map read during 2FA operations |\n| `handler/twoFA.go` | 245 | Map read during 2FA operations |\n| `handler/twoFA.go` | 491 | Map read during 2FA operations |\n| `service/common.go` | 79 | Map delete |\n\n### Data Flow\n\n```\nMultiple HTTP goroutines (concurrent requests)\n \u2502\n \u251c\u2500\u2500 handler/login.go:139 \u2500\u25ba map write \u2500\u2500\u2510\n \u251c\u2500\u2500 handler/twoFA.go:205 \u2500\u25ba map write \u2500\u2500\u253c\u2500\u2500 InMemorySecret2FA (bare map)\n \u251c\u2500\u2500 handler/twoFA.go:189 \u2500\u25ba map read \u2500\u2500\u2500\u2524 \u25b2 NO sync.RWMutex\n \u251c\u2500\u2500 handler/twoFA.go:245 \u2500\u25ba map read \u2500\u2500\u2500\u2524 \u2502\n \u251c\u2500\u2500 handler/twoFA.go:491 \u2500\u25ba map read \u2500\u2500\u2500\u2524 \u2502\n \u2514\u2500\u2500 service/common.go:79 \u2500\u25ba map delete \u2500\u2518 \u2502\n \u2502\n Go runtime detects concurrent map \u2502\n read+write or write+write \u2502\n \u2502 \u2502\n \u25bc \u2502\n fatal error: concurrent map read and map write \u2502\n fatal error: concurrent map writes \u2502\n \u2502 \u2502\n \u25bc \u2502\n Process crash (DoS) \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n```\n\n### Description\n\nThe `InMemorySecret2FA` in `database/model/twoFA.go` was defined as a package-level `map[uint64]Secret2FA` \u2014 a bare Go map with no synchronization primitive. Multiple HTTP handlers in `handler/login.go` and `handler/twoFA.go` read from and wrote to this map concurrently. Go\u0027s runtime detects unsynchronized concurrent map access and throws an unrecoverable `fatal error`, which crashes the entire process.\n\nThis is a CWE-362 race condition: the shared resource (the map) is accessed concurrently without proper synchronization, and the failure mode is a hard process crash (denial of service).\n\n### Trigger Conditions\n\n1. Two users with 2FA enabled logging in simultaneously \u2014 concurrent map writes\n2. One user logging in (map write) while another performs 2FA verification (map read)\n3. Any concurrent combination of the 9 affected handler locations\n\n### Proof of Concept\n\n```bash\n# Simulate two concurrent logins with 2FA enabled\nfor i in 1 2; do\n curl -X POST http://target:8080/api/v1/login -H \"Content-Type: application/json\" -d \"{\"email\":\"user${i}@example.com\",\"password\":\"testpass\"}\" \u0026\ndone\nwait\n\n# Go runtime output:\n# fatal error: concurrent map writes\n# goroutine 34 [running]:\n# runtime.throw({0x...})\n# runtime/map.go:...\n```\n\n### Impact\n\n- **Availability (High):** Hard process crash via Go runtime fatal error. No recovery possible \u2014 the process exits. An attacker can repeat the concurrent requests to crash the service on demand.\n- **Confidentiality (None):** The crash itself does not leak data.\n- **Integrity (None):** No data corruption (Go prevents it by crashing).\n\n### Fix (PR #391)\n\nIntroduced `Secret2FAStore` struct with `sync.RWMutex` protection:\n\n```go\n// BEFORE: database/model/twoFA.go \u2014 bare map, no protection\nvar InMemorySecret2FA map[uint64]Secret2FA\n\n// AFTER: Wrapped with sync.RWMutex\ntype Secret2FAStore struct {\n mu sync.RWMutex\n data map[uint64]Secret2FA\n}\n\nfunc (s *Secret2FAStore) Get(key uint64) (Secret2FA, bool) {\n s.mu.RLock()\n defer s.mu.RUnlock()\n v, ok := s.data[key]\n return cloneSecret2FA(v), ok\n}\n\nfunc (s *Secret2FAStore) Set(key uint64, value Secret2FA) {\n s.mu.Lock()\n defer s.mu.Unlock()\n s.data[key] = cloneSecret2FA(value)\n}\n\nfunc (s *Secret2FAStore) Delete(key uint64) {\n s.mu.Lock()\n defer s.mu.Unlock()\n delete(s.data, key)\n}\n\n// cloneSecret2FA returns a deep copy of a Secret2FA.\n// This prevents external code from mutating the store\u0027s data\n// through shared slice backing arrays.\nfunc cloneSecret2FA(v Secret2FA) Secret2FA {\n\tout := Secret2FA{Image: v.Image}\n\tif v.PassHash != nil {\n\t\tout.PassHash = append([]byte(nil), v.PassHash...)\n\t}\n\tif v.KeySalt != nil {\n\t\tout.KeySalt = append([]byte(nil), v.KeySalt...)\n\t}\n\tif v.Secret != nil {\n\t\tout.Secret = append([]byte(nil), v.Secret...)\n\t}\n\treturn out\n}\n```\n\nAll 9 handler call sites updated from direct map access to store method calls.\n\n### Not Vulnerable (verified during audit)\n\n- JWT: RSA keys from files, appleboy/gin-jwt middleware \u2014 correct\n- Password hashing: Argon2 via pilinux/argon2 \u2014 correct\n- SQL queries: GORM parameterized \u2014 correct\n- CORS: validates wildcard+credentials combination at config load \u2014 correct\n\n### Patched Versions\n\nAll versions after PR #391 merge.\n\n### Resources\n\n- Fix PR: https://github.com/pilinux/gorest/pull/391\n\n### Credit\n\nReported by @saaa99999999 via manual security audit.",
"id": "GHSA-cpwg-x64r-rgwg",
"modified": "2026-06-12T18:29:08Z",
"published": "2026-06-12T18:29:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pilinux/gorest/security/advisories/GHSA-cpwg-x64r-rgwg"
},
{
"type": "WEB",
"url": "https://github.com/pilinux/gorest/pull/391"
},
{
"type": "PACKAGE",
"url": "https://github.com/pilinux/gorest"
}
],
"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"
}
],
"summary": "gorest InMemorySecret2FA race condition allows process crash via concurrent map access (CWE-362)"
}
GHSA-CQ2W-Q6M3-MHW9
Vulnerability from github – Published: 2025-10-09 15:31 – Updated: 2026-02-03 15:30In the Linux kernel, the following vulnerability has been resolved:
iommu/amd/pgtbl: Fix possible race while increase page table level
The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations.
The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level.
But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON.
CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)
Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.
{
"affected": [],
"aliases": [
"CVE-2025-39961"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-09T13:15:32Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd/pgtbl: Fix possible race while increase page table level\n\nThe AMD IOMMU host page table implementation supports dynamic page table levels\n(up to 6 levels), starting with a 3-level configuration that expands based on\nIOVA address. The kernel maintains a root pointer and current page table level\nto enable proper page table walks in alloc_pte()/fetch_pte() operations.\n\nThe IOMMU IOVA allocator initially starts with 32-bit address and onces its\nexhuasted it switches to 64-bit address (max address is determined based\non IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU\ndriver increases page table level.\n\nBut in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads\npgtable-\u003e[root/mode] without lock. So its possible that in exteme corner case,\nwhen increase_address_space() is updating pgtable-\u003e[root/mode], fetch_pte()\nreads wrong page table level (pgtable-\u003emode). It does compare the value with\nlevel encoded in page table and returns NULL. This will result is\niommu_unmap ops to fail and upper layer may retry/log WARN_ON.\n\nCPU 0 CPU 1\n------ ------\nmap pages unmap pages\nalloc_pte() -\u003e increase_address_space() iommu_v1_unmap_pages() -\u003e fetch_pte()\n pgtable-\u003eroot = pte (new root value)\n READ pgtable-\u003e[mode/root]\n\t\t\t\t\t Reads new root, old mode\n Updates mode (pgtable-\u003emode += 1)\n\nSince Page table level updates are infrequent and already synchronized with a\nspinlock, implement seqcount to enable lock-free read operations on the read path.",
"id": "GHSA-cq2w-q6m3-mhw9",
"modified": "2026-02-03T15:30:20Z",
"published": "2025-10-09T15:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39961"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/075abf0b1a958acfbea2435003d228e738e90346"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e56310b40fd2e7e0b9493da9ff488af145bdd0c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d462bdecb7d9c32934dab44aaeb7ea7d73a27a2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd92c8ab336c3a633d46e6f35ebcd3509ae7db3b"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CQ7P-PGP3-4RJ8
Vulnerability from github – Published: 2026-04-14 18:30 – Updated: 2026-04-14 18:30Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Push Notifications allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-26172"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-14T18:16:51Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Push Notifications allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-cq7p-pgp3-4rj8",
"modified": "2026-04-14T18:30:37Z",
"published": "2026-04-14T18:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26172"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-26172"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CQMW-3H5W-7XQ6
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34Race condition in subsystem for Intel(R) CSME versions before 12.0.70 and 14.0.45, Intel(R) SPS versions before E5_04.01.04.400 and E3_05.01.04.200 may allow an unauthenticated user to potentially enable escalation of privilege via physical access.
{
"affected": [],
"aliases": [
"CVE-2020-8755"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-12T18:15:00Z",
"severity": "MODERATE"
},
"details": "Race condition in subsystem for Intel(R) CSME versions before 12.0.70 and 14.0.45, Intel(R) SPS versions before E5_04.01.04.400 and E3_05.01.04.200 may allow an unauthenticated user to potentially enable escalation of privilege via physical access.",
"id": "GHSA-cqmw-3h5w-7xq6",
"modified": "2022-05-24T17:34:13Z",
"published": "2022-05-24T17:34:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8755"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20201113-0002"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20201113-0004"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00391"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CQPW-MC9F-6GF5
Vulnerability from github – Published: 2022-05-24 17:32 – Updated: 2022-05-24 17:32A race condition was addressed with additional validation. This issue is fixed in macOS Catalina 10.15.6. A malicious application may be able to execute arbitrary code with kernel privileges.
{
"affected": [],
"aliases": [
"CVE-2020-9990"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-22T19:15:00Z",
"severity": "HIGH"
},
"details": "A race condition was addressed with additional validation. This issue is fixed in macOS Catalina 10.15.6. A malicious application may be able to execute arbitrary code with kernel privileges.",
"id": "GHSA-cqpw-mc9f-6gf5",
"modified": "2022-05-24T17:32:09Z",
"published": "2022-05-24T17:32:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9990"
},
{
"type": "WEB",
"url": "https://support.apple.com/kb/HT211289"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CR4C-368C-2FC2
Vulnerability from github – Published: 2022-05-17 02:37 – Updated: 2022-05-17 02:37Xen 4.7.x and earlier does not properly honor CR0.TS and CR0.EM, which allows local x86 HVM guest OS users to read or modify FPU, MMX, or XMM register state information belonging to arbitrary tasks on the guest by modifying an instruction while the hypervisor is preparing to emulate it.
{
"affected": [],
"aliases": [
"CVE-2016-7777"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-10-07T14:59:00Z",
"severity": "MODERATE"
},
"details": "Xen 4.7.x and earlier does not properly honor CR0.TS and CR0.EM, which allows local x86 HVM guest OS users to read or modify FPU, MMX, or XMM register state information belonging to arbitrary tasks on the guest by modifying an instruction while the hypervisor is preparing to emulate it.",
"id": "GHSA-cr4c-368c-2fc2",
"modified": "2022-05-17T02:37:04Z",
"published": "2022-05-17T02:37:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-7777"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201611-09"
},
{
"type": "WEB",
"url": "https://support.citrix.com/article/CTX217363"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/93344"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1036942"
},
{
"type": "WEB",
"url": "http://xenbits.xen.org/xsa/advisory-190.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CR4X-C6Q2-VC47
Vulnerability from github – Published: 2022-05-17 05:11 – Updated: 2022-05-17 05:11Race condition on Cisco Adaptive Security Appliances (ASA) devices allows remote attackers to cause a denial of service (CPU consumption or device reload) by establishing multiple connections, leading to improper handling of hash lookups for secondary flows, aka Bug IDs CSCue31622 and CSCuc71272.
{
"affected": [],
"aliases": [
"CVE-2012-5415"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-04-16T14:04:00Z",
"severity": "MODERATE"
},
"details": "Race condition on Cisco Adaptive Security Appliances (ASA) devices allows remote attackers to cause a denial of service (CPU consumption or device reload) by establishing multiple connections, leading to improper handling of hash lookups for secondary flows, aka Bug IDs CSCue31622 and CSCuc71272.",
"id": "GHSA-cr4x-c6q2-vc47",
"modified": "2022-05-17T05:11:40Z",
"published": "2022-05-17T05:11:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5415"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2012-5415"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.