| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Podgrab contains an unauthenticated denial-of-service vulnerability caused by unsynchronized concurrent access to shared maps (activePlayers and allConnections) in its WebSocket handler, where Wshandler and HandleWebsocketMessages goroutines read and write these maps without a mutex. A remote attacker can open multiple WebSocket connections to the /ws endpoint and send messages in a loop to trigger a Go runtime data race that crashes the process, causing a denial of service that requires operator intervention to restore service. |
| MISP contains a vulnerability in its one-time password (OTP) authentication flow that allows replay of a consumed HOTP (paper) token and rewinding of the token counter.
The HOTP verification logic compared the submitted token against a counter value that was cached in the user's session at the time the password was entered, rather than against the authoritative counter stored in the database. Because the session-cached counter is not updated after a token is successfully consumed, an attacker who holds a valid session (password already submitted) can reuse a previously burned HOTP token. The stale cached counter still matches the replayed token, granting a second successful authentication and effectively rewinding the counter state.
Preconditions:
- The target user has HOTP (paper token) second-factor authentication enabled.
- The attacker possesses a valid session in which the password step has already been completed (the OTP step is pending).
- The attacker has access to at least one HOTP token value (e.g., a paper token list).
Security impact:
- Bypass of the second authentication factor, allowing unauthorized access to a user's MISP account.
- Corruption of the HOTP counter state, potentially invalidating subsequent legitimate tokens or enabling further replays.
Affected versions: <2.5.48. |
| Ghost versions 0.5.0 before 6.23.0 contain a concurrency issue in the staff invitation acceptance mechanism that allows multiple accounts to be created from a single invite token. Attackers can exploit this race condition by submitting concurrent requests with the same invitation token to create duplicate user accounts. |
| NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer where a privileged user could trigger a race condition that leads to an out-of-bounds write. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| Race condition, use-after-free in the Audio/Video component. This vulnerability was fixed in Thunderbird 157 and Firefox 157. |
| Race condition in V8 in Google Chrome prior to 154.0.8037.57 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| Affected products do not properly synchronize access to their monitoring functionality. When multiple clients send concurrent requests, this may lead to incorrect reads or writes, or to corruption of internal memory structures. An authenticated remote attacker with monitoring access can exploit this issue to cause incorrect data processing or a denial-of-service condition. |
| Race condition in Transactions Platform in Google Chrome prior to 154.0.8037.57 allowed a remote attacker to potentially leak sensitive information via a crafted HTML page. (Chromium security severity: Medium) |
| A race condition in the document value layer of MongoDB Server can allow concurrent server threads to operate on the same internal memory without synchronization, leading to memory corruption. An authenticated user holding ordinary read-write privileges on a database may be able to trigger this condition over the normal client protocol, resulting in server termination and potential corruption of process memory with user-influenced content. Successful use of this issue may impact the confidentiality, integrity, and availability of the affected server process. |
| The account recovery (password reset) functionality in the vulnerability-lookup web application contains a time-of-check-to-time-of-use (TOCTOU) race condition in the consumption of single-use recovery tokens. The original implementation verified the token nonce against the stored digest and then consumed (cleared) it in separate database operations. Two concurrent HTTP requests presenting the same valid recovery token could both pass the verification check before either transaction committed, allowing both to set their own password on the target account. The last transaction to commit overwrites the first, enabling an attacker who possesses a valid recovery token to replace the legitimate user's password with one of their choosing.
A secondary defect in the same endpoint (confirm_account) allowed a valid recovery link to be used to set an empty or trivially short password (e.g., three characters). The view handler performed only a manual equality comparison between the two password fields and never invoked the form's validation logic, bypassing the intended minimum-length and complexity constraints.
The affected component is the user account recovery endpoint (/user/confirm_account/<token>) and the associated token verification and consumption logic in the User model (website/models/user.py) and the view layer (website/web/views/user.py). |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Instrumentation allows an authorized attacker to elevate privileges locally. |
| OpenClaw (npm package `openclaw`) versions >= 2026.7.2 and < 2026.9.2 contain a race condition in the Discord realtime voice transcript path. Concurrent control-classified voice transcripts could consume speaker context belonging to another participant after an asynchronous control check, causing a transcript to inherit another speaker's owner status. In Discord agent-proxy voice sessions using the affected realtime control path, an utterance from a non-owner participant could reach the downstream agent boundary marked as owner, so owner-sensitive behavior is applied to the wrong speaker. Exploitation depends on concurrent transcript timing and on the tools and commands available to the affected agent. The issue is fixed in 2026.9.2; as a workaround, disable Discord realtime voice for agents that distinguish owner and non-owner senders. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.6 before 19.2.7, 19.3 before 19.3.3, and 19.4 before 19.4.1 that under a race condition, the MCP search tool's shared state handling could have caused search results to be returned under an incorrect user context. |
| In the Linux kernel, the following vulnerability has been resolved:
coresight: perf: Retrieve path and source from event data
ETM perf callbacks currently use the per-CPU csdev_src pointer, which
can race with updates during device registration and unregistration.
The AUX setup already builds and stores the path in the event data.
Use this path to retrieve the source instead of csdev_src to avoid
the race.
Export coresight_get_source() and add etm_event_get_ctxt_path() to
retrieve the context's path and its source with READ_ONCE() /
WRITE_ONCE() accessors. Give the comments to explain why this
approach is safe when pause or resume callbacks preempt the disable
callback (e.g. via NMI). |
| In the Linux kernel, the following vulnerability has been resolved:
sched_ext: Keep kick_sync waiting on the rq's own CPU
kick_sync_wait_bal_cb() assumes it runs on the rq's CPU from the
__schedule() tail: the snapshots it compares against live in that CPU's
percpu area and the busy-wait runs with the rq lock dropped and IRQs
enabled.
However, dispatch can now drop the rq lock while the callback sits queued,
and rq lock takers in that window (the sched class change paths, the scx
task iterator) flush pending balance callbacks on release, running the
callback on a foreign CPU. Such a run compares against unrelated snapshots
and can deadlock when the executing CPU is itself a wait target.
Bail on a foreign CPU and leave the wait state alone. The wait only observes
progress that the resched kicks already guarantee and the rq's next wait
picks up the stale cpus_to_sync bits. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/page_owner: use memcg_data snapshot to avoid TOCTOU in print_page_owner_memcg()
print_page_owner_memcg() reads page->memcg_data via READ_ONCE() at the
start to guard against tail pages and NULL data. However, it later
re-reads page->memcg_data locklessly in two places:
1: page_memcg_check(page)
2: PageMemcgKmem(page) (via folio_memcg_kmem(), which includes
VM_BUG_ON assertions for tail pages and MEMCG_DATA_OBJEXTS)
If the page is concurrently freed and reallocated as a THP tail page or
slab page between these calls, the VM_BUG_ON assertions can trigger on
CONFIG_DEBUG_VM=y builds, crashing the kernel.
Fix both TOCTOU issues by using the memcg_data snapshot throughout. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: skip device-private PMDs in madvise_free_huge_pmd
madvise_free_pte_range() checks pmd_trans_huge(*pmd) unlocked, then
madvise_free_huge_pmd() takes pmd_trans_huge_lock(). pmd_is_huge()
returns true for a device-private PMD, so orig_pmd can be device-private
and enter the !pmd_present() branch.
Skip device-private PMDs in that non-present branch and continue to out
before calling pmd_folio(). Downgrade the check to VM_WARN_ON_ONCE() so
an unexpected PMD softleaf logs a warning rather than panicking. Drop the
thp_migration_supported() guard: it expands to
IS_ENABLED(CONFIG_ARCH_SUPPORTS_PMD_SOFTLEAF), and both
pmd_is_migration_entry() and pmd_is_device_private_entry() already return
false when that config is not selected, so the guard suppresses only the
case where the warning would already be silent.
Potential trigger: an HMM-based GPU driver races with madvise(MADV_FREE):
migrate_vma_pages() flips the PMD to a device-private entry between the
caller's pmd_trans_huge() check and the callee's pmd_trans_huge_lock(). |
| In the Linux kernel, the following vulnerability has been resolved:
nfsd: add missing read barrier to rpc_status_get dumpit seqcount retry
The hand-rolled seqcount-like protocol in nfsd_nl_rpc_status_get_dumpit()
is missing a read memory barrier (smp_rmb) before its second counter
check. The standard kernel read_seqcount_retry() includes smp_rmb()
to ensure that all data reads complete before the counter is re-checked.
Without this barrier, on weakly-ordered architectures (ARM, POWER),
the CPU may reorder field reads past the second counter check, making
the retry logic ineffective: it could observe a consistent counter pair
while reading fields that have been concurrently modified by the writer.
Add smp_rmb() before the second counter check to order the field reads
ahead of it, matching the barrier semantics of the standard seqcount
read-side. The begin-side smp_load_acquire() already pairs with the
smp_store_release() in nfsd_dispatch(); with the smp_rmb() now ordering
the field reads, the retry check no longer needs acquire semantics and
reads the counter with a plain READ_ONCE(), as read_seqcount_retry()
does.
[ cel: Use READ_ONCE instead of smp_load_acquire() ] |
| Cloudreve is a self-hosted file management and sharing system. Prior to 4.18.0, PrepareUpload in pkg/filemanager/fs/dbfs/upload.go checks a stale in-memory user storage value through validateUserCapacity and later applies an unconditional storage charge outside the same quota-enforcing transaction. An authenticated user with Files.Write permission can issue concurrent upload-session requests that read the same capacity snapshot, all pass the MaxStorage check, and reserve their declared sizes through CommitWithStorageDiff. The resulting reservations can exceed the account quota and can be materialized as chunked uploads that exhaust host storage and deny uploads to other users. The default local-storage policy and default User group are affected. This issue is fixed in version 4.18.0. |
| In the Linux kernel, the following vulnerability has been resolved:
net: net_failover: Fix the deadlock in net_failover_slave_name_change()
This is a sibling fix of commit
b84c5632c7b3 ("net: net_failover: Fix the deadlock in slave register").
There is netdev_lock_ops() in the upper callers, so using netif_open()
instead of dev_open().
Call Trace:
__schedule+0x2bb/0x650
schedule+0x27/0xb0
schedule_preempt_disabled+0x15/0x30
__mutex_lock.constprop.0+0x550/0xaf0
__mutex_lock_slowpath+0x13/0x20
mutex_lock+0x3b/0x50
dev_open+0x3b/0xe0
net_failover_slave_name_change+0x22/0x40
failover_event+0xd4/0x1e0
notifier_call_chain+0x62/0xf0
raw_notifier_call_chain+0x16/0x30
call_netdevice_notifiers_info+0x50/0x80
netif_change_name+0x200/0x330
do_setlink.isra.0+0xb12/0xdf0
? security_capable+0x9a/0x1e0
? ns_capable+0x31/0x60
rtnl_setlink+0x302/0x670
? netlink_recvmsg+0x296/0x340
? security_capable+0x9a/0x1e0
? __pfx_rtnl_setlink+0x10/0x10
rtnetlink_rcv_msg+0x384/0x460
? __pfx_rtnetlink_rcv_msg+0x10/0x10
netlink_rcv_skb+0x61/0x120
rtnetlink_rcv+0x15/0x30
netlink_unicast+0x28f/0x3c0
netlink_sendmsg+0x216/0x450
__sys_sendto+0x222/0x230
__x64_sys_sendto+0x24/0x40
x64_sys_call+0x1d5d/0x2390
do_syscall_64+0x105/0x5a0
? do_syscall_64+0x140/0x5a0
? exc_page_fault+0x94/0x1e0
entry_SYSCALL_64_after_hwframe+0x76/0x7e |
