Export limit exceeded: 424108 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 424108 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (424108 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-58376 | 1 Renovatebot | 1 Renovate | 2026-09-29 | 6.7 Medium |
| Renovate versions 37.158.0 before 37.199.0 contain a command injection vulnerability in the helmv3 manager's registryAliases handling that allows attackers with commit access to execute arbitrary commands. Attackers can manipulate registryAliases keys with unquoted shell metacharacters to inject commands executed during helm repo add operations, gaining full access to Renovate's execution environment. | ||||
| CVE-2026-15278 | 2026-09-29 | N/A | ||
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2026-96878 | 1 Wikimedia | 1 Mediawiki-cargo Extension | 2026-09-29 | N/A |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Mediawiki - Cargo extension allows Reflected XSS. This issue affects Mediawiki - Cargo extension: through 3.9.4. | ||||
| CVE-2026-96877 | 1 Wikimedia | 1 Mediawiki-cargo Extension | 2026-09-29 | N/A |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Mediawiki - Cargo extension allows Reflected XSS. This issue affects Mediawiki - Cargo extension: through 3.9.4. | ||||
| CVE-2026-96874 | 1 Wikimedia | 1 Mediawiki-cargo Extension | 2026-09-29 | N/A |
| Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in the Mediawiki - Cargo extension allows Stored XSS. This issue affects Mediawiki - Cargo extension: through 3.9.4. | ||||
| CVE-2026-76227 | 1 Renovatebot | 1 Renovate | 2026-09-29 | 5.5 Medium |
| Renovate versions from 42.68.1 before 42.96.3 and from 43.0.0 before 43.4.4, including the renovate/renovate Docker images, and Mend Renovate CE/EE images (renovate-ce, renovate-ee-server, renovate-ee-worker) from 13.3.0 before 13.6.0, fail to restrict environment variables to an allowlist when spawning child processes. As a result, child processes (e.g. npm install, postUpgradeTasks, postUpdateOptions) gain full access to all environment variables of the Renovate process, allowing insider or outside attackers to exfiltrate secrets accessible to the Renovate deployment. | ||||
| CVE-2026-76226 | 1 Renovatebot | 1 Renovate | 2026-09-29 | 6.3 Medium |
| Renovate versions from 43.65.0 before 43.102.11 contain a remote code execution vulnerability in bazel-module and bazelisk managers when using lockFileMaintenance. Attackers can execute arbitrary code by providing malicious dependencies that are referenced in bazel mod deps calls, such as within ctx.execute statements. | ||||
| CVE-2026-98029 | 1 Linux | 1 Linux Kernel | 2026-09-29 | 7 High |
| In the Linux kernel, the following vulnerability has been resolved: eth: nfp: bound the ntuple rule dump by the caller's buffer size nfp_net_get_fs_loc() dumps every entry of nn->fs.list into rule_locs[] without consulting cmd->rule_cnt, which is how many entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed flow steering rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Bail out with -EMSGSIZE when the buffer fills up, the way the other ntuple capable drivers do, and report how many locations were filled so a shrinking rule list does not leave the caller reading stale slots. | ||||
| CVE-2026-98037 | 1 Linux | 1 Linux Kernel | 2026-09-29 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Reject untrusted allocated-object pointers When the final RCU read-side critical section ends, a local kptr is demoted to PTR_UNTRUSTED but retains MEM_ALLOC. The pointer may be NULL or may refer to an object whose lifetime is no longer protected. type_is_ptr_alloc_obj() nevertheless recognizes any PTR_TO_BTF_ID with MEM_ALLOC as a live allocated object. In particular, a refcount-only local kptr never carries NON_OWN_REF, so it still passes the bpf_refcount_acquire() argument check after RCU protection ends. The kfunc can then dereference NULL or stale memory. Make type_is_ptr_alloc_obj() reject PTR_UNTRUSTED pointers. Since type_is_non_owning_ref() is based on the same predicate, graph kfunc arguments obey the same live-object requirement. Fault-protected reads of the demoted pointer remain valid: writes are already rejected, and read fixups use bpf_may_fault_on_deref() rather than this predicate. [ kkd: Rewrote commit log ] | ||||
| CVE-2026-98039 | 1 Linux | 1 Linux Kernel | 2026-09-29 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Require MEM_PERCPU for percpu kptr stores map_kptr_match_type() treats perm_flags as the set of register type flags that a kptr field permits. Adding MEM_PERCPU to that set for BPF_KPTR_PERCPU does not require the source register to carry it, however. The subset test consequently accepts both a plain bpf_obj_new() allocation and a referenced kernel pointer into a __percpu_kptr map field. Loads from the field are always marked MEM_PERCPU. Consumers then treat the stored value as the cookie returned by bpf_percpu_obj_new(): per-CPU pointer helpers relocate it, and map teardown selects the per-CPU free path. A plain allocation can therefore provide an arbitrary kernel read/write, while a kernel pointer can be relocated into an invalid address or sent through a missing destructor. Require the source MEM_PERCPU flag to match the destination field kind. This preserves valid bpf_percpu_obj_new() stores and rejects both the program-BTF and kernel-BTF variants. | ||||
| CVE-2026-98040 | 1 Linux | 1 Linux Kernel | 2026-09-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Mark the zero register precise for a register-form NULL check check_cond_jmp_op() accepts "if rA <op> rB" as a NULL check for a nullable pointer rA when rB is a scalar known to be zero, lifts PTR_MAYBE_NULL from rA in the corresponding branch and does not mark rB precise. Consider the following program: r0 = bpf_get_prandom_u32(); r6 = 1; /* the r6 == 0 path is explored first */ if (r0 == 0) goto 1f; r6 = 0; 1: r0 = bpf_map_lookup_elem(map, &0); /* absent, NULL at runtime */ if (r0 == r6) goto 2f; /* taken as a NULL check for r0 */ *(u8 *)(r0 + 0); /* verifier: map value; runtime: zero */ 2: return 0; The r6 == 0 path is explored first and the dereference is accepted. The r6 == 1 path is pruned at the checkpoint recorded for (1), so the comparison is never verified with a non-zero r6. At runtime a failed lookup returns NULL, NULL != 1 takes the non-NULL edge and the program dereferences a pointer that is zero. | ||||
| CVE-2026-95834 | 1 Kovidgoyal | 1 Kitty | 2026-09-29 | N/A |
| Use After Free in the drag source path of the drag and drop protocol in kitty from 0.47.0 before 0.49.0 allows a program writing to the terminal to cause the terminal to read from and write to freed heap memory, because drag_remote_file_data() in kitty/dnd.c holds a DragRemoteItem pointer into an array it does not own, calls toplevel_data_for_drag() or subdir_data_for_drag(), and then continues to use that pointer. Those helpers, and add_payload() and populate_dir_entries() which they call, report errors through the abrt() macro, which expands to cancel_drag() followed by a plain return, and cancel_drag() calls drag_free_offer(), which frees the array the pointer refers to. The helpers return void, so the caller receives no indication that the teardown happened, and proceeds to call all_children_complete() on the freed pointer, which dereferences it, and then to write through it. That dereference is guarded by a local flag that is set when the request carries no payload and announces no further data, which is the same condition that selects the finalisation block of add_payload(), so the error paths in that block reach it: a create that fails because an entry of the same name already exists, because the client may declare two entries with one name and the create operations use O_CREAT with O_EXCL and symlinkat(), a mkdirat() failure other than EEXIST, and the directory entry allocation paths. Both branches reach it. In the top level branch the caller's pointer is never cleared, so clearing the owning structure's own pointers during teardown does not help. In the sub directory branch subdir_data_for_drag() sets the caller's pointer to NULL on entry and assigns it only after its own last error path, so its own aborts leave the caller with NULL and are stopped by a null check, but it then calls add_payload() with that pointer set, and an abort there leaves the caller holding a freed child node inside the item tree, which drag_free_offer() frees by recursion. This results in undefined behaviour in the terminal process, reachable from the byte stream of any program running in the window. | ||||
| CVE-2026-80431 | 1 Kovidgoyal | 1 Kitty | 2026-09-29 | N/A |
| Out-of-bounds Write in the natural width branch of the text sizing protocol in kitty from 0.40.0 before 0.49.0 allows a program writing to the terminal to write past the end of a fixed-size buffer, because screen_handle_multicell_command() in kitty/screen.c appends each codepoint of a grapheme cluster with lc.chars[lc.count++] = ch without any capacity check, while lc is declared by the RAII_ListOfChars macro as a four-element char_type array in the function's stack frame, so an OSC 66 escape code whose payload carries a grapheme cluster longer than four codepoints writes beyond that buffer, one 32-bit value per additional codepoint, in the order the codepoints appear. Where the cluster is preceded in the same payload by a sequence that causes an intermediate flush, the buffer is first migrated to the heap by ensure_space_for_chars() and the write occurs past the heap allocation instead. This results in termination of the kitty process and therefore of all its windows, tabs and child processes. | ||||
| CVE-2026-98042 | 1 Linux | 1 Linux Kernel | 2026-09-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Don't resurrect a scalar id dropped by collect_linked_regs() check_cond_jmp_op() copies the compared registers into env->{false,true}_reg{1,2} before collect_linked_regs() runs and copies those snapshots back into both branch states afterwards. collect_linked_regs() records at most LINKED_REGS_MAX members of a linked registers group in the jump history and calls clear_scalar_id() for every member that does not fit. The compared register is not exempt from that. As a consequence, sync_linked_regs() might adjust ranges for more registers than bpf_bt_sync_linked_regs() can propagate precision to. Collect the linked registers before the snapshots are taken instead. This might lead to some unnecessary clear_scalar_id's, but from previous testing situations with many linked registers are extremely rare. | ||||
| CVE-2026-98105 | 1 Linux | 1 Linux Kernel | 2026-09-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: ethernet: oa_tc6: Improve the error recovery When oversubscribed traffic causes lot of buffer overflow errors, probably due to loss of data chunks, driver fails to find a data chunk with end_valid bit set, before it runs out of sk buffer space. As a result, assert is seen during skb_put. Now, check is made if skb buffer has enough tailroom for the incoming data before accepting. If there is no room, current frame is abandoned and it will start looking for a data chunk with start_valid bit, that is a new frame. SK buffer allocation error is considered as recoverable error. rx_buf_overflow flag is too specific and no longer the only condition this flag is used for. Therefore it is renamed as wait_until_start_valid. This is more appropriate as this flag is used to look for the next data chunk with SV bit set, after failures like buffer overflow, buffer allocation failure, skb pointer validity besides buffer overflow error. Not writing to status0 if it reads 0. | ||||
| CVE-2026-98106 | 1 Linux | 1 Linux Kernel | 2026-09-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/pagemap: Prevent double migration of device pages A device-private folio migrated to system memory by a CPU fault can remain reachable through the raw-PFN eviction path until migration finalization drops the source reference. If eviction selects the same device-private folio during this window, it can attempt to migrate the folio again. The second migration can leave an uncharged folio on an LRU list, causing folio_lruvec_lock_irqsave() to retry indefinitely and resulting in a soft lockup and RCU stall. Mark successfully migrated device-private folios using a low bit of their zone_device_data before migration finalization. Make both CPU-fault and raw-PFN migration paths skip device-private folios carrying this flag. Mask the flag when retrieving the drm_pagemap_zdd pointer and preserve it when a device-private folio is split. Keeping the state on the physical folio also avoids depending on a virtual address that may change before a fault occurs. v2: - Replace the retired-PFN XArray with an embedded bitmap. (Matthew Brost) - Mark every base page covered by a migrated folio so retirement remains valid if the folio is later split. v3: - Store the migrated state in a low bit of zone_device_data instead of adding virtual-range and bitmap tracking to the ZDD. (Matthew Brost) - Mask the flag when retrieving the ZDD and preserve it when splitting a folio. - Drop the pre-existing fixes already covered by Matthew Brost's series: https://patchwork.freedesktop.org/series/171651/ v4: - Advance by the folio size only for migration entries marked with MIGRATE_PFN_COMPOUND. (Sashiko) v5: - Simplify ZDD flag updates and folio iteration. (Matthew Brost) - Skip retired device-private folios in the CPU-fault path. (Matthew Brost) - Preserve flag bits while taking a new ZDD reference for split folios. v6: - Restore MIGRATE_PFN_COMPOUND-aware stepping so non-compound migration entries are processed one at a time. (Sashiko) - Drop the pre-existing fixes already covered by Matthew Brost's series: https://patchwork.freedesktop.org/series/171651/ The lockup was observed as: [10109.860465] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [kworker/u65:5:6557] [10109.860524] Tainted: [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE [10109.860524] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 [10109.860525] Workqueue: xe_page_fault_work_queue xe_pagefault_queue_work [xe] [10109.860644] RIP: 0010:_raw_spin_unlock_irqrestore+0x57/0x80 [10109.860655] Call Trace: [10109.860655] <TASK> [10109.860657] folio_lruvec_lock_irqsave+0x216/0x220 [10109.860661] ? __pfx_lru_add+0x10/0x10 [10109.860665] folio_batch_move_lru+0xc8/0x450 [10109.860670] ? lock_acquire+0xc4/0x2d0 [10109.860674] ? __folio_batch_add_and_move+0x60/0x2e0 [10109.860677] ? folio_migrate_mapping+0xa6/0x110 [10109.860679] ? folio_migrate_flags+0x13b/0x1b0 [10109.860681] ? __pfx_lru_add+0x10/0x10 [10109.860683] __folio_batch_add_and_move+0xe7/0x2e0 [10109.860685] ? dma_iova_try_alloc+0xb0/0x140 [10109.860689] folio_add_lru+0x64/0x80 [10109.860691] __migrate_device_finalize+0x12c/0x270 [10109.860695] migrate_device_finalize+0x10/0x20 [10109.860698] drm_pagemap_evict_to_ram+0x185/0x370 [drm_gpusvm_helper] [10109.860704] ? drm_pagemap_evict_to_ram+0x96/0x370 [drm_gpusvm_helper] [10109.860709] xe_svm_bo_evict+0x15/0x20 [xe] [10109.860819] ? xe_svm_bo_evict+0x15/0x20 [xe] [10109.860921] xe_bo_move+0x107e/0x1570 [xe] [10109.860992] ? xe_ttm_tt_create+0x168/0x340 [xe] [10109.861059] ? __up_read+0x98/0x2b0 [10109.861061] ? lock_is_held_type+0xa3/0x130 [10109.861067] ttm_bo_handle_move_mem+0xe8/0x1e0 [ttm] [10109.861075] ttm_bo_evict+0x141/0x1c0 [ttm] [10109.861081] ttm_bo_evict_cb+0x9f/0x100 [ttm] [10109.861086] ttm_lru_walk_for_evict+0x84/0x190 [ttm] [10109.861091] ? xe_ttm_vram_mgr_new+0x258/0x3a0 [xe] [10109.861198] ttm_bo_alloc_resource+0x219/0 ---truncated--- | ||||
| CVE-2026-102822 | 1 Eugeny | 1 Russh | 2026-09-29 | 3.7 Low |
| Russh is a Rust SSH client and server library. Prior to 0.63.1, a connection configured to permit mac=none can negotiate it with a MAC-requiring CTR or CBC block cipher because the selection logic validates needs_mac() only when MAC selection fails. A remote peer can then send a packet with a decrypted length of zero, causing russh/src/cipher/mod.rs to shrink the previously read block before indexing buffer.buffer[16..], which panics and terminates the connection task. This issue is fixed in version 0.63.1. | ||||
| CVE-2026-93642 | 1 Zimbra | 1 Zimbra Collaboration Suite | 2026-09-29 | 9.3 Critical |
| An unauthenticated sender can forge a share notification that triggers stored XSS when a signed-in Zimbra Modern recipient clicks Accept Share, allowing the attacker to access mailbox data and act as the victim. | ||||
| CVE-2026-93641 | 1 Zimbra | 1 Zimbra Collaboration Suite | 2026-09-29 | 9.3 Critical |
| An unauthenticated sender can forge a share notification that triggers stored XSS when a signed-in Zimbra Classic recipient clicks Accept Share, allowing the attacker to access mailbox data and act as the victim. | ||||
| CVE-2026-96879 | 1 Wikimedia | 1 Mediawiki - Flaggedrevs Extension | 2026-09-29 | N/A |
| Improper removal of sensitive information before storage or transfer vulnerability in Wikimedia Foundation's Mediawiki - FlaggedRevs extension through 1.46.0. | ||||