Export limit exceeded: 108083 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (108083 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-9566 | 1 Redhat | 9 Enterprise Linux, Hummingbird, Openshift and 6 more | 2026-11-03 | 8.1 High |
| There's a vulnerability in podman where an attacker may use the kube play command to overwrite host files when the kube file container a Secrete or a ConfigMap volume mount and such volume contains a symbolic link to a host file path. In a successful attack, the attacker can only control the target file to be overwritten but not the content to be written into the file. Binary-Affected: podman Upstream-version-introduced: v4.0.0 Upstream-version-fixed: v5.6.1 | ||||
| CVE-2026-95508 | 1 Redhat | 3 Enterprise Linux, Openshift, Openshift Container Platform | 2026-11-03 | 7.4 High |
| A heap-based buffer overflow was found in the DHCPv6 and TFTP response builders of libslirp. When the host is configured with a small interface MTU, a guest-supplied DHCPv6 CLIENTID option or TFTP blksize option can overflow the reply buffer with attacker-controlled content and length, resulting in denial of service and potentially arbitrary code execution in the host process. The default interface MTU is not affected. | ||||
| CVE-2026-58946 | 1 Google | 1 Android | 2026-11-03 | 8.4 High |
| In navigateUpTo of ActivityClientController.java, there is a possible permission bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-107018 | 2026-11-03 | 8.1 High | ||
| Insecure permissions in Ghost Commander File Manager versionCode 479 allows unauthorized attackers to arbitrarily read and write files inside the commander's private storage. | ||||
| CVE-2026-76955 | 1 Zyxel | 1 Nwa110ax Firmware | 2026-11-03 | 8.8 High |
| A buffer overflow vulnerability in the zdp_wtp binary in Zyxel NWA110AX firmware versions through 7.12(ABTG.0)C0 could allow a LAN-based attacker to escalate privileges on an affected device. | ||||
| CVE-2026-17527 | 1 Redhat | 2 Container Native Virtualization, Openshift Virtualization | 2026-11-03 | 7.7 High |
| In containerized-data-importer (CDI), the aggregated cdi.kubevirt.io:view ClusterRole, intended to provide read-only access to CDI resources, includes a rule granting create on the datavolumes/source subresource. CDI's DataVolume clone authorization accepts this permission as sufficient to authorize cloning the contents of any PVC the caller can name, without requiring write access to the source namespace. A user or service account bound to the view role, commonly granted cluster-wide via ClusterRoleBinding, who also has ordinary write access (edit/admin) to any single namespace, can use this to exfiltrate the contents of any PVC in the cluster into a namespace they control, bypassing namespace isolation and the read-only guarantee of the view role. | ||||
| CVE-2026-107441 | 2026-11-03 | 8.8 High | ||
| An out-of-bounds write vulnerability in the CGI program of Zyxel GS1900-24E firmware versions through 2.90(AAHK.2)C0 could allow an unauthenticated adjacent attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request. | ||||
| CVE-2026-118009 | 1 Mozilla | 1 Firefox | 2026-11-03 | 7.5 High |
| Integer overflow, use-after-free in the Graphics: Text component. This vulnerability was fixed in Firefox 159 and Thunderbird 159. | ||||
| CVE-2026-118012 | 1 Mozilla | 1 Firefox | 2026-11-03 | 7.5 High |
| Use-after-free in the DOM: Animation component. This vulnerability was fixed in Firefox 159 and Thunderbird 159. | ||||
| CVE-2026-107024 | 2026-11-03 | 7.5 High | ||
| Insecure permissions in Share 2 Archive Today versionCode 61 allows unauthorized attackers to arbitrarily overwrite another user's clipboard content via supplying a crafted URL. | ||||
| CVE-2026-99235 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Save the event file instead of the compatible histogram create_field_var_hist() creates a histogram on the matched event to supply a field variable, and records it on the target so it can be torn down later: hist_data = find_compatible_hist(target_hist_data, file); ... /* Save the compatible histogram information */ var_hist->hist_data = hist_data; hist_data is not the histogram it creates. It is one that was already there, whose keys the new one copies. The saved pointer has a single user, unregister_field_var_hists(), which runs when the target is removed: file = hist_data->field_var_hists[i]->hist_data->event_file; find_compatible_hist() matches on keys alone, so it can pick one with no variables of its own. check_var_refs() then returns false and the user can remove it while the target still points at it: BUG: KASAN: slab-use-after-free in event_hist_trigger_free+0x2b2/0x320 Read of size 8 at addr ffff8880093b90e0 by task init/1 Freed by task 1: kfree+0x154/0x420 event_hist_trigger_free+0x1d5/0x320 event_hist_trigger_parse+0x35f3/0x69e0 trigger_process_regex+0x1a6/0x250 Save the event file instead. It is all the dereference ever wanted, and it does not go away when the user removes a trigger. | ||||
| CVE-2026-58829 | 1 Google | 1 Android | 2026-11-03 | 8.4 High |
| In fuse_backing_mmap of backing.c, there is a possible memory corruption due to a use after free. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-118011 | 1 Mozilla | 1 Firefox | 2026-11-03 | 7.5 High |
| Frame poisoning in the CSS Parsing and Computation component. This vulnerability was fixed in Firefox 159 and Thunderbird 159. | ||||
| CVE-2026-99231 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: own the request before clearing ->head io_waitid_remove_wq() only takes the wait queue lock if ->head is set. io_waitid_wait() clears ->head first thing, before it tries to become the owner of the request by bumping ->refs. If somebody else owns the request at that point, nothing keeps it from completing the request while the wake up handler is still going to touch it: CPU0 (io_waitid_wait) CPU1 (io_waitid, holds a ref) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() finds another child io_waitid_remove_wq() // ->head == NULL, no locking io_waitid_finish(), IOU_COMPLETE // request freed and reused atomic_fetch_inc(&iw->refs) The same goes for __io_waitid_cancel() if it claims the request in that window. ->refs is part of the per opcode data of the request, so this increments whatever the next user of the request keeps there. If that happens to be zero, the handler concludes that it owns the request, and queues io_waitid_cb() for it. With the window held open by a delay, and the request reused for a receive that is waiting for data: BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0 __wake_up_sync_key+0x36/0x50 sock_def_readable+0xf1/0x420 unix_stream_sendmsg+0x60b/0x1110 Allocated by task 87: io_arm_apoll+0x1ed/0x940 Freed by task 87: __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950 Only clear ->head once the handler owns the request. If it doesn't, the owner finds ->head set and has to wait for the lock, which is held by the caller of the handler. Deleting the already deleted entry again is harmless. | ||||
| CVE-2026-99233 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Verify event_call identity when updating synth_event refcount In event_hist_trigger_parse() and hist_unreg_all(), the histogram registration and unregistration paths look up find_synth_event() using trace_event_name(file->event_call) and adjust se->ref if a match is found. Because find_synth_event() only compares the event basename, registering or removing a histogram on a non-synthetic trace event whose basename matches a synthetic event erroneously modifies the synthetic event's reference count. If a histogram is registered on the non-synthetic event before the synthetic event is created and removed afterwards, se->ref is decremented without a matching increment, allowing the synthetic event to be freed while an active histogram action still holds a pointer to it. Introduce find_synth_event_call() to verify that &se->call matches file->event_call before adjusting se->ref. | ||||
| CVE-2026-99239 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn l2cap_chan may be linked to l2cap_conn at most once. This is assumed in several places, eg l2cap_chan_del cleanup. There is a TOCTOU race where the invariant is violated: [Task 1] [Task 2] l2cap_chan_connect l2cap_sock_bind l2cap_chan_lock lock_sock l2cap_state_change if (sk->sk_state != BT_OPEN) chan->state = BT_CONNECT l2cap_sock_state_change_cb chan->state = BT_BOUND sk->sk_state = BT_BOUND lock_sock <------------------ release_sock sk->sk_state = BT_CONNECT l2cap_sock_connect() does not check sk->sk_state, so since chan->state is now BT_BOUND, subsequent connect() ends up with second __l2cap_chan_add. Explicitly document and check the invariant in __l2cap_chan_add with WARN_ON_ONCE. The only callsite where it could be hit is l2cap_chan_connect, so add pre-check there to avoid relying on chan->state. chan->state read/write is not properly guarded currently so there can be other TOCTOUC problems. Add l2cap_lock_chan in l2cap_sock_bind() to guard chan->state write. | ||||
| CVE-2026-99017 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-03 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE errata_probe_ghostwrite() only marks the CPU as vulnerable when it is called at the RISCV_ALTERNATIVES_EARLY_BOOT stage, and the mitigation in ghostwrite_enable_mitigation() only takes effect if the vulnerable state was recorded before the boot alternatives are patched. The early boot stage is only executed when CONFIG_RISCV_ALTERNATIVE_EARLY is enabled, which currently is only selected by ERRATA_THEAD_MAE. In a kernel built with ERRATA_THEAD_GHOSTWRITE=y but ERRATA_THEAD_MAE=n, the early alternatives never run, so ghostwrite_state is never set to VULNERABLE: ghostwrite_enable_mitigation() returns false, xtheadvector remains enabled, and sysfs reports "Not affected" on a vulnerable T-Head C9xx CPU. Select RISCV_ALTERNATIVE_EARLY from ERRATA_THEAD_GHOSTWRITE so that the vulnerability is detected in the early boot stage and the default mitigation is applied. | ||||
| CVE-2026-28597 | 1 Google | 1 Android | 2026-11-03 | 8.4 High |
| In writeGrantedUriPermissions of UriGrantsManagerService.java, there is a possible permission bypass due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-49923 | 1 Google | 1 Android | 2026-11-03 | 8.4 High |
| In onResult of AccountManagerService.java, there is a possible untrusted/misleading UI issue due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-49931 | 1 Google | 1 Android | 2026-11-03 | 8.4 High |
| In onActivityResult in multiple locations, there is a possible contact leak from protected profile due to a confused deputy. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||