Total
1978 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-20509 | 1 Cisco | 50 Meraki Mx100, Meraki Mx100 Firmware, Meraki Mx105 and 47 more | 2025-06-04 | 5.8 Medium |
| A vulnerability in the Cisco AnyConnect VPN server of Cisco Meraki MX and Cisco Meraki Z Series Teleworker Gateway devices could allow an unauthenticated, remote attacker to hijack an AnyConnect VPN session or cause a denial of service (DoS) condition for individual users of the AnyConnect VPN service on an affected device. This vulnerability is due to weak entropy for handlers that are used during the VPN authentication process as well as a race condition that exists in the same process. An attacker could exploit this vulnerability by correctly guessing an authentication handler and then sending crafted HTTPS requests to an affected device. A successful exploit could allow the attacker to take over the AnyConnect VPN session from a target user or prevent the target user from establishing an AnyConnect VPN session with the affected device. | ||||
| CVE-2025-48880 | 1 Freescout | 1 Freescout | 2025-06-04 | 6.6 Medium |
| FreeScout is a free self-hosted help desk and shared mailbox. Prior to version 1.8.181, when an administrative account is a deleting a user, there is the the possibility of a race condition occurring. This issue has been patched in version 1.8.181. | ||||
| CVE-2022-34702 | 1 Microsoft | 10 Windows 10, Windows 11, Windows 7 and 7 more | 2025-06-04 | 8.1 High |
| Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability | ||||
| CVE-2024-36615 | 1 Ffmpeg | 1 Ffmpeg | 2025-06-03 | 5.9 Medium |
| FFmpeg n7.0 has a race condition vulnerability in the VP9 decoder. This could lead to a data race if video encoding parameters were being exported, as the side data would be attached in the decoder thread while being read in the output thread. | ||||
| CVE-2022-3328 | 1 Canonical | 2 Snapd, Ubuntu Linux | 2025-06-03 | 7.8 High |
| Race condition in snap-confine's must_mkdir_and_open_with_perms() | ||||
| CVE-2024-22047 | 2 Collectiveidea, Redhat | 2 Audited, Satellite | 2025-06-03 | 3.1 Low |
| A race condition exists in Audited 4.0.0 to 5.3.3 that can result in an authenticated user to cause audit log entries to be attributed to another user. | ||||
| CVE-2025-40909 | 2025-06-03 | 5.9 Medium | ||
| Perl threads have a working directory race condition where file operations may target unintended paths. If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit. The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6 | ||||
| CVE-2022-26765 | 1 Apple | 5 Ipados, Iphone Os, Macos and 2 more | 2025-05-30 | 4.7 Medium |
| A race condition was addressed with improved state handling. This issue is fixed in watchOS 8.6, tvOS 15.5, macOS Monterey 12.4, iOS 15.5 and iPadOS 15.5. A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication. | ||||
| CVE-2024-23651 | 1 Mobyproject | 1 Buildkit | 2025-05-29 | 8.7 High |
| BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. The issue has been fixed in v0.12.5. Workarounds include, avoiding using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options. | ||||
| CVE-2016-20015 | 1 Smokeping | 1 Smokeping | 2025-05-29 | 7.5 High |
| In the ebuild package through smokeping-2.7.3-r1 for SmokePing on Gentoo, the initscript allows the smokeping user to gain ownership of any file, allowing for the smokeping user to gain root privileges. There is a race condition involving /var/lib/smokeping and chown. | ||||
| CVE-2025-46805 | 2025-05-28 | 5.5 Medium | ||
| Screen version 5.0.0 and older version 4 releases have a TOCTOU race potentially allowing to send SIGHUP, SIGCONT to privileged processes when installed setuid-root. | ||||
| CVE-2025-46802 | 2025-05-28 | 6 Medium | ||
| For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session. | ||||
| CVE-2025-48753 | 2025-05-28 | 2.9 Low | ||
| In the anode crate 0.1.0 for Rust, data races can occur in unlock in SpinLock. | ||||
| CVE-2025-48751 | 2025-05-28 | 2.9 Low | ||
| The process_lock crate 0.1.0 for Rust allows data races in unlock. | ||||
| CVE-2025-34027 | 2025-05-28 | N/A | ||
| The Versa Concerto SD-WAN orchestration platform is vulnerable to an authentication bypass in the Traefik reverse proxy configuration, allowing at attacker to access administrative endpoints. The Spack upload endpoint can be leveraged for a Time-of-Check to Time-of-Use (TOCTOU) write in combination with a race condition to achieve remote code execution via path loading manipulation, allowing an unauthenticated actor to achieve remote code execution (RCE).This issue is known to affect Concerto from 12.1.2 through 12.2.0. Additional versions may be vulnerable. | ||||
| CVE-2025-23132 | 2025-05-26 | 4.7 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: f2fs: quota: fix to avoid warning in dquot_writeback_dquots() F2FS-fs (dm-59): checkpoint=enable has some unwritten data. ------------[ cut here ]------------ WARNING: CPU: 6 PID: 8013 at fs/quota/dquot.c:691 dquot_writeback_dquots+0x2fc/0x308 pc : dquot_writeback_dquots+0x2fc/0x308 lr : f2fs_quota_sync+0xcc/0x1c4 Call trace: dquot_writeback_dquots+0x2fc/0x308 f2fs_quota_sync+0xcc/0x1c4 f2fs_write_checkpoint+0x3d4/0x9b0 f2fs_issue_checkpoint+0x1bc/0x2c0 f2fs_sync_fs+0x54/0x150 f2fs_do_sync_file+0x2f8/0x814 __f2fs_ioctl+0x1960/0x3244 f2fs_ioctl+0x54/0xe0 __arm64_sys_ioctl+0xa8/0xe4 invoke_syscall+0x58/0x114 checkpoint and f2fs_remount may race as below, resulting triggering warning in dquot_writeback_dquots(). atomic write remount - do_remount - down_write(&sb->s_umount); - f2fs_remount - ioctl - f2fs_do_sync_file - f2fs_sync_fs - f2fs_write_checkpoint - block_operations - locked = down_read_trylock(&sbi->sb->s_umount) : fail to lock due to the write lock was held by remount - up_write(&sb->s_umount); - f2fs_quota_sync - dquot_writeback_dquots - WARN_ON_ONCE(!rwsem_is_locked(&sb->s_umount)) : trigger warning because s_umount lock was unlocked by remount If checkpoint comes from mount/umount/remount/freeze/quotactl, caller of checkpoint has already held s_umount lock, calling dquot_writeback_dquots() in the context should be safe. So let's record task to sbi->umount_lock_holder, so that checkpoint can know whether the lock has held in the context or not by checking current w/ it. In addition, in order to not misrepresent caller of checkpoint, we should not allow to trigger async checkpoint for those callers: mount/umount/remount/ freeze/quotactl. | ||||
| CVE-2025-22100 | 2025-05-26 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race condition when gathering fdinfo group samples Commit e16635d88fa0 ("drm/panthor: add DRM fdinfo support") failed to protect access to groups with an xarray lock, which could lead to use-after-free errors. | ||||
| CVE-2025-22036 | 1 Linux | 1 Linux Kernel | 2025-05-26 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: exfat: fix random stack corruption after get_block When get_block is called with a buffer_head allocated on the stack, such as do_mpage_readpage, stack corruption due to buffer_head UAF may occur in the following race condition situation. <CPU 0> <CPU 1> mpage_read_folio <<bh on stack>> do_mpage_readpage exfat_get_block bh_read __bh_read get_bh(bh) submit_bh wait_on_buffer ... end_buffer_read_sync __end_buffer_read_notouch unlock_buffer <<keep going>> ... ... ... ... <<bh is not valid out of mpage_read_folio>> . . another_function <<variable A on stack>> put_bh(bh) atomic_dec(bh->b_count) * stack corruption here * This patch returns -EAGAIN if a folio does not have buffers when bh_read needs to be called. By doing this, the caller can fallback to functions like block_read_full_folio(), create a buffer_head in the folio, and then call get_block again. Let's do not call bh_read() with on-stack buffer_head. | ||||
| CVE-2025-22027 | 1 Linux | 1 Linux Kernel | 2025-05-26 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: media: streamzap: fix race between device disconnection and urb callback Syzkaller has reported a general protection fault at function ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer dereference of dev->raw pointer, even though it is checked for NULL in the same function, which means there is a race condition. It occurs due to the incorrect order of actions in the streamzap_disconnect() function: rc_unregister_device() is called before usb_kill_urb(). The dev->raw pointer is freed and set to NULL in rc_unregister_device(), and only after that usb_kill_urb() waits for in-progress requests to finish. If rc_unregister_device() is called while streamzap_callback() handler is not finished, this can lead to accessing freed resources. Thus rc_unregister_device() should be called after usb_kill_urb(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | ||||
| CVE-2023-45864 | 1 Samsung | 14 Exynos 1080, Exynos 1080 Firmware, Exynos 1280 and 11 more | 2025-05-22 | 4 Medium |
| A race condition issue discovered in Samsung Mobile Processor Exynos 9820, 980, 1080, 2100, 2200, 1280, and 1380 allows unintended modifications of values within certain areas. | ||||