Export limit exceeded: 408462 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (408462 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-107153 | 2026-10-15 | N/A | ||
| Multiple smartphones provided by Rakuten Mobile, Inc. utilize AOSP test keys for their Android Verified Boot (AVB) functionality. With physical access to the affected device, a crafted system image may be installed. | ||||
| CVE-2026-107319 | 2026-10-15 | 4.3 Medium | ||
| The GamiPress WordPress plugin before 8.0.6 does not perform a capability check or ownership verification on one of its authenticated AJAX actions, allowing any authenticated user, such as a Subscriber, to read arbitrary entries from its activity log, including other users' points balances and earned achievements and the usernames of the administrators who performed manual point award and revoke actions. | ||||
| CVE-2025-13465 | 1 Lodash | 1 Lodash | 2026-10-15 | 5.3 Medium |
| The _.unset and _.omit functions in Lodash are vulnerable to prototype pollution. An attacker can pass crafted paths which cause Lodash to delete methods from global prototypes. The issue permits deletion of properties but does not allow overwriting their original behavior. The issue is patched from 4.17.23 to 4.18.0 depending on the package: lodash, lodash-es, and lodash-amd in 4.17.23, and the standalone lodash.unset and lodash.omit packages in 4.18.0. | ||||
| CVE-2026-19198 | 1 Akaunting | 1 Akaunting | 2026-10-15 | N/A |
| Akaunting 3.1.21 contains an authenticated improper authorization vulnerability in the common BulkActions dispatcher.This issue affects Akaunting: 3.1.21. | ||||
| CVE-2026-58098 | 2026-10-15 | N/A | ||
| When semop(2) blocks waiting for a semaphore condition, it releases the per-set lock and sleeps. Upon waking, it checks the sequence number embedded in the semaphore set's IPC identifier to detect whether the set was removed while the caller was asleep. This sequence number is only 15 bits wide. If enough semaphore sets are created and destroyed in the same table slot while a caller is blocked, the counter wraps around, and semop(2) may falsely conclude that the original set still exists. The subsequent access to a semaphore within the set may then be out of bounds. An unprivileged local user can trigger an out-of-bounds access on kernel heap memory, potentially leading to privilege escalation. | ||||
| CVE-2026-85000 | 2026-10-15 | 5.3 Medium | ||
| The EmbedPress WordPress plugin before 4.6.8 does not perform any capability or nonce check on an unauthenticated request that triggers a server-side, credential-bearing request to a third-party API and stores attacker-controlled cache entries, allowing unauthenticated attackers to consume the site owner's third-party API quota and write unbounded records into the site's database. | ||||
| CVE-2026-86799 | 2026-10-15 | 8.8 High | ||
| The Forms WordPress plugin before 3.0.2 does not sanitise submitted form values on storage, nor escape them before outputting them on the form submissions screen in the administration dashboard, allowing unauthenticated users to inject arbitrary web scripts that will execute in the browser of any administrator viewing the submissions. | ||||
| CVE-2026-94261 | 2026-10-15 | 5.3 Medium | ||
| The Sifalo Pay WordPress plugin before 2.5.3 does not verify that a payment transaction identifier belongs to the order it is confirming, nor that the requester owns that order, allowing unauthenticated attackers holding one valid transaction identifier from a payment of their own to mark arbitrary pending orders as paid. | ||||
| CVE-2026-107171 | 2026-10-15 | N/A | ||
| An Hardcoded Cryptographic Key vulnerability existed in Trellix Agent 5.8.4 via mfecryptc.dll leads to Database Decryption by Regular Users. | ||||
| CVE-2026-98406 | 1 Linux | 1 Linux Kernel | 2026-10-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: avoid WARN in set_bitrate_mask when sdata not in driver ieee80211_set_bitrate_mask() checks if the interface is running via ieee80211_sdata_running(), but it does not check if the interface is still present in the driver. When sdata is running but IEEE80211_SDATA_IN_DRIVER is not set, the call reaches drv_set_bitrate_mask() in driver-ops.h which hits wlan1: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.h:884 at drv_set_bitrate_mask Syzkaller triggers this via wext SIOCSIWRATE ioctl. The Call Trace shows wext_ioctl_dispatch() in wext-core.c dispatching the ioctl, calling ioctl_standard_call() for SIOCSIWRATE, which calls cfg80211_wext_siwrate() in wext-compat.c. That builds a bitrate mask and calls rdev_set_bitrate_mask() which ends up in ieee80211_set_bitrate_mask() in cfg.c. The interface is marked running via SDATA_STATE_RUNNING but flags is 0, so check_sdata_in_driver() fails. When the interface is being torn down, or when wext ioctl is issued during interface bringup before drv_add_interface() sets IN_DRIVER, the running check passes while IN_DRIVER is clear. Check IEEE80211_SDATA_IN_DRIVER in ieee80211_set_bitrate_mask() before calling the driver, returning -ENETDOWN. This avoids the WARN_ONCE in driver-ops.h and matches other cfg.c operations that bail early when not in driver. This change should be safe because wiphy mutex is held in cfg80211_wext_siwrate() via guard(wiphy), and IN_DRIVER is set/cleared under RTNL and wiphy paths in drv_add_interface() and drv_remove_interface() in driver-ops.c, so the check is race-free against driver add/remove. Returning -ENETDOWN is the same error other not-running paths use and does not introduce new locking. [also add second syzbot report] | ||||
| CVE-2025-60205 | 2 Themerex, Wordpress | 2 Themerex Addons, Wordpress | 2026-10-15 | 9.8 Critical |
| Deserialization of Untrusted Data vulnerability in ThemeREX Group ThemeREX Addons trx_addons allows Object Injection.This issue affects ThemeREX Addons: from n/a through 2.36.1.1. | ||||
| CVE-2026-96900 | 2026-10-15 | 5.3 Medium | ||
| The Cart Abandonment Recovery for WooCommerce WordPress plugin before 2.1.4 does not verify ownership of the email address used to select an abandoned-cart record before deleting or overwriting it, allowing unauthenticated attackers who know a customer's email to destroy or tamper with that customer's stored abandoned-cart data. | ||||
| CVE-2026-103671 | 2026-10-15 | N/A | ||
| External control of assumed-Immutable web parameter issue exists in EC-CUBE plugin (for EC-CUBE 4 series) "AmazonPay Plugin". If exploited, the user may be redirected to an arbitrary website during the ordering process. As a result, user's account information may be obtained. | ||||
| CVE-2026-86476 | 1 Redhat | 1 Enterprise Linux | 2026-10-15 | 8.4 High |
| A flaw was found in gst-plugins-base. A heap buffer overflow can be triggered when processing video buffers whose attached GstVideoMeta metadata declares plane strides and offsets that exceed the actual backing memory allocation. The metadata is not range-checked during deserialization, and the video frame mapping code does not verify that the declared plane geometry fits within the buffer before allowing consumers to read or write video data. A local attacker who controls the sending side of a GStreamer inter-process IPC pipeline can deliver a crafted buffer carrying fabricated strides, causing the receiving process to read or write beyond heap boundaries. Successful exploitation can cause a denial of service or potentially allow code execution within the affected process. | ||||
| CVE-2026-101301 | 2026-10-15 | 5.3 Medium | ||
| The WPCode WordPress plugin before 2.4.0 does not correctly verify that a request is genuinely for the login screen before entering its snippet safe mode, allowing unauthenticated visitors to disable all of the site's automatically inserted snippets for their own requests. | ||||
| CVE-2026-103308 | 2026-10-15 | 6.5 Medium | ||
| The Visma Pay for WooCommerce WordPress plugin before 1.2.2 does not verify the authenticity of payment gateway return requests, relying on a merchant secret that is empty on a store which has not entered its credentials, allowing unauthenticated attackers to mark arbitrary orders as paid and to disclose the name, email address and postal address of any order's customer. | ||||
| CVE-2026-109968 | 1 Redhat | 2 Enterprise Linux, Openshift | 2026-10-15 | 5.5 Medium |
| A flaw was found in the clevis PKCS#11 pin. The clevis-pkcs11-afunix-socket-unlock daemon logs LUKS disk encryption passphrases in plaintext to a log file. The log file is created without restrictive permissions, making it world-readable under the default process umask. A local attacker can read the log file to obtain the LUKS passphrase. | ||||
| CVE-2026-98394 | 1 Linux | 1 Linux Kernel | 2026-10-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: af_unix: Return immediately when manage_oob() returns NULL for 0-length buffer. Fahad Alharbi reported that recv(0, MSG_PEEK) triggers busy-wait in unix_stream_read_generic() if recv() is blocking and the last skb in the queue is MSG_OOB skb. In such a situation, TCP returns 0 immediately regardless of blocking or non-blocking. Let's follow the behaviour. | ||||
| CVE-2026-98398 | 1 Linux | 1 Linux Kernel | 2026-10-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: locking/lockdep: Invalidate stale class_cache entries for zapped classes syzbot reported a lockdep splat hitting DEBUG_LOCKS_WARN_ON(1) in hlock_class() due to an invalid class_idx: WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203 Workqueue: wg-crypt-wg0 wg_packet_tx_worker RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4870 [inline] RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203 Call Trace: <IRQ> lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5886 _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:173 tcp_tsq_handler+0x29/0x200 net/ipv4/tcp_output.c:1291 tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325 ... When a lock class is zapped (e.g. during module unload or key unregistration), zap_class() clears the class's bit in lock_classes_in_use and removes it from the class hash table. However, existing lockdep_map instances embedded in data structures may still retain a pointer to the zapped class in their class_cache[] array. When __lock_acquire() subsequently runs on such a lock, it finds lock->class_cache[subclass] != NULL, skipping register_lock_class() and assigning hlock->class_idx to the index of the zapped class. When check_wait_context() or hlock_class() inspects the held_lock, it finds !test_bit(class_idx, lock_classes_in_use) and warns. Furthermore, if the zapped slot is subsequently re-allocated to an unrelated lock key, the stale class_cache entry would erroneously match the unrelated class (ABA issue). Add lock_class_cache_is_valid() to validate that the cached class is within lock_classes bounds, still allocated in lock_classes_in_use (using uninstrumented arch_test_bit() in __always_inline context so it is safe in noinstr contexts like match_held_lock()), and that class->key matches the expected subkey (taking lockdep_set_subclass() overrides into account). Also use READ_ONCE()/WRITE_ONCE() when accessing class_cache[]. If the entry is invalid or stale, fall back to register_lock_class() / look_up_lock_class(). | ||||
| CVE-2026-98422 | 1 Linux | 1 Linux Kernel | 2026-10-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown On ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface, but it's never decremented again unless the AP is also brought down. Thus, bringing the same AP_VLAN up again will increment the counter again and eventually hit the sanity check: WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt != master->crypto_tx_tailroom_needed_cnt); Reset it on ifdown to avoid that. | ||||