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.
3186 vulnerabilities reference this CWE, most recent first.
GHSA-J5GJ-G4CC-754W
Vulnerability from github – Published: 2023-04-06 18:30 – Updated: 2023-04-12 21:30In display drm, there is a possible double free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07570826; Issue ID: ALPS07570826.
{
"affected": [],
"aliases": [
"CVE-2023-20686"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-06T18:15:00Z",
"severity": "MODERATE"
},
"details": "In display drm, there is a possible double free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07570826; Issue ID: ALPS07570826.",
"id": "GHSA-j5gj-g4cc-754w",
"modified": "2023-04-12T21:30:20Z",
"published": "2023-04-06T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20686"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/April-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J5GQ-897M-2RFF
Vulnerability from github – Published: 2025-12-10 21:31 – Updated: 2025-12-10 21:31Description
In the Okta Java SDK, race conditions may arise from concurrent requests using the ApiClient class. This could cause a status code or response header from one request’s response to influence another request’s response.
Affected product and versions
You may be affected if you meet the following preconditions: - Using the Okta Java SDK between versions 11.0.0 and 20.0.0, and - Implementing a multithreaded application with the ApiClient class where the response status code is used in access control flows
Resolution
Upgrade Okta/okta-sdk-java to versions 21.0.0 or greater.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 20.0.0"
},
"package": {
"ecosystem": "Maven",
"name": "com.okta.sdk:okta-sdk-root"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "20.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-67505"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-10T21:31:52Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Description\nIn the Okta Java SDK, race conditions may arise from concurrent requests using the ApiClient class. This could cause a status code or response header from one request\u2019s response to influence another request\u2019s response.\n\n\n### Affected product and versions\nYou may be affected if you meet the following preconditions:\n- Using the Okta Java SDK between versions 11.0.0 and 20.0.0, and\n- Implementing a multithreaded application with the ApiClient class where the response status code is used in access control flows\n\n### Resolution\nUpgrade Okta/okta-sdk-java to versions 21.0.0 or greater.",
"id": "GHSA-j5gq-897m-2rff",
"modified": "2025-12-10T21:31:52Z",
"published": "2025-12-10T21:31:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/okta/okta-sdk-java/security/advisories/GHSA-j5gq-897m-2rff"
},
{
"type": "WEB",
"url": "https://github.com/okta/okta-sdk-java/commit/abf4f128a0441f90cb7efcdcf4bde1aef8703243"
},
{
"type": "PACKAGE",
"url": "https://github.com/okta/okta-sdk-java"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Race condition in the Okta Java SDK"
}
GHSA-J5V2-R4PG-J7H4
Vulnerability from github – Published: 2024-05-01 15:30 – Updated: 2025-09-18 18:30In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race when detecting delalloc ranges during fiemap
For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc).
This however introduced a race that makes us miss delalloc ranges for file regions that are currently holes, so the caller of fiemap will not be aware that there's data for some file regions. This can be quite serious for some use cases - for example in coreutils versions before 9.0, the cp program used fiemap to detect holes and data in the source file, copying only regions with data (extents or delalloc) from the source file to the destination file in order to preserve holes (see the documentation for its --sparse command line option). This means that if cp was used with a source file that had delalloc in a hole, the destination file could end up without that data, which is effectively a data loss issue, if it happened to hit the race described below.
The race happens like this:
1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that has delalloc in the file range [64M, 65M[, which is currently a hole;
2) Fiemap locks the inode in shared mode, then starts iterating the inode's subvolume tree searching for file extent items, without having the whole fiemap target range locked in the inode's io tree - the change introduced recently by commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking"). It only locks ranges in the io tree when it finds a hole or prealloc extent since that commit;
3) Note that fiemap clones each leaf before using it, and this is to avoid deadlocks when locking a file range in the inode's io tree and the fiemap buffer is memory mapped to some file, because writing to the page with btrfs_page_mkwrite() will wait on any ordered extent for the page's range and the ordered extent needs to lock the range and may need to modify the same leaf, therefore leading to a deadlock on the leaf;
4) While iterating the file extent items in the cloned leaf before finding the hole in the range [64M, 65M[, the delalloc in that range is flushed and its ordered extent completes - meaning the corresponding file extent item is in the inode's subvolume tree, but not present in the cloned leaf that fiemap is iterating over;
5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in the cloned leaf (or a file extent item with disk_bytenr == 0 in case the NO_HOLES feature is not enabled), it will lock that file range in the inode's io tree and then search for delalloc by checking for the EXTENT_DELALLOC bit in the io tree for that range and ordered extents (with btrfs_find_delalloc_in_range()). But it finds nothing since the delalloc in that range was already flushed and the ordered extent completed and is gone - as a result fiemap will not report that there's delalloc or an extent for the range [64M, 65M[, so user space will be mislead into thinking that there's a hole in that range.
This could actually be sporadically triggered with test case generic/094 from fstests, which reports a missing extent/delalloc range like this:
generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad) --- tests/generic/094.out 2020-06-10 19:29:03.830519425 +0100 +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad 2024-02-28 11:00:00.381071525 +0000 @@ -1,3 +1,9 @@ QA output created by 094 fiemap run with sync fiemap run without sync +ERROR: couldn't find extent at 7 +map is 'HHDDHPPDPHPH' +logical: [ 5.. 6] phys: ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-27080"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-01T13:15:51Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race when detecting delalloc ranges during fiemap\n\nFor fiemap we recently stopped locking the target extent range for the\nwhole duration of the fiemap call, in order to avoid a deadlock in a\nscenario where the fiemap buffer happens to be a memory mapped range of\nthe same file. This use case is very unlikely to be useful in practice but\nit may be triggered by fuzz testing (syzbot, etc).\n\nThis however introduced a race that makes us miss delalloc ranges for\nfile regions that are currently holes, so the caller of fiemap will not\nbe aware that there\u0027s data for some file regions. This can be quite\nserious for some use cases - for example in coreutils versions before 9.0,\nthe cp program used fiemap to detect holes and data in the source file,\ncopying only regions with data (extents or delalloc) from the source file\nto the destination file in order to preserve holes (see the documentation\nfor its --sparse command line option). This means that if cp was used\nwith a source file that had delalloc in a hole, the destination file could\nend up without that data, which is effectively a data loss issue, if it\nhappened to hit the race described below.\n\nThe race happens like this:\n\n1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that\n has delalloc in the file range [64M, 65M[, which is currently a hole;\n\n2) Fiemap locks the inode in shared mode, then starts iterating the\n inode\u0027s subvolume tree searching for file extent items, without having\n the whole fiemap target range locked in the inode\u0027s io tree - the\n change introduced recently by commit b0ad381fa769 (\"btrfs: fix\n deadlock with fiemap and extent locking\"). It only locks ranges in\n the io tree when it finds a hole or prealloc extent since that\n commit;\n\n3) Note that fiemap clones each leaf before using it, and this is to\n avoid deadlocks when locking a file range in the inode\u0027s io tree and\n the fiemap buffer is memory mapped to some file, because writing\n to the page with btrfs_page_mkwrite() will wait on any ordered extent\n for the page\u0027s range and the ordered extent needs to lock the range\n and may need to modify the same leaf, therefore leading to a deadlock\n on the leaf;\n\n4) While iterating the file extent items in the cloned leaf before\n finding the hole in the range [64M, 65M[, the delalloc in that range\n is flushed and its ordered extent completes - meaning the corresponding\n file extent item is in the inode\u0027s subvolume tree, but not present in\n the cloned leaf that fiemap is iterating over;\n\n5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in\n the cloned leaf (or a file extent item with disk_bytenr == 0 in case\n the NO_HOLES feature is not enabled), it will lock that file range in\n the inode\u0027s io tree and then search for delalloc by checking for the\n EXTENT_DELALLOC bit in the io tree for that range and ordered extents\n (with btrfs_find_delalloc_in_range()). But it finds nothing since the\n delalloc in that range was already flushed and the ordered extent\n completed and is gone - as a result fiemap will not report that there\u0027s\n delalloc or an extent for the range [64M, 65M[, so user space will be\n mislead into thinking that there\u0027s a hole in that range.\n\nThis could actually be sporadically triggered with test case generic/094\nfrom fstests, which reports a missing extent/delalloc range like this:\n\n generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad)\n --- tests/generic/094.out\t2020-06-10 19:29:03.830519425 +0100\n +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad\t2024-02-28 11:00:00.381071525 +0000\n @@ -1,3 +1,9 @@\n QA output created by 094\n fiemap run with sync\n fiemap run without sync\n +ERROR: couldn\u0027t find extent at 7\n +map is \u0027HHDDHPPDPHPH\u0027\n +logical: [ 5.. 6] phys:\n---truncated---",
"id": "GHSA-j5v2-r4pg-j7h4",
"modified": "2025-09-18T18:30:21Z",
"published": "2024-05-01T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27080"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/49d640d2946c35a17b051d54171a032dd95b0f50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/978b63f7464abcfd364a6c95f734282c50f3decf"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ced63fffd63072c0ca55d5a451010d71bf08c0b3"
}
],
"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-J5VW-CW8P-7F7G
Vulnerability from github – Published: 2026-09-09 12:32 – Updated: 2026-09-09 12:32PasswordPusher before 2.11.1 contains a time-of-check-to-time-of-use race condition in view limit enforcement that allows unauthenticated attackers to bypass expire_after_views limits. Attackers can send concurrent requests to the show endpoint to access one-time secrets multiple times before the view count is incremented and the push expires.
{
"affected": [],
"aliases": [
"CVE-2026-87816"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-09T12:17:16Z",
"severity": "HIGH"
},
"details": "PasswordPusher before 2.11.1 contains a time-of-check-to-time-of-use race condition in view limit enforcement that allows unauthenticated attackers to bypass expire_after_views limits. Attackers can send concurrent requests to the show endpoint to access one-time secrets multiple times before the view count is incremented and the push expires.",
"id": "GHSA-j5vw-cw8p-7f7g",
"modified": "2026-09-09T12:32:15Z",
"published": "2026-09-09T12:32:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pglombardo/PasswordPusher/security/advisories/GHSA-6q3c-57pp-wvpp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87816"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/passwordpusher-before-2.11.1-race-condition-view-limit-bypass"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/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-J5XM-8FGH-W49X
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 Windows Push Notifications allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-42979"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T17:17:13Z",
"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-j5xm-8fgh-w49x",
"modified": "2026-06-09T18:30:45Z",
"published": "2026-06-09T18:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42979"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-42979"
}
],
"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-J65R-8HRG-QC6X
Vulnerability from github – Published: 2024-04-09 03:30 – Updated: 2025-11-04 21:31An attacker can make the Node.js HTTP/2 server completely unavailable by sending a small amount of HTTP/2 frames packets with a few HTTP/2 frames inside. It is possible to leave some data in nghttp2 memory after reset when headers with HTTP/2 CONTINUATION frame are sent to the server and then a TCP connection is abruptly closed by the client triggering the Http2Session destructor while header frames are still being processed (and stored in memory) causing a race condition.
{
"affected": [],
"aliases": [
"CVE-2024-27983"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-09T01:15:49Z",
"severity": "HIGH"
},
"details": "An attacker can make the Node.js HTTP/2 server completely unavailable by sending a small amount of HTTP/2 frames packets with a few HTTP/2 frames inside. It is possible to leave some data in nghttp2 memory after reset when headers with HTTP/2 CONTINUATION frame are sent to the server and then a TCP connection is abruptly closed by the client triggering the Http2Session destructor while header frames are still being processed (and stored in memory) causing a race condition.",
"id": "GHSA-j65r-8hrg-qc6x",
"modified": "2025-11-04T21:31:23Z",
"published": "2024-04-09T03:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27983"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2319584"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00029.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JDECX4BYZLMM4S4LALN4DPZ2HUTTPLKE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YDVFUH7ACZPYB3BS4SVILNOY7NQU73VW"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240510-0002"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/421644"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/04/03/16"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J68W-7QM9-FJQQ
Vulnerability from github – Published: 2022-05-13 01:03 – Updated: 2025-11-04 18:30Race condition in mm/gup.c in the Linux kernel 2.x through 4.x before 4.8.3 allows local users to gain privileges by leveraging incorrect handling of a copy-on-write (COW) feature to write to a read-only memory mapping, as exploited in the wild in October 2016, aka "Dirty COW."
{
"affected": [],
"aliases": [
"CVE-2016-5195"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-11-10T21:59:00Z",
"severity": "HIGH"
},
"details": "Race condition in mm/gup.c in the Linux kernel 2.x through 4.x before 4.8.3 allows local users to gain privileges by leveraging incorrect handling of a copy-on-write (COW) feature to write to a read-only memory mapping, as exploited in the wild in October 2016, aka \"Dirty COW.\"",
"id": "GHSA-j68w-7qm9-fjqq",
"modified": "2025-11-04T18:30:34Z",
"published": "2022-05-13T01:03:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-5195"
},
{
"type": "WEB",
"url": "https://github.com/torvalds/linux/commit/19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/E7M62SRP6CZLJ4ZXCRZKV4WPLQBSR7DT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NWMDLBWMGZKFHMRJ7QUQVCERP5QHDB6W"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/W3APRVDVPDBXLH4DC5UKZVCR742MJIM3"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/E7M62SRP6CZLJ4ZXCRZKV4WPLQBSR7DT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NWMDLBWMGZKFHMRJ7QUQVCERP5QHDB6W"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/W3APRVDVPDBXLH4DC5UKZVCR742MJIM3"
},
{
"type": "WEB",
"url": "https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5195.html"
},
{
"type": "WEB",
"url": "https://security-tracker.debian.org/tracker/CVE-2016-5195"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20161025-0001"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2016-5195"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2016-11-01.html"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2016-12-01.html"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181107-vcsd"
},
{
"type": "WEB",
"url": "https://www.arista.com/en/support/advisories-notices/security-advisories/1753-security-advisory-0026"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2016-5195"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/40611"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/40616"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/40839"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/40847"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/243144"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:0372"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/cve-2016-5195"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/vulnerabilities/2706661"
},
{
"type": "WEB",
"url": "https://bto.bluecoat.com/security-advisory/sa134"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1384344"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1004418"
},
{
"type": "WEB",
"url": "https://dirtycow.ninja"
},
{
"type": "WEB",
"url": "https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs"
},
{
"type": "WEB",
"url": "https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-c05352241"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbgn03707en_us"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbgn03722en_us"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbgn03742en_us"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbgn03761en_us"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05341463"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05347541"
},
{
"type": "WEB",
"url": "https://h20566.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c05352241"
},
{
"type": "WEB",
"url": "https://help.ecostruxureit.com/display/public/UADCO8x/StruxureWare+Data+Center+Operation+Software+Vulnerability+Fixes"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10176"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10177"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10222"
},
{
"type": "WEB",
"url": "http://fortiguard.com/advisory/FG-IR-16-063"
},
{
"type": "WEB",
"url": "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619"
},
{
"type": "WEB",
"url": "http://kb.juniper.net/InfoCenter/index?page=content\u0026id=JSA10770"
},
{
"type": "WEB",
"url": "http://kb.juniper.net/InfoCenter/index?page=content\u0026id=JSA10774"
},
{
"type": "WEB",
"url": "http://kb.juniper.net/InfoCenter/index?page=content\u0026id=JSA10807"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00034.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00035.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00036.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00038.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00039.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00040.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00045.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00048.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00049.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00050.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00051.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00052.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00053.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00054.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00055.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00056.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00057.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00058.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00063.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00064.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00065.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00066.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00067.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-10/msg00072.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-12/msg00033.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2016-12/msg00100.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00041.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/139277/Kernel-Live-Patch-Security-Notice-LSN-0012-1.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/139286/DirtyCow-Linux-Kernel-Race-Condition.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/139287/DirtyCow-Local-Root-Proof-Of-Concept.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/139922/Linux-Kernel-Dirty-COW-PTRACE_POKEDATA-Privilege-Escalation.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/139923/Linux-Kernel-Dirty-COW-PTRACE_POKEDATA-Privilege-Escalation.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/142151/Kernel-Live-Patch-Security-Notice-LSN-0021-1.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2098.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2105.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2106.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2107.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2110.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2118.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2120.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2124.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2126.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2127.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2128.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2132.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2016-2133.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Aug/35"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20161026-linux"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2016/dsa-3696"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20161207-01-dirtycow-en"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.8.3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/21/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/26/7"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/27/13"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/30/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/11/03/7"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/03/07/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/08/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/08/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/08/7"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/08/8"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/09/4"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/08/15/1"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/539611/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/540252/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/540344/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/540736/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/archive/1/539611/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/archive/1/540252/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/archive/1/540344/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/archive/1/540736/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/93793"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1037078"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3104-1"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3104-2"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3105-1"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3105-2"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3106-1"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3106-2"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3106-3"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3106-4"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3107-1"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-3107-2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J6FW-387G-RW6J
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 Runtime allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-50322"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T18:17:31Z",
"severity": "HIGH"
},
"details": "Concurrent execution using shared resource with improper synchronization (\u0027race condition\u0027) in Windows Runtime allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-j6fw-387g-rw6j",
"modified": "2026-07-14T18:32:15Z",
"published": "2026-07-14T18:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50322"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50322"
}
],
"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-J6GC-4893-QWMP
Vulnerability from github – Published: 2026-08-17 16:36 – Updated: 2026-08-17 16:36Summary
Authenticated users can repeatedly call PUT /api/user/self with language or sidebar_modules while relay requests are consuming quota. The settings path reads a full User snapshot and writes it back through User.Update(), which refreshes Redis with RedisHSetObj and overwrites the Quota field. This can erase concurrent HINCRBY quota deductions and keep cached balance artificially high, allowing calls far beyond the paid quota.
Impact
A low-privileged authenticated user may bypass quota enforcement and cause financial loss to operators. Authentication and pre-consumption use cached quota, while DB/log usage can continue increasing.
Affected Components
- controller/user.go: UpdateSelf language/sidebar_modules branches
- model/user.go: User.Update / UpdateWithTx full snapshot update
- model/user_cache.go: updateUserCache RedisHSetObj full hash write
- model/user.go: GetUserQuota reads Redis cache first
Root Cause
Normal billing uses Redis HINCRBY on user:.Quota, while settings updates use a stale full user snapshot to HSET the entire cache hash, including Quota. These two writers race on the same Redis field.
Patches
This issue is fixed in v1.0.0-rc.16. The fix makes user setting updates field-scoped, prevents stale user snapshots from overwriting accounting fields, and keeps generic user cache refreshes from modifying Quota. Quota cache updates are reserved for atomic quota delta paths or explicit quota synchronization paths.
Workarounds
If upgrading immediately is not possible, operators should temporarily restrict or rate-limit PUT /api/user/self and avoid allowing frequent user setting updates while Redis-backed quota cache is enabled. This is only a mitigation; upgrading is recommended.
Remediation
Upgrade to v1.0.0-rc.16 or later. Deployments with Redis enabled should restart application instances after upgrading so stale in-process code paths are removed.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.0-rc.15"
},
"package": {
"ecosystem": "Go",
"name": "github.com/QuantumNous/new-api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.0-rc.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-64865"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-17T16:36:19Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nAuthenticated users can repeatedly call PUT /api/user/self with language or sidebar_modules while relay requests are consuming quota. The settings path reads a full User snapshot and writes it back through User.Update(), which refreshes Redis with RedisHSetObj and overwrites the Quota field. This can erase concurrent HINCRBY quota deductions and keep cached balance artificially high, allowing calls far beyond the paid quota.\n\n### Impact\nA low-privileged authenticated user may bypass quota enforcement and cause financial loss to operators. Authentication and pre-consumption use cached quota, while DB/log usage can continue increasing.\n\n### Affected Components\n- controller/user.go: UpdateSelf language/sidebar_modules branches\n- model/user.go: User.Update / UpdateWithTx full snapshot update\n- model/user_cache.go: updateUserCache RedisHSetObj full hash write\n- model/user.go: GetUserQuota reads Redis cache first\n\n### Root Cause\nNormal billing uses Redis HINCRBY on user:\u003cid\u003e.Quota, while settings updates use a stale full user snapshot to HSET the entire cache hash, including Quota. These two writers race on the same Redis field.\n\n### Patches\nThis issue is fixed in v1.0.0-rc.16. The fix makes user setting updates field-scoped, prevents stale user snapshots from overwriting accounting fields, and keeps generic user cache refreshes from modifying Quota. Quota cache updates are reserved for atomic quota delta paths or explicit quota synchronization paths.\n\n### Workarounds\nIf upgrading immediately is not possible, operators should temporarily restrict or rate-limit PUT /api/user/self and avoid allowing frequent user setting updates while Redis-backed quota cache is enabled. This is only a mitigation; upgrading is recommended.\n\n### Remediation\nUpgrade to v1.0.0-rc.16 or later. Deployments with Redis enabled should restart application instances after upgrading so stale in-process code paths are removed.",
"id": "GHSA-j6gc-4893-qwmp",
"modified": "2026-08-17T16:36:19Z",
"published": "2026-08-17T16:36:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/QuantumNous/new-api/security/advisories/GHSA-j6gc-4893-qwmp"
},
{
"type": "WEB",
"url": "https://github.com/QuantumNous/new-api/commit/dfc0d6324b40c1d6c2972e524409f933541bfb0f"
},
{
"type": "PACKAGE",
"url": "https://github.com/QuantumNous/new-api"
},
{
"type": "WEB",
"url": "https://github.com/QuantumNous/new-api/releases/tag/v1.0.0-rc.16"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "New API: Redis user quota cache overwrite via PUT /api/user/self allows quota bypass"
}
GHSA-J6M4-FRXH-P4X8
Vulnerability from github – Published: 2022-05-17 05:44 – Updated: 2024-11-19 19:02Race condition in ZEO/StorageServer.py in Zope Object Database (ZODB) before 3.10.0a2 allows remote attackers to cause a denial of service (daemon outage) by establishing and then immediately closing a TCP connection, leading to the accept function having an unexpected return value of None, an unexpected value of None for the address, or an ECONNABORTED, EAGAIN, or EWOULDBLOCK error, a related issue to CVE-2010-3492.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "zodb3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.10.0a2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2010-3495"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-01T16:29:16Z",
"nvd_published_at": "2010-10-19T20:00:00Z",
"severity": "MODERATE"
},
"details": "Race condition in `ZEO/StorageServer.py` in Zope Object Database (ZODB) before 3.10.0a2 allows remote attackers to cause a denial of service (daemon outage) by establishing and then immediately closing a TCP connection, leading to the accept function having an unexpected return value of None, an unexpected value of None for the address, or an ECONNABORTED, EAGAIN, or EWOULDBLOCK error, a related issue to CVE-2010-3492.",
"id": "GHSA-j6m4-frxh-p4x8",
"modified": "2024-11-19T19:02:36Z",
"published": "2022-05-17T05:44:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-3495"
},
{
"type": "WEB",
"url": "https://github.com/zopefoundation/ZODB/commit/cfe16277ef1b5bb094dc79da50b0df1ee1537590"
},
{
"type": "WEB",
"url": "https://bugs.launchpad.net/zodb/+bug/135108"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/zodb3/PYSEC-2010-27.yaml"
},
{
"type": "WEB",
"url": "https://pypi.org/project/ZODB3/3.10.0a2/#a2-2010-05-04"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20111225005929/http://secunia.com/advisories/41755"
},
{
"type": "WEB",
"url": "http://bugs.python.org/issue6706"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2010-12/msg00006.html"
},
{
"type": "WEB",
"url": "http://pypi.python.org/pypi/ZODB3/3.10.0#id1"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/41755"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2010/09/09/6"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2010/09/11/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2010/09/22/3"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2010/09/24/3"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Zope Object Database Denial of Service vulnerability"
}
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.