Export limit exceeded: 421036 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (5477 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-16819 | 1 Ibm | 3 Aix, Powervm Vios, Vios | 2026-08-20 | 7.7 High |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to cause a denial of service and compromise data integrity due to a time-of-check time-of-use race condition. | ||||
| CVE-2026-20057 | 1 Cisco | 5 Cisco Utd Snort Ips Engine Software, Cyber Vision, Secure Firewall Threat Defense and 2 more | 2026-08-20 | 5.8 Medium |
| Multiple Cisco products are affected by a vulnerability in the Snort 3 Visual Basic for Applications (VBA) feature which could allow an unauthenticated, remote attacker to cause the Snort 3 Detection Engine to crash. This vulnerability is due to lack of proper error checking when decompressing VBA data. An attacker could exploit this vulnerability by sending a crafted VBA data to the Snort 3 Detection Engine on the targeted device. A successful exploit could allow the attacker to cause the Snort 3 Detection Engine to unexpectedly restart causing a a denial of service (DoS) condition. | ||||
| CVE-2026-66802 | 1 Microsoft | 8 Windows 10 1809, Windows 11 26h1, Windows 11 26h1 and 5 more | 2026-08-20 | 8.1 High |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Device Health Attestation (DHA) allows an unauthorized attacker to execute code over a network. | ||||
| CVE-2026-13346 | 1 Pypa | 1 Pip | 2026-08-20 | 6.5 Medium |
| pip would incorrectly handle doubly-encoded package URLs from indexes allowing for files to be installed to arbitrary locations on disk even when installing wheels. This vulnerability requires downloading or installing a package from a malicious package index to succeed, malicious packages alone are not able to exploit this vulnerability. Note that this vulnerability only materially impacts users running `pip download` with the `--only-binary` option as installing source distributions from an untrusted index is already an unsafe operation that executes code during install time. | ||||
| CVE-2024-13942 | 1 Rockchip | 1 Rk3588s | 2026-08-20 | 7.6 High |
| Secure BootROM of RK3588s SoC is vulnerable to a time-of-check to time-of-use attack in case of booting from external media (SPI NOR or NAND, EMMC or SD). The code reads the header of the next-stage loader twice. The header contains hashes of the executable modules and is signed with a private key, the public part of which is verified against the SHA256 digest blown in the OTP. The first read is only partial and contains only the hashes of the executable modules. The second is complete, including the header signature. Although the header is verified based on the fully read data, the authenticity of the executable modules is checked against the partial data from the first read. An attacker with physical access to a device containing RK3588s SoC can easily modify the next-stage loader data on-the-fly using a low-cost SD-card or SPI NOR/NAND or EMMC emulator. Even a simple ultra low-cost circuit comprising two memory chips (containing the same data but different headers - the original and the modified one) and a multiplexer can be used to carry out an attack. This can lead to arbitrary code execution with the highest privileges available (EL3). This issue affects RK3588s: RK3588s SoC BootROM (secure) 350B20210512V100 and possibly others. As remediation apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable https://www.rock-chips.com/a/en/products/RK35_Series/2022/0926/1660.html | ||||
| CVE-2026-20474 | 2 Mediatek, Mediatek, Inc. | 35 Mt6991, Mt6991 Firmware, Mt6993 and 32 more | 2026-08-19 | 6 Medium |
| In display, there is a possible escalation of privilege due to a race condition. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS11019183; Issue ID: MSV-7758. | ||||
| CVE-2026-74971 | 1 Mozilla | 2 Firefox, Thunderbird | 2026-08-19 | 4.3 Medium |
| Information disclosure in the DOM: UI Events & Focus Handling component. This vulnerability was fixed in Firefox 154, Firefox ESR 140.14, Firefox ESR 153.1, Thunderbird 154, Thunderbird 140.14, and Thunderbird 153.1. | ||||
| CVE-2026-74973 | 1 Mozilla | 2 Firefox, Thunderbird | 2026-08-19 | 4.2 Medium |
| Race condition, use-after-free in the Graphics component. This vulnerability was fixed in Firefox 154, Firefox ESR 115.39, Firefox ESR 140.14, Firefox ESR 153.1, Thunderbird 154, Thunderbird 140.14, and Thunderbird 153.1. | ||||
| CVE-2026-72124 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded. | ||||
| CVE-2026-72123 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Commit f1b4e32aca08 ("can: bcm: use call_rcu() instead of costly synchronize_rcu()") replaced synchronize_rcu() in bcm_delete_rx_op() with call_rcu() and introduced the RX_NO_AUTOTIMER flag. However, this flag check was omitted for thrtimer in the packet rx fast-path. During BCM RX operation teardown, a concurrent RCU reader (bcm_rx_handler) can race and re-arm thrtimer via bcm_rx_update_and_send() after call_rcu() has been scheduled. Once the RCU grace period elapses, bcm_op is freed. The subsequently firing thrtimer then dereferences the deallocated op, causing a UAF. Adding flag checks to the rx fast-path (bcm_rx_update_and_send) does not fully close the TOCTOU race and introduces latency for every CAN frame. Conversely, calling hrtimer_cancel() directly inside the RCU callback (softirq context) is fatal as hrtimer_cancel() can sleep, triggering a "scheduling while atomic" panic. Resolve this by deferring the timer cancellation and memory free to a dedicated unbound workqueue (bcm_wq). The RCU callback now queues a work item to bcm_wq, which safely cancels both timers and deallocates memory in sleepable process context. A dedicated workqueue is used to prevent system-wide WQ saturation and is cleanly flushed/destroyed on module unload to avoid rmmod page faults. Since the deferred work can now outlive the calling context by an unbounded amount, also take a reference on op->sk when it is assigned and drop it only once the deferred work has cancelled both timers, so a socket can no longer be freed out from under a still-armed timer whose callback (bcm_send_to_user()) dereferences op->sk. | ||||
| CVE-2026-72121 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock. | ||||
| CVE-2026-72119 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms. | ||||
| CVE-2026-72115 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net(). | ||||
| CVE-2020-1021 | 1 Microsoft | 10 Windows 10, Windows 10 1507, Windows 10 1607 and 7 more | 2026-08-19 | 7.8 High |
| An elevation of privilege vulnerability exists in Windows Error Reporting (WER) when WER handles and executes files. The vulnerability could allow elevation of privilege if an attacker can successfully exploit it. An attacker who successfully exploited the vulnerability could gain greater access to sensitive information and system functionality. To exploit the vulnerability, an attacker could run a specially crafted application. The security update addresses the vulnerability by correcting the way that WER handles and executes files. | ||||
| CVE-2026-23394 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls. | ||||
| CVE-2026-70667 | 1 Netflix | 1 Lemur | 2026-08-19 | 6.3 Medium |
| Lemur manages TLS certificate creation. Prior to 1.9.3, _validate_revocation_url in lemur/certificates/verify.py checked the original CRL or OCSP URL but the later request could reach a different destination. The CRL requests.get call followed HTTP redirects without validating each Location target, so a public attacker-controlled URL could redirect to loopback, RFC1918, link-local, or instance-metadata addresses. Validation and connection also performed separate DNS resolutions, creating a time-of-check time-of-use window for DNS rebinding on both CRL and OCSP paths. An operator uploading a certificate through POST /api/1/certificates/upload could therefore induce blind internal requests despite the earlier mitigation. The fix disables redirects and pins validated addresses while preserving the correct Host value. This issue is fixed in version 1.9.3. | ||||
| CVE-2026-45742 | 1 Gotenberg | 1 Gotenberg | 2026-08-19 | 7.5 High |
| Gotenberg is a Docker-powered stateless API for PDF files. From 8.10.0 until 8.33.0, the newContext function in pkg/modules/api/context.go starts one errgroup.Go goroutine for each multipart downloadFrom entry and allows those goroutines to concurrently write to the shared ctx.files, ctx.diskToOriginal, and ctx.filesByField maps and slices. Go maps and slices are not safe for concurrent mutation, so a crafted multipart request containing many downloadFrom entries can trigger a data race and terminate the process with a fatal concurrent map writes runtime error. The default configuration enables downloadFrom and disables authentication, allowing an unauthenticated remote attacker to crash an exposed conversion service and cause a denial of service. This issue is fixed in version 8.33.0. | ||||
| CVE-2020-15671 | 1 Mozilla | 1 Firefox Mobile | 2026-08-19 | 3.1 Low |
| When typing in a password under certain conditions, a race may have occured where the InputContext was not being correctly set for the input field, resulting in the typed password being saved to the keyboard dictionary. This vulnerability affects Firefox for Android < 80. | ||||
| CVE-2020-15670 | 1 Mozilla | 4 Firefox, Firefox Esr, Firefox Mobile and 1 more | 2026-08-19 | 8.8 High |
| Mozilla developers reported memory safety bugs present in Firefox for Android 79. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 80, Firefox ESR < 78.2, Thunderbird < 78.2, and Firefox for Android < 80. | ||||
| CVE-2023-29537 | 1 Mozilla | 3 Firefox, Firefox Mobile, Focus | 2026-08-19 | 7.5 High |
| Multiple race conditions in the font initialization could have led to memory corruption and execution of attacker-controlled code. This vulnerability affects Firefox for Android < 112, Firefox < 112, and Focus for Android < 112. | ||||