Total
2492 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-43770 | 1 Apple | 2 Macos, Tvos | 2026-07-29 | N/A | 4.7 MEDIUM |
| A race condition was addressed with additional validation. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6, tvOS 26.6. An app may be able to access sensitive user data. | |||||
| CVE-2025-10263 | 2026-07-29 | N/A | 9.1 CRITICAL | ||
| Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level. | |||||
| CVE-2026-28926 | 2026-07-29 | N/A | 7.0 HIGH | ||
| A race condition was addressed with improved state handling. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8. An app may be able to elevate privileges. | |||||
| CVE-2026-43728 | 2026-07-28 | N/A | 7.5 HIGH | ||
| This issue was addressed through improved state management. This issue is fixed in macOS Tahoe 26.6. An attacker may be able to modify the state of the Keychain. | |||||
| CVE-2026-43781 | 2026-07-28 | N/A | 4.7 MEDIUM | ||
| A race condition was addressed with improved state handling. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6. An app may be able to access sensitive user data. | |||||
| CVE-2026-43755 | 1 Apple | 1 Macos | 2026-07-28 | N/A | 7.0 HIGH |
| A race condition was addressed with improved state management. This issue is fixed in macOS Sonoma 14.8.8, macOS Tahoe 26.6. An app may be able to gain root privileges. | |||||
| CVE-2026-64720 | 1 Apple | 5 Ipados, Iphone Os, Macos and 2 more | 2026-07-28 | N/A | 9.8 CRITICAL |
| A race condition was addressed with improved state handling. This issue is fixed in iOS 26.6 and iPadOS 26.6, macOS Tahoe 26.6, tvOS 26.6, watchOS 26.6. An app may be able to cause unexpected system termination. | |||||
| CVE-2026-28982 | 1 Apple | 1 Macos | 2026-07-28 | N/A | 9.8 CRITICAL |
| A race condition was addressed with improved locking. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6. A remote user may be able to cause unexpected system termination or corrupt kernel memory. | |||||
| CVE-2026-43805 | 1 Apple | 4 Ipados, Iphone Os, Macos and 1 more | 2026-07-28 | N/A | 9.8 CRITICAL |
| A race condition was addressed with improved state handling. This issue is fixed in iOS 26.6 and iPadOS 26.6, macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6, watchOS 26.6. An app may be able to cause unexpected system termination or write kernel memory. | |||||
| CVE-2026-43811 | 1 Apple | 2 Ipados, Iphone Os | 2026-07-28 | N/A | 4.7 MEDIUM |
| A race condition was addressed with improved checks. This issue is fixed in iOS 26.6 and iPadOS 26.6. An app may be able to modify protected parts of the file system. | |||||
| CVE-2019-16779 | 3 Debian, Excon Project, Opensuse | 4 Debian Linux, Excon, Backports Sle and 1 more | 2026-07-28 | 4.3 MEDIUM | 5.8 MEDIUM |
| In RubyGem excon before 0.71.0, there was a race condition around persistent connections, where a connection which is interrupted (such as by a timeout) would leave data on the socket. Subsequent requests would then read this data, returning content from the previous response. The race condition window appears to be short, and it would be difficult to purposefully exploit this. | |||||
| CVE-2026-62432 | 2026-07-28 | N/A | 7.3 HIGH | ||
| The EVTCHNOP_expand_array hypercall checks for whether FIFO event channels are enabled, but without holding the correct lock. It can race with EVTCHNOP_reset, resulting in dereferencing a NULL pointer. | |||||
| CVE-2026-62430 | 2026-07-28 | N/A | 7.5 HIGH | ||
| Accesses to the CMOS memory contents are done using an indirect IO port pair. Therefore Xen needs to cache the guest chosen index, and one of the usages of the index didn't take the necessary locking to avoid concurrent changes. As a result, a guest could change the index after it being checked, causing a subsequent out-of-bound read access to the contents of an array. | |||||
| CVE-2026-62429 | 2026-07-28 | N/A | 6.5 MEDIUM | ||
| Accessing the vNUMA configuration data of a guest is still possible when domain destruction has already started. The cleaning up of that configuration information is not synchronized with its retrieval by a device model controlling the guest. | |||||
| CVE-2026-43693 | 2026-07-28 | N/A | 7.0 HIGH | ||
| A race condition was addressed with improved state handling. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6. An app may be able to gain root privileges. | |||||
| CVE-2026-62436 | 2026-07-28 | N/A | 6.5 MEDIUM | ||
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away. Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held. The v1 -> v2 issue is CVE-2026-62435. The v2 -> v1 issue is CVE-2026-62436. | |||||
| CVE-2026-62435 | 2026-07-28 | N/A | 6.5 MEDIUM | ||
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away. Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held. The v1 -> v2 issue is CVE-2026-62435. The v2 -> v1 issue is CVE-2026-62436. | |||||
| CVE-2026-45712 | 1 Axllent | 1 Mailpit | 2026-07-28 | N/A | 5.9 MEDIUM |
| Mailpit is an email testing tool and API for developers. Prior to version 1.30.0, the screenshot/print proxy (/proxy?data=…) maintains a package-level assets map[string]MessageAssets cache, but reads the map without holding assetsMutex while a long-running cleanup goroutine and (re-entrant) CSS-rewriting code path concurrently write to it under the lock. When the unsynchronized read coincides with a synchronized write, Go's runtime raises fatal error: concurrent map read and map write — a runtime.throw that is not recoverable by http.Server's handler-panic recover. The whole Mailpit process exits, taking the SMTP, POP3 and HTTP listeners down with it. Version 1.30.0 contains a patch. | |||||
| CVE-2026-43743 | 1 Apple | 3 Ipados, Iphone Os, Macos | 2026-07-27 | N/A | 4.7 MEDIUM |
| A race condition was addressed with improved state handling. This issue is fixed in iOS 26.5.2 and iPadOS 26.5.2, macOS Tahoe 26.5.2, tvOS 26.6, watchOS 26.6. An app may be able to cause unexpected system termination. | |||||
| CVE-2026-10681 | 2026-07-27 | N/A | 6.5 MEDIUM | ||
| In Zephyr's userspace dynamic-objects subsystem, thread_idx_alloc() in kernel/userspace/userspace.c allocated a new thread permission index from the global _thread_idx_map[] bitmap without holding lists_lock. On SMP systems, two user-mode threads invoking the k_object_alloc(K_OBJ_THREAD) syscall concurrently can both observe the same low free bit, perform the same non-atomic RMW to clear it, and return the identical tidx. The two newly created K_OBJ_THREAD objects are then assigned the same thread_id, so the two user threads alias a single bit position in every kernel object's perms[] bitfield: any subsequent grant of access on a kernel object to one thread is implicitly a grant to the other, defeating userspace ACL isolation. A secondary lost-update window between the unlocked &=~BIT() in alloc and the locked |= BIT() in thread_idx_free() can also leak entries from the thread-index pool. The defect is reachable from any user-mode thread via the unrestricted __syscall k_object_alloc and is gated on CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP. The flaw was introduced when the per-thread permission index was added in 2018 and is present in every release up to and including v4.4.0. Fixed by holding lists_lock across the bitmap RMW and the permissions clear (and inlining the obj_list traversal that previously took the lock itself). | |||||