Race Condition
Race conditions occur when multiple concurrent requests exploit the brief time gap between checking a condition and acting upon it (TOCTOU - Time of Check, Time of Use).
How It Works
Race conditions occur when multiple concurrent requests exploit the brief time gap between checking a condition and acting upon it (TOCTOU - Time of Check, Time of Use). An attacker sends nearly simultaneous requests to manipulate shared state before the application can enforce its business logic. For example, when redeeming a gift voucher, Request A checks the balance, Request B also checks while A is processing, then both complete successfully—redeeming the voucher twice.
Attackers use specialized techniques to achieve precise timing. HTTP/2's multiplexing allows 20-30 requests in a single TCP packet, arriving virtually simultaneously at the server. For HTTP/1.1, "last-byte synchronization" holds back the final byte of multiple requests, then releases them together. These methods reduce network jitter to microseconds, maximizing collision probability.
Advanced attacks include multi-endpoint collisions (hitting different API paths that share state), exploiting partial object construction (accessing resources before initialization completes), and single-endpoint confusion (causing a function to process stale state by overwhelming it with requests).
Impact
- Financial fraud: Redeeming coupons multiple times, withdrawing beyond account balance, applying discounts repeatedly
- Authentication bypass: Reusing CAPTCHA tokens, bypassing rate limits on login attempts, exploiting session validation gaps
- Resource exhaustion: Claiming limited inventory multiple times, booking the same seat/room concurrently
- Data corruption: Simultaneous writes creating inconsistent database states, inventory counts becoming negative
- Access control violations: Exploiting privilege checks to access unauthorized resources during state transitions
Real-World Examples
In 2019, security researchers demonstrated race conditions in major e-commerce platforms allowing users to purchase items at massive discounts by applying the same promotional code dozens of times within milliseconds. The applications checked voucher validity but didn't atomically mark them as used.
TOCTOU vulnerabilities have been found in cryptocurrency exchanges where concurrent withdrawal requests could drain more funds than an account held. Attackers automated HTTP/2 packet timing to submit multiple withdrawal requests before the balance update propagated, essentially duplicating money.
File upload race conditions have enabled remote code execution when attackers upload malicious files and execute them before security scanners complete validation-the check happens, but the file runs before removal.
Mitigation
- Database transactions with row-level locking: Wrap check-and-update logic in ACID transactions with SELECT FOR UPDATE
- Idempotency keys: Require unique request identifiers; reject duplicates within a time window
- Uniqueness constraints: Database-level UNIQUE constraints on critical fields (voucher redemptions, order IDs)
- Atomic operations: Use database built-ins like DECREMENT with bounds checking, compare-and-swap primitives
- Application-level mutexes: Distributed locks (Redis, memcached) around critical sections, ensuring single execution
- Rate limiting per resource: Throttle requests per user AND per target resource (not just per IP)
- Sequence validation: Check monotonically increasing counters or nonces to detect concurrent modification
Recent CVEs (2128)
Multi-thread race condition vulnerability in the card framework module. Impact: Successful exploitation of this vulnerability may affect availability. [CVSS 8.0 HIGH]
Multi-thread race condition vulnerability in the card framework module. Impact: Successful exploitation of this vulnerability may affect availability. [CVSS 8.0 HIGH]
Windows SMB Server denial of service via race condition affects Windows 10 21h2, Windows 11 24h2, and Windows Server 2022, allowing authenticated attackers to disrupt service availability through improper synchronization of shared resources. The vulnerability requires network access and specific conditions to trigger but carries no patch availability at this time. Impact is limited to availability with no confidentiality or integrity compromise.
In the Linux kernel, the following vulnerability has been resolved: functionfs: fix the open/removal races ffs_epfile_open() can race with removal, ending up with file->private_data pointing to freed object.
Local privilege escalation in the Linux kernel's ETS (net/sched) packet scheduler arises from a use-after-free on a struct Qdisc object, caused by a race between ets_qdisc_dequeue and ets_qdisc_change. When bands are reconfigured, a class can retain its entry on the active list after its child qdisc is freed and nulled, letting a concurrent dequeue operate on freed memory. Trend Micro ZDI reports a working reproducer and that an attacker able to create user and network namespaces can trigger the flaw and, per their analysis, control RIP; there is no CISA KEV listing and EPSS is very low (0.05%), so no public evidence of active exploitation.
In the Linux kernel, the following vulnerability has been resolved: usb: phy: fsl-usb: Fix use-after-free in delayed work during device removal The delayed work item otg_event is initialized in fsl_otg_conf() and scheduled under two conditions: 1.
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid updating compression context during writeback Bai, Shuangpeng <sjb7183@psu.edu> reported a bug as below: Oops: divide error: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 11441 Comm: syz.0.46 Not tainted 6.17.0 #1 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:f2fs_all_cluster_page_ready+0x106/0x550 fs/f2fs/compress.c:857 Call Trace: <TASK> f2fs_write_cache_pages fs/f2fs/data.c:3078 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3290 [inline] f2fs_write_data_pages+0x1c19/0x3600 fs/f2fs/data.c:3317 do_writepages+0x38e/0x640 mm/page-writeback.c:2634 filemap_fdatawrite_wbc mm/filemap.c:386 [inline] __filemap_fdatawrite_range mm/filemap.c:419 [inline] file_write_and_wait_range+0x2ba/0x3e0 mm/filemap.c:794 f2fs_do_sync_file+0x6e6/0x1b00 fs/f2fs/file.c:294 generic_write_sync include/linux/fs.h:3043 [inline] f2fs_file_write_iter+0x76e/0x2700 fs/f2fs/file.c:5259 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x7e9/0xe00 fs/read_write.c:686 ksys_write+0x19d/0x2d0 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf7/0x470 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The bug was triggered w/ below race condition: fsync setattr ioctl - f2fs_do_sync_file - file_write_and_wait_range - f2fs_write_cache_pages : inode is non-compressed : cc.cluster_size = F2FS_I(inode)->i_cluster_size = 0 - tag_pages_for_writeback - f2fs_setattr - truncate_setsize - f2fs_truncate - f2fs_fileattr_set - f2fs_setflags_common - set_compress_context : F2FS_I(inode)->i_cluster_size = 4 : set_inode_flag(inode, FI_COMPRESSED_FILE) - f2fs_compressed_file : return true - f2fs_all_cluster_page_ready : "pgidx % cc->cluster_size" trigger dividing 0 issue Let's change as below to fix this issue: - introduce a new atomic type variable .writeback in structure f2fs_inode_info to track the number of threads which calling f2fs_write_cache_pages().
Virtualenv versions up to 20.36.1 is affected by improper link resolution before file access (CVSS 4.5).
Python's filelock SoftFileLock implementation prior to version 3.20.3 contains a TOCTOU race condition that allows local attackers with symlink creation privileges to interfere with lock file operations between permission validation and file creation. An attacker can exploit this window to create a symlink at the target lock path, causing lock operations to fail or redirect to unintended files, resulting in denial of service or unexpected behavior. Upgrade to filelock version 3.20.3 or later to remediate this vulnerability.
In seninf, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. [CVSS 7.0 HIGH]
An issue was discovered in the Camera in Samsung Mobile Processor and Wearable Processor Exynos 1330, 1380, 1480, 2400, 1580, 2500. A race condition in the issimian device driver results in a double free, leading to a denial of service. [CVSS 5.9 MEDIUM]
An issue was discovered in the Camera in Samsung Mobile Processor and Wearable Processor Exynos 1330, 1380, 1480, 2400, 1580, 2500. A race condition in the issimian device driver results in an out-of-bounds access, leading to a denial of service. [CVSS 5.1 MEDIUM]
Race condition in the Purchase Request Handler of PHPEMS up to version 11.0 allows remote attackers to corrupt purchase data integrity under precise timing conditions. Exploitation requires high complexity and many attempts, with limited impact on information disclosure. A public proof-of-concept is available, but no active exploitation has been confirmed.
Race condition in PHPEMS Coupon Handler component up to version 11.0 allows authenticated remote attackers to manipulate coupon processing logic, potentially resulting in integrity compromise. The vulnerability requires high attack complexity and authenticated access, limiting practical exploitation despite publicly available proof-of-concept code. EPSS score of 0.04% indicates low real-world exploitation probability despite public POC availability.
OpenCart versions up to 4.1.0.3 are vulnerable to a race condition in the Single-Use Coupon Handler component that allows remote attackers to perform unauthorized manipulation resulting in information disclosure. The attack requires high complexity and no authentication, with a CVSS score of 2.9 indicating low impact. Publicly available exploit code exists, though the vendor did not respond to early disclosure notification.
Availability impact in the Linux kernel's Intel VPU accelerator driver (accel/ivpu) stems from a race condition between Buffer Object (BO) freeing and context teardown. A local, low-privileged user on a system with Intel VPU/NPU hardware can trigger the ivpu_gem_bo_free() path to remove a BO from the list before it is fully unmapped, causing file_priv_unbind() to encounter an unclean memory manager state and trigger a drm_mm_takedown() warning, ultimately resulting in a kernel availability impact. No public exploit exists and EPSS sits at the 1st percentile, indicating negligible real-world exploitation interest at this time.
Safari and Apple operating systems contain a race condition that crashes the rendering process when processing maliciously crafted web content, affecting Safari 26.2 and earlier, iOS 18.7.3 and earlier, iPadOS 18.7.3 and earlier, macOS Tahoe 26.2 and earlier, tvOS 26.2 and earlier, visionOS 26.2 and earlier, and watchOS 26.2 and earlier. The vulnerability requires user interaction (clicking a malicious link or visiting a hostile website) and has high attack complexity, resulting in denial of service through process crash rather than data compromise. No public exploit code has been identified, EPSS exploitation probability is very low at 0.12%, and Apple has released patched versions across all affected platforms.
A race condition in the Linux kernel timer subsystem allows timer_shutdown_sync() to NULL out a timer's callback function while that timer is still executing on another CPU, leaving a pending timer whose function pointer is NULL and triggering the WARN_ON_ONCE(!fn) check in expire_timers(). The issue affects local, low-privileged code on SMP systems running kernel 6.1.158 or 6.18-rc1 through rc6 that can concurrently invoke a timer-shutdown path during timer expiry, and its practical impact is confined to a kernel warning that only becomes a denial of service when panic_on_warn is enabled - there is no remote vector and no data exposure (independent assessment: CVSS 3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L). No public exploit code identified at time of analysis, EPSS is 0.13% (2nd percentile), and the upstream fix is available as stable-tree commits.
Server-side request forgery in the Fancy Product Designer plugin for WordPress (all versions through 6.4.8) lets unauthenticated remote attackers make the hosting server fetch attacker-chosen internal or external URLs through the fpd_custom_uplod_file AJAX action. The flaw is a time-of-check/time-of-use race condition: the plugin validates the attacker-supplied 'url' parameter with getimagesize() and then re-fetches the same URL with file_get_contents(), so an attacker who controls the responding server can answer the validation request with a legitimate image and then switch to a redirect toward an internal address before the real fetch. Impact is bounded to SSRF on WordPress installations running the affected plugin - independent assessment confirms no code execution, no authentication bypass, and no public exploit identified at time of analysis - and the attacker must control a differential-response server and win the timing window, making this a moderate-priority (CVSS 6.5) issue rather than an emergency.
Privilege escalation in MaxKB 2.3.1 and earlier allows an authenticated, low-privileged user to overwrite the built-in dynamic linker and other critical system files, ultimately enabling code execution in the context of a higher-privileged process. Exploitation requires winning a narrow race condition and a privileged process subsequently loading the overwritten file, which is why the base 7.5 'High' score (AV:N/AC:H/PR:L/UI:N) reflects high impact but non-trivial attack conditions. No public exploit code or confirmed active exploitation was identified at time of analysis, and EPSS is low at 0.35% (26th percentile), so this should be treated as a moderate, not urgent, patch-priority item; version 2.4.0 remediates the flaw.
Sandbox escape and privilege escalation in MaxKB 2.3.1 and earlier allow an attacker who can submit or trigger custom Python tool code to break out of the platform's tool-execution sandbox and operate with elevated privileges, but only when a race condition during ToolExecutor/sandbox initialization is won under concurrent requests. NVD scores the issue 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), while the independent assessment revises it to AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H because tool-module access in typical deployments is authenticated and the exploit depends on a timing race - so practical exploitability is materially lower than the headline score even though the impact once the race succeeds is complete (all three CIA impacts High with Scope:Changed). Exploitation status: no public exploit identified at time of analysis, and EPSS is low at 0.31% (22nd percentile); MaxKB 2.4.0 is the vendor-released fix.
Local privilege escalation on Google Pixel (Tensor) devices stems from a use-after-free race condition in the BIGO hardware video codec driver shipped as private/google-modules/video/gchips/bigo.c, where concurrent codec operations can free memory still referenced by bigo_worker_thread. An unprivileged app that already runs code locally and can reach the BIGO device interface can win the timing window and gain kernel-level execution with high confidentiality and integrity impact, requiring no authentication and no user interaction. Exposure is limited to Pixel/Tensor-class Android devices that ship this module, and because the bug is race-dependent (CVSS AC:H) exploitation typically requires repeated attempts and heap grooming; no public exploit code has been identified at time of analysis.
Local privilege escalation in the Android GXP DSP driver (gxp_main_actor.cc) lets a malicious or already-compromised low-privilege app on Pixel/Tensor devices gain elevated privileges by winning a double-fetch race condition in PrepareWorkloadBuffers, where a shared value is read twice and can be altered in between. Exploitation requires local code execution with at least low privileges (CVSS vector PR:L), needs no user interaction, and is timing-dependent (AC:H), making it probabilistic and unreliable rather than a deterministic attack. No public exploit code or CISA KEV entry was identified at time of analysis, and a patch is available per the vendor advisory (December 2025 Android/Pixel security bulletin).
Okta Java SDK versions 11.0.0 through 20.0.0 allow concurrent ApiClient requests to cross-contaminate response status codes and headers, which can undermine access-control decisions in multithreaded applications. This is a timing-dependent race condition (CWE-362) that is not remotely exploitable against default deployments; exploitation requires an application that invokes ApiClient concurrently and bases authorization on its response status or headers. No public exploit or active exploitation has been identified, and EPSS is low at 0.21%, but a vendor patch is available in version 20.0.1 (GHSA text says 21.0.0+).
Local privilege escalation in the Windows Shell (the shell32/explorer component handling shell operations and namespace objects) lets an authenticated low-privileged attacker who can already run code on a Windows host race a shared resource against a concurrent privileged operation and cross a security boundary, gaining elevated rights on the same machine. The flaw is CWE-362 (improper synchronization / race condition) and carries CVSS 7.8 with Scope:Changed, reflecting that the vulnerable component's flaw impacts a component with different privileges, but the assessed vector (AC:H, PR:L, AV:L) means exploitation is non-deterministic, requires many timing attempts, and no remote or unauthenticated path exists. All supported Windows client and server branches are affected - Windows 10 1607 through 22H2, Windows 11 23H2/24H2/25H2, and Windows Server 2016 through 2025 - and no public exploit code has been identified at time of analysis, with no CISA KEV listing, so real-world risk sits below what the raw 7.8 score suggests in isolation.
Privilege escalation in the Windows Shell lets a low-privileged local attacker who already has code execution on a host defeat the shell's shared-resource synchronization and gain SYSTEM-level rights (scope change, high confidentiality/integrity/availability impact). Exploitation is constrained on three fronts: the attacker must already hold a local foothold (PR:L), must win a timing-sensitive race condition (AC:H per CWE-362), and must wait for a victim to perform a normal shell or file operation that the attacker can race (UI:R). Affected platforms are Windows 10 1809/21H2/22H2, Windows 11 23H2/24H2/25H2, and Windows Server 2019/2022/2022-23H2/2025, with multi-user, RDP, and terminal-server hosts representing the highest-value targets; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Privilege escalation in the Microsoft Brokering File System lets an authenticated local attacker win a race condition (CWE-362) over an improperly synchronized shared resource and elevate to a higher-integrity privileged context on Windows 11 24H2, Windows 11 25H2, and Windows Server 2025. Per the assessed vector (CVSS 7.0, AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H), the attacker must already hold a low-privileged local account or code execution on the target host - there is no remote path and no user interaction - and success is probabilistic because the timing window is narrow, so attempts often need repetition. There is no public exploit identified at time of analysis, the flaw is not confirmed actively exploited (CISA KEV), and Microsoft has published a remediation advisory for the affected builds.
In multiple locations of UsbDataAdvancedProtectionHook.java, there is a possible way to access USB data when the screen is off due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
In multiple locations, there is a possible intent filter bypass due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
A multi-thread race condition in the network management module of Huawei HarmonyOS 5.0.1 lets a local attacker with low-level privileges crash or hang the affected service, degrading availability. Per the assessed vector (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H), exploitation is confined to the local device, requires at least low privileges (for example a malicious or compromised local app), and depends on hitting a narrow, non-deterministic timing window by repeatedly triggering concurrent operations, so success is probabilistic and the impact is denial of service only, with no data exposure or modification. There is no confirmed active exploitation (not in CISA KEV) and no publicly available exploit code identified at time of analysis, and the EPSS score is negligible at roughly 0.01% (1st percentile), making this a low-priority issue despite being a locally exploitable availability flaw.
Information disclosure in Huawei HarmonyOS 5.0.1 and 5.1.0 can be achieved by an authenticated local attacker who exploits a race condition in the network module. The attacker must already have low-privilege code execution on the device and successfully win a timing-dependent concurrency window, which is complex and not guaranteed. No public exploit code has been identified, and the EPSS score is 0.01%, indicating very low exploitation likelihood.
Local attackers can crash or hang the camera service on Huawei HarmonyOS 5.0.1 and 6.0.0 by exploiting a multi-threaded race condition (CWE-362) in the camera framework module. Exploitation requires a low-privilege app already present on the device (PR:L) that repeatedly invokes camera framework operations to hit the narrow timing window; the vector is local-only (AV:L), high complexity (AC:H), and the only impact is availability, with no confidentiality or integrity loss. No public exploit code has been identified at time of analysis and EPSS is 0.01% (0th percentile), so real-world priority is low.
A multi-thread race condition in the Huawei HarmonyOS camera framework module lets a locally installed low-privilege application drive concurrent calls into the camera service and win a narrow timing window, resulting in a denial of service that degrades camera availability on the affected device. Only HarmonyOS 5.0.1, 5.1.0, and 6.0.0 are affected; the issue carries a CVSS 3.1 base score of 4.7 (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H), so confidentiality and integrity are untouched and there is no path to code execution or privilege escalation. There is no public exploit identified at time of analysis and the EPSS score is 0.01% (0th percentile), indicating negligible predicted exploitation activity; exploitation is constrained by the high-complexity, timing-dependent race and by the hard prerequisite that the attacker already execute code locally on the device.
A multi-thread race condition (CWE-362) in the HarmonyOS camera framework can be triggered by a locally installed, low-privileged process on HarmonyOS 5.0.1, 5.1.0 and 6.0.0, causing the camera service to crash or hang and thereby degrading availability. Exploitation requires local code execution plus winning a narrow, timing-dependent window across concurrent threads (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H), so the flaw is not remotely reachable and consistent triggering is difficult; the resulting 4.7 MEDIUM rating is further tempered by an EPSS score of 0.01% (0th percentile). No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and impact is confined to availability with no confidentiality or integrity effect.
Race in v8 in Google Chrome prior to 143.0.7499.41 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)
In aee daemon, there is a possible system crash due to a race condition. This could lead to local denial of service if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS10190802; Issue ID: MSV-4833.
Denial of service (DoS) vulnerability in the office service. Rated medium severity (CVSS 5.3), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
DoS vulnerability in the video-related system service module. Rated high severity (CVSS 7.3), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
UAF vulnerability in the screen recording framework module. Rated high severity (CVSS 8.4), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
An attacker with a Looker Developer role could manipulate a LookML project to exploit a race condition during Git directory deletion, leading to arbitrary command execution on the Looker instance. Rated high severity (CVSS 7.1), this vulnerability is remotely exploitable. No vendor patch available.
In Eclipse Jersey versions 2.45, 3.0.16, 3.1.9 a race condition can cause ignoring of critical SSL configurations - such as mutual authentication, custom key/trust stores, and other security. Rated critical severity (CVSS 9.4), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
Inappropriate implementation in DevTools in Google Chrome prior to 126.0.6478.182 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required. Public exploit code available and no vendor patch available.
Wasmtime is a runtime for WebAssembly. Rated low severity (CVSS 1.8). No vendor patch available.
Linux kernel F2FS filesystem implementation contains a race condition between garbage collection and block allocation that causes segment type inconsistencies, leading to filesystem shutdown. The vulnerability affects systems using F2FS with pinned files during concurrent fallocate and writepage operations. While the EPSS score is low at 0.03%, this is a kernel-level denial of service affecting data availability on affected systems.
Linux kernel block I/O throttling subsystem crashes with a NULL pointer dereference when I/O operations are submitted during early initialization before throttle policy is fully activated, causing denial of service on affected systems. The vulnerability affects the block layer's throttle policy initialization sequence and is triggered sporadically on cold boots when blk_should_throtl() accesses uninitialized throttle group state. With an EPSS score of 0.03% (10th percentile) and no public exploit identified, this is a low-probability but high-impact local crash condition requiring a kernel patch to fully resolve.
Double free in Microsoft Wireless Provisioning System allows an authorized attacker to elevate privileges locally. Rated high severity (CVSS 7.0). No vendor patch available.
Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Wireless Provisioning System allows an authorized attacker to elevate privileges locally. Rated high severity (CVSS 7.0). No vendor patch available.
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges. Rated high severity (CVSS 7.0). No vendor patch available.
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows DirectX allows an authorized attacker to deny service over a network. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable. No vendor patch available.
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Speech allows an authorized attacker to elevate privileges locally. Rated high severity (CVSS 7.0). No vendor patch available.
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Speech allows an authorized attacker to elevate privileges locally. Rated high severity (CVSS 7.0). No vendor patch available.
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows DirectX allows an authorized attacker to elevate privileges locally. Rated high severity (CVSS 7.0). No vendor patch available.
In JetBrains YouTrack before 2025.3.104432 a race condition allowed bypass of helpdesk Agent limit. Rated low severity (CVSS 2.7), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Race condition in the Graphics component. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
Race in Storage in Google Chrome on Windows prior to 142.0.7444.59 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. Rated medium severity (CVSS 4.2), this vulnerability is remotely exploitable, no authentication required. No vendor patch available.
Race in V8 in Google Chrome prior to 142.0.7444.59 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
In JetBrains Hub before 2025.3.104432 information disclosure was possible via the Users API. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
In JetBrains Hub before 2025.3.104432 a race condition allowed bypass of the Agent-user limit. Rated low severity (CVSS 2.7), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
A race condition was addressed with improved state handling. Rated medium severity (CVSS 4.7). No vendor patch available.
A race condition was addressed with additional validation. Rated high severity (CVSS 7.8), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
node-tar 7.5.1 can leak uninitialized process memory into the caller's data stream when the synchronous listing API `.t()` / `.list()` is used with `{ sync: true }` and the tar file on disk is truncated to a smaller size mid-read. A local attacker (or any concurrent process with write access to the archive) must win a narrow race window between the initial size lookup and the parser's read of a truncated 512-byte block boundary, after which the parser can hand back bytes of stale heap memory - potentially unrelated file contents, environment variables, or credentials - instead of tar entry data. Real-world risk is limited: the vector is local (CVSS:3.1/AV:L/AC:H/PR:L/UI:R, CVSS 4.0 base 6.1), EPSS is only 0.13% (3rd percentile), the vulnerability is not in CISA KEV, and a publicly available proof-of-concept reproducer exists in the GitHub advisory (GHSA-29xp-372q-xqph) targeting Node.js 22 or >= 25.1.0; the issue is fixed in 7.5.2.
Race conditions in the ksmbd in-kernel SMB server's RPC handle list (sess->rpc_handle_list XArray) expose systems to use-after-free and kernel availability loss. ksmbd_session_rpc_open() incorrectly acquired only a read lock before performing mutating XArray operations, and ksmbd_session_rpc_method() performed xa_load() with no lock at all - creating a window where concurrent session operations can corrupt or dereference freed memory. No public exploit exists and EPSS is 0.13% (3rd percentile), placing real-world exploitation risk very low, though the use-after-free primitive carries latent potential beyond the scored availability impact.
Local privilege escalation via memory corruption in the Linux kernel's iommufd subsystem allows a low-privileged local user to trigger a use-after-free by racing the abort path of IOMMU object allocation. Because fput() defers file release to a workqueue while the code immediately kfree()s the tied iommufd_object, the deferred release() decrements a users refcount on already-freed memory, corrupting the slab. Only pre-release 6.17-rc kernels are affected; EPSS is 0.10% (1st percentile) and there is no public exploit identified at time of analysis.
An unauthenticated race condition (CWE-362) in Fortinet FortiAnalyzer's FortiCloud SSO authorization logic lets a remote attacker attempt to win a timing-sensitive race and bypass SSO authorization by sending crafted, concurrent FortiCloud SSO requests. Affected builds are 7.6.0 through 7.6.2, 7.4.0 through 7.4.6, 7.2.0 through 7.2.10, and all versions before 7.0.13, and the flaw only matters where FortiCloud SSO is actually configured - deployments using purely local authentication are out of scope. Rated CVSS 5.3 (AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N) with EPSS around 0.32% (22nd percentile), this is a moderate-severity, lower-priority issue rather than a top-tier emergency, and there is no public exploit identified at time of analysis.
A race condition in the audio handler of Tomofun's Furbo 360 dog camera firmware (through FB0035_FW_036) allows a remote attacker who already holds low-privileged authenticated access to repeatedly trigger the audio-handling routine and win a timing window, degrading audio availability. Impact is confined to low availability loss (C:N/I:N/A:L) with no data exposure, integrity impact, or code execution, and the attack requires both authentication and reliable race-condition timing, so real-world priority is low-to-moderate. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; EPSS is 0.30% (21st percentile), and the vendor did not respond to the disclosure.
Race condition in the Linux kernel's AMD IOMMU host page table subsystem (iommu/amd/pgtbl) allows a local low-privileged attacker to cause IOMMU unmap failures and trigger WARN_ON conditions, resulting in a denial of service. The flaw arises because iommu_v1_unmap_pages() calls fetch_pte() to read pgtable->root and pgtable->mode without holding the spinlock, while increase_address_space() updates those fields non-atomically under lock on another CPU, creating a window where the reader observes a torn state (new root, old mode). No active exploitation is confirmed - EPSS stands at 0.10% (1st percentile) and this CVE is not in CISA KEV - making this primarily a kernel stability and reliability concern for systems with AMD IOMMU hardware.
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix deletion race condition System crash when using debug kernel due to link list corruption.
In the Linux kernel, the following vulnerability has been resolved: mm/ksm: fix race with VMA iteration and mm_struct teardown exit_mmap() will tear down the VMAs and maple tree with the mmap_lock held in write mode.
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Check for NOT_READY flag state after locking Currently the check for NOT_READY flag is performed before obtaining the necessary lock.
In the Linux kernel, the following vulnerability has been resolved: zram: fix slot write race condition Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this: CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock() compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle(handle) zram_slot_lock Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix hci_suspend_sync crash If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1 This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix disconnect vs accept race Despite commit 0ad529d9fd2b ("mptcp: fix possible divide by zero in recvmsg()"), the mptcp protocol is still prone to a race between disconnect() (or shutdown) and accept. The root cause is that the mentioned commit checks the msk-level flag, but mptcp_stream_accept() does acquire the msk-level lock, as it can rely directly on the first subflow lock. As reported by Christoph than can lead to a race where an msk socket is accepted after that mptcp_subflow_queue_clean() releases the listener socket lock and just before it takes destructive actions leading to the following splat: BUG: kernel NULL pointer dereference, address: 0000000000000012 PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330 Code: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 <0f> b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89 RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300 RDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a RBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020 R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880 FS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> do_accept+0x1ae/0x260 net/socket.c:1872 __sys_accept4+0x9b/0x110 net/socket.c:1913 __do_sys_accept4 net/socket.c:1954 [inline] __se_sys_accept4 net/socket.c:1951 [inline] __x64_sys_accept4+0x20/0x30 net/socket.c:1951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Address the issue by temporary removing the pending request socket from the accept queue, so that racing accept() can't touch them. After depleting the msk - the ssk still exists, as plain TCP sockets, re-insert them into the accept queue, so that later inet_csk_listen_stop() will complete the tcp socket disposal.
In the Linux kernel, the following vulnerability has been resolved: tracing/synthetic: Fix races on freeing last_cmd Currently, the "last_cmd" variable can be accessed by multiple processes asynchronously when multiple users manipulate synthetic_events node at the same time, it could lead to use-after-free or double-free. This patch add "lastcmd_mutex" to prevent "last_cmd" from being accessed asynchronously. ================================================================ It's easy to reproduce in the KASAN environment by running the two scripts below in different shells. script 1: while : do echo -n -e '\x88' > /sys/kernel/tracing/synthetic_events done script 2: while : do echo -n -e '\xb0' > /sys/kernel/tracing/synthetic_events done ================================================================ double-free scenario: process A process B ------------------- --------------- 1.kstrdup last_cmd 2.free last_cmd 3.free last_cmd(double-free) ================================================================ use-after-free scenario: process A process B ------------------- --------------- 1.kstrdup last_cmd 2.free last_cmd 3.tracing_log_err(use-after-free) ================================================================ Appendix 1. KASAN report double-free: BUG: KASAN: double-free in kfree+0xdc/0x1d4 Free of addr ***** by task sh/4879 Call trace: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x60/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Allocated by task 4879: ... kstrdup+0x5c/0x98 create_or_delete_synth_event+0x6c/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Freed by task 5464: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x60/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... ================================================================ Appendix 2. KASAN report use-after-free: BUG: KASAN: use-after-free in strlen+0x5c/0x7c Read of size 1 at addr ***** by task sh/5483 sh: CPU: 7 PID: 5483 Comm: sh ... __asan_report_load1_noabort+0x34/0x44 strlen+0x5c/0x7c tracing_log_err+0x60/0x444 create_or_delete_synth_event+0xc4/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Allocated by task 5483: ... kstrdup+0x5c/0x98 create_or_delete_synth_event+0x80/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Freed by task 5480: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x74/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ...
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix potential race condition between napi_init and napi_enable A race condition can happen if netdev is registered, but NAPI isn't initialized yet, and meanwhile user space starts the netdev that will enable NAPI. Then, it hits BUG_ON(): kernel BUG at net/core/dev.c:6423! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91 Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022 RIP: 0010:napi_enable+0x3f/0x50 Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ... RSP: 0018:ffffada1414f3548 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000 RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58 R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001 FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8] rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] __dev_open+0xe0/0x180 __dev_change_flags+0x1da/0x250 dev_change_flags+0x26/0x70 do_setlink+0x37c/0x12c0 ? ep_poll_callback+0x246/0x290 ? __nla_validate_parse+0x61/0xd00 ? __wake_up_common_lock+0x8f/0xd0 To fix this, follow Jonas' suggestion to switch the order of these functions and move register netdev to be the last step of PCI probe. Also, correct the error handling of rtw89_core_register_hw().
In the Linux kernel, the following vulnerability has been resolved: ceph: fix race condition validating r_parent before applying state Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes. [ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]
In the Linux kernel, the following vulnerability has been resolved: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver Currently phylink_resolve() protects itself against concurrent phylink_bringup_phy() or phylink_disconnect_phy() calls which modify pl->phydev by relying on pl->state_mutex. The problem is that in phylink_resolve(), pl->state_mutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be acquired prior to pl->state_mutex. But that requires dereferencing pl->phydev in the first place, and without pl->state_mutex, that is racy. Hence the reason for the extra lock. Currently it is redundant, but it will serve a functional purpose once mutex_lock(&phy->lock) will be moved outside of the mutex_lock(&pl->state_mutex) section. Another alternative considered would have been to let phylink_resolve() acquire the rtnl_mutex, which is also held when phylink_bringup_phy() and phylink_disconnect_phy() are called. But since phylink_disconnect_phy() runs under rtnl_lock(), it would deadlock with phylink_resolve() when calling flush_work(&pl->resolve). Additionally, it would have been undesirable because it would have unnecessarily blocked many other call paths as well in the entire kernel, so the smaller-scoped lock was preferred.
Quadient DS-700 iQ devices through 2025-09-30 might have a race condition during the quick clicking of (in order) the Question Mark button, the Help Button, the About button, and the Help Button,. Rated medium severity (CVSS 6.4), this vulnerability is no authentication required. No vendor patch available.
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity.
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Stylemix MasterStudy LMS allows Leveraging Race Conditions.6.20. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
A vulnerability has been found in Smartstore up to 6.2.0. Rated low severity (CVSS 2.3), this vulnerability is remotely exploitable. No vendor patch available.
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Bluetooth Service allows an authorized attacker to elevate privileges locally. Rated high severity (CVSS 7.0). No vendor patch available.
Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Graphics Component allows an authorized attacker to elevate privileges locally. Rated high severity (CVSS 7.0). No vendor patch available.
In the Linux kernel, the following vulnerability has been resolved: f2fs: don't reset unchangable mount option in f2fs_remount() syzbot reports a bug as below: general protection fault, probably for. Rated medium severity (CVSS 4.7).
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between quota enable and quota rescan ioctl When enabling quotas, at btrfs_quota_enable(), after committing the. Rated medium severity (CVSS 4.7).
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race issue between cpu buffer write and swap Warning happened in rb_end_commit() at code: if (RB_WARN_ON(cpu_buffer,. Rated medium severity (CVSS 4.7).
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix potential data race in rxrpc_wait_to_be_connected() Inside the loop in rxrpc_wait_to_be_connected() it checks. Rated medium severity (CVSS 4.7).
In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix race in lowcomms This patch fixes a race between queue_work() in _dlm_lowcomms_commit_msg() and srcu_read_unlock(). Rated medium severity (CVSS 4.7).
In JetBrains TeamCity before 2025.07.2 project isolation bypass was possible due to race condition. Rated medium severity (CVSS 4.2), this vulnerability is remotely exploitable. No vendor patch available.
In the Linux kernel, the following vulnerability has been resolved: workqueue: fix data race with the pwq->stats[] increment KCSAN has discovered a data race in kernel/workqueue.c:2598: [. Rated medium severity (CVSS 4.7).
In the Linux kernel, the following vulnerability has been resolved: power: supply: axp288_fuel_gauge: Fix external_power_changed race fuel_gauge_external_power_changed() dereferences info->bat, which. Rated medium severity (CVSS 4.7).
Quick Facts
- Typical Severity
- MEDIUM
- Category
- web
- Total CVEs
- 2128