| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| rails-html-sanitizer is responsible for sanitizing HTML fragments in Rails applications. Before 1.7.2, the HTML4 and HTML5 variants of Rails::HTML::SafeListSanitizer reuse one Rails::HTML::PermitScrubber across calls and mutate its tags and attributes without synchronization. In a multithreaded process, concurrent sanitize calls using different tags: or attributes: options can interleave and cause one call to use the other call's allowlist. If a permissive call admits a script element or event-handler attribute, output expected to be sanitized under a stricter policy can retain it and cause cross-site scripting when rendered. Applications that are single-threaded, use one identical allowlist everywhere, or provide a separate scrubber: are not affected. This issue is fixed in version 1.7.2. |
| Concurrent Execution using Shared Resource with Improper Synchronization vulnerability in Apache HTTP Server's mod_http2 in assign_headers() can lead to RCE.
This issue affects Apache HTTP Server: from 2.4.55 through 2.4.70.
Affected releases of mod_h2 from GitHub: from 2.0.8 through 2.0.42. |
| In port_shutdown of ipc.c, there is a possible Use After Free due to a race condition. This could lead to local escalation of privilege with execution privileges needed. User interaction is for exploitation. |
| Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Automattic WooCommerce woocommerce allows Leveraging Race Conditions.This issue affects WooCommerce: from 11.0.0 through 11.2.2. |
| In multiple functions of face_status.h, there is a possible way to modify verified biometric enrollment data in shared memory 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. |
| NocoDB before 2026.08.1 contains a race condition vulnerability in users.service.ts that allows holders of a valid reset token to perform multiple password changes by sending concurrent reset requests. Attackers can exploit the window created by slow bcrypt hashing before the token is cleared to overwrite the owner's new password and lock them out. |
| NocoDB before 2026.08.0 contains a race condition in refresh-token rotation that allows attackers to reuse tokens because UserRefreshToken.ts never checks the affected-row count. Attackers holding a captured refresh token can present it concurrently with the legitimate user to obtain a valid authenticated session, and no reuse event is recorded. |
| NocoDB before 2026.06.2 contains a race condition vulnerability in oauth-token.service.ts that allows attackers to reuse a refresh token by presenting it concurrently during non-atomic rotation. Attackers holding a captured refresh token can race the legitimate client to obtain their own access and refresh tokens, retaining scoped access without triggering reuse detection. |
| OpenMage magento-lts before 20.19.0 and 21.0.0-beta1 before 21.0.0-beta3 contains a race condition in shopping cart price rule usage limits, because Mage_SalesRule_Model_Validator checks coupon limits without locking and the usage counters are later incremented non-atomically. Unauthenticated attackers, including guest shoppers, can submit concurrent checkouts to redeem a limited coupon more times than its cap allows. |
| Paaster is a pastebin application. Prior to version 3.3.0, Paaster's "view once" (burn-after-reading) paste mode can be bypassed with concurrent requests. The check that's supposed to enforce single-use is a plain read followed by a separate write, with no atomicity, so multiple simultaneous requests can all see the paste as "not yet read" and all successfully retrieve it. This issue has been patched in version 3.3.0. |
| Improper access control within the AMD Secure Encrypted Virtualization (SEV) firmware could allow an attacker with administrative privileges to tamper with memory, potentially resulting in loss of guest memory integrity. |
| In handle_chan_msg of tipc_virtio_dev.c, there is a possible way to bypass memory tag access controls via concurrent shared memory modification 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. |
| In multiple locations, there is a possible way to modify authenticated coprocessor firmware in shared memory before loading 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. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: event: Fix event FIFO reset race
`iio_event_getfd()` creates the event file descriptor with
`anon_inode_getfd()`, which allocates a new fd, creates the anonymous
file and installs it in the process fd table before returning to the
caller.
The IIO code resets the event FIFO after `anon_inode_getfd()` has returned,
but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace.
But since fd tables are shared between threads, another thread can guess
the newly allocated fd number and issue a `read()` on it as soon as the fd
has been installed.
This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in
parallel with the `kfifo_reset_out()` in `iio_event_getfd()`.
The kfifo documentation says that `kfifo_reset_out()` is only safe when it
is called from the reader thread and there is only one concurrent reader.
Otherwise it is dangerous and must be handled in the same way as
`kfifo_reset()`.
If that happens, `kfifo_to_user()` can advance the FIFO `out` index based
on state from before the reset, after the reset has already moved the `out`
index to the current `in` index. That can leave the FIFO with an `out`
index past the `in` index. A later `read()` can then see an underflowed
FIFO length and copy more data than the event FIFO buffer contains. This
can result in an out-of-bounds read and leak adjacent kernel memory to
userspace.
Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is
marked busy, but the new fd has not been installed yet, so userspace cannot
access it while the FIFO is reset. |
| The YITH WooCommerce Gift Cards WordPress plugin before 4.38.1 does not lock or atomically update a gift card's balance when it is redeemed at checkout, allowing an attacker who holds a gift card code to spend more than its funded value by submitting multiple checkouts for the same code at the same time. |
| Use after free in Microsoft Trace Data Helper allows an authorized attacker to elevate privileges locally. |
| In affected versions of Progress® Telerik® UI for ASP.NET MVC `2012.2.710` through `2026.3.811`, ClassFactory updates a shared class dictionary without exclusive write protection and emits non-collectible dynamic assemblies that remain loaded for the AppDomain's lifetime. The dictionary lookup and insertion are not atomic, and case variations in aggregate descriptors can produce distinct retained types even though member resolution is case-insensitive. An unauthenticated remote attacker can exploit this if the application exposes an aggregation endpoint that is reachable without authentication, by submitting concurrent or repeated crafted requests. These requests may corrupt dictionary state or increase CPU and memory use, potentially degrading availability. The issue is fixed in version `2026.3.1015`. |
| In the Linux kernel, the following vulnerability has been resolved:
serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ
When uart_flush_buffer() runs before the DMA completion IRQ is delivered,
the following race can occur (all steps serialized by uart_port_lock):
1. DMA starts: tx_remaining = N, kfifo contains N bytes
2. DMA completes in hardware; IRQ is pending but not yet delivered
3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(),
making kfifo_len() = 0 while tx_remaining remains N
4. uart_flush_buffer() releases the port lock
5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls
uart_xmit_advance(uport, tx_remaining) on an empty kfifo
uart_xmit_advance() increments kfifo->out by tx_remaining. Since
kfifo_reset() already set both in and out to 0, out wraps past in,
causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next
start_tx_dma() call then submits a DMA transfer of stale buffer data.
Fix this by snapshotting kfifo_len() at the start of handle_tx_dma()
and skipping uart_xmit_advance() when fifo_len < tx_remaining, which
indicates the kfifo was reset by a preceding flush. |
| In multiple locations, there is a possible use-after-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. |
| Use after free in Windows Win32K allows an authorized attacker to elevate privileges locally. |
