Export limit exceeded: 414056 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3292 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-93824 | 1 Linux | 1 Linux Kernel | 2026-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tls: reject the combination of TLS and sockmap TLS and sockmap (BPF psock) integration hides a lot of latent bugs. Bugs which may be more or less relevant for real users but they are definitely exploitable. We could not find anyone actively using this integration so let's reject this config. Adding a TLS socket to a sockmap was already rejected by sk_psock_init() through the inet_csk_has_ulp() check. We need to reject the attempts to configure the TLS keys (rather than adding the ULP itself) because checking prior to the ULP installation is tricky without risking a race with sockmap getting added in parallel (sockmap does not hold the socket lock). This patch is a minimal rejection of the feature. Subsequent patch in the series will do a light dead code removal. Full cleanup would require a major rewrite of the Tx path, we don't need skmsg any more. | ||||
| CVE-2026-93204 | 1 Linux | 1 Linux Kernel | 2026-10-03 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: atomically update mac addresses When a MAC address is updated in batadv_dat_entry_add(), it is done using a simple copy function. A parallel reader might only see parts of this update. In worst case, the reader is transporting the half updated MAC address over the network or is creating an ARP response using it - poisoning the ARP cache. atomic64_t can be used to store the 48 bit of a mac address. A reader will then either see the old mac address or the new one - never a mixture of both. | ||||
| CVE-2026-95384 | 1 Google | 1 Chrome | 2026-10-02 | 5.3 Medium |
| 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) | ||||
| CVE-2026-98115 | 1 Linux | 1 Linux Kernel | 2026-10-02 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: safely drain sessions during logoff SMB3 multichannel allows requests for one session to run on multiple connections. Wait for all channels bound to a session before freeing shared session objects. A deferred byte-range lock remains counted as a running request and only wakes when its file closes. Wake blocked locks during the drain without unpublishing or modifying their file objects. Synchronous CANCEL requests must invoke their cancellation callback to wake pending operations, while CHANGE_NOTIFY completion remains specific to the asynchronous path. Serialize session teardown with channel registration and previous-session cleanup, and use atomic work-state transitions so LOGOFF, CANCEL, and connection teardown invoke cancellation callbacks only once. | ||||
| CVE-2026-104057 | 1 Akhilrex | 1 Podgrab | 2026-10-01 | 7.5 High |
| 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. | ||||
| CVE-2026-103651 | 1 Misp | 1 Misp | 2026-10-01 | N/A |
| 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. | ||||
| CVE-2026-103282 | 1 Ghost | 1 Ghost | 2026-10-01 | 4.3 Medium |
| 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. | ||||
| CVE-2026-47565 | 1 Nvidia | 6 Geforce, Guest Driver, Nvs and 3 more | 2026-09-30 | 6.4 Medium |
| 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. | ||||
| CVE-2026-95280 | 1 Google | 1 Chrome | 2026-09-30 | 7.5 High |
| 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) | ||||
| CVE-2026-79625 | 1 Codesys | 18 Control For Beaglebone Sl, Control For Empc-a/imx6 Sl, Control For Iot2000 Sl and 15 more | 2026-09-30 | 8.1 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. | ||||
| CVE-2026-89099 | 1 Mongodb | 2 Mongodb, Mongodb Server | 2026-09-29 | 7.5 High |
| 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. | ||||
| CVE-2026-101041 | 1 Circl | 1 Vulnerability-lookup | 2026-09-29 | N/A |
| 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). | ||||
| CVE-2026-70582 | 1 Microsoft | 26 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 23 more | 2026-09-28 | 6.4 Medium |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Management Instrumentation allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-100546 | 1 Openclaw | 1 Openclaw | 2026-09-28 | 6.4 Medium |
| 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. | ||||
| CVE-2026-92628 | 1 Gitlab | 1 Gitlab | 2026-09-28 | 3.1 Low |
| 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. | ||||
| CVE-2026-97499 | 1 Linux | 1 Linux Kernel | 2026-09-28 | 5.5 Medium |
| 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). | ||||
| CVE-2026-93220 | 1 Linux | 1 Linux Kernel | 2026-09-26 | N/A |
| 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. | ||||
| CVE-2026-93218 | 1 Linux | 1 Linux Kernel | 2026-09-26 | N/A |
| 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(). | ||||
| CVE-2026-93229 | 1 Linux | 1 Linux Kernel | 2026-09-26 | 7.1 High |
| 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() ] | ||||
| CVE-2026-77633 | 1 Cloudreve | 1 Cloudreve | 2026-09-26 | 7.1 High |
| 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. | ||||