Export limit exceeded: 416842 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 416842 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (416842 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-100394 | 1 Nezhahq | 1 Nezha | 2026-10-29 | 6.5 Medium |
| Nezha Monitoring is a self-hostable, lightweight, servers and websites monitoring and O&M tool. From 2.2.7 until 2.2.11, ServiceSentinel.worker in service/singleton/servicesentinel.go checked an owned service under servicesLock and later dereferenced pointer-valued serviceStatusToday and serviceCurrentStatusData entries under serviceResponseDataStoreLock without revalidating that ServiceSentinel.Delete had not removed them. A RoleMember could concurrently report TCP or ICMP results through the member's own agent and delete the same owned service, causing a nil pointer dereference. Because the gRPC server had no recovery interceptor, the worker panic terminated the whole dashboard process and disrupted every tenant's web interface, REST API, and agent connections. The issue affects availability only and does not disclose or modify data. This issue is fixed in versions 2.2.11 and 2.3.0. | ||||
| CVE-2025-62841 | 2026-10-29 | N/A | ||
| An use of hard-coded cryptographic key vulnerability has been reported to affect HBS 3 Hybrid Backup Sync and Hybrid Backup Sync. If exploited, the vulnerability could allow remote attackers to compromise the security of the system. We have already fixed the vulnerability in the following version: HBS 3 Hybrid Backup Sync 26.4.0.521 and later Hybrid Backup Sync 26.4.0.521 and later Hybrid Backup Sync 26.4.1.563 and later | ||||
| CVE-2025-62839 | 2026-10-29 | N/A | ||
| An use of hard-coded cryptographic key vulnerability has been reported to affect HBS 3 Hybrid Backup Sync and Hybrid Backup Sync. If exploited, the vulnerability could allow remote attackers to compromise the security of the system. We have already fixed the vulnerability in the following version: HBS 3 Hybrid Backup Sync 26.4.0.521 and later Hybrid Backup Sync 26.4.0.521 and later Hybrid Backup Sync 26.4.1.563 and later | ||||
| CVE-2026-104317 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 8.1 High |
| IBM Langflow OSS 1.0.0 through 1.12.3 could allow a remote attacker who could reach the message broker to execute arbitrary code on the system due to the deserialization of untrusted data. | ||||
| CVE-2026-104324 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 8.8 High |
| IBM Langflow OSS 1.0.0 through 1.12.3 could allow a remote authenticated attacker to execute arbitrary code due to deserialization of untrusted data. | ||||
| CVE-2026-104331 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 5.4 Medium |
| IBM Langflow OSS 1.0.0 through 1.12.3 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. | ||||
| CVE-2026-104339 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 9.8 Critical |
| IBM Langflow OSS 1.0.0 through 1.12.3 could allow a remote attacker to execute arbitrary code due to improper neutralization of special elements used in an OS command. | ||||
| CVE-2026-107326 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 8.8 High |
| IBM Langflow OSS 1.0.0 through 1.12.4 could allow a remote authenticated attacker to execute arbitrary code due to improper neutralization of special elements used in an OS command. | ||||
| CVE-2026-107327 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 9.9 Critical |
| IBM Langflow OSS 1.0.0 through 1.12.4 could allow a remote authenticated attacker to execute arbitrary code due to missing authorization. | ||||
| CVE-2026-107329 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 9.9 Critical |
| IBM Langflow OSS 1.0.0 through 1.12.4 could allow a remote authenticated attacker to execute arbitrary code due to improper control of code generation. | ||||
| CVE-2026-110186 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 9.8 Critical |
| IBM Langflow OSS 1.0.0 through 1.12.8 could allow a remote attacker to execute arbitrary code due to improper control of code generation. | ||||
| CVE-2026-110192 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 6.5 Medium |
| IBM Langflow OSS 1.0.0 through 1.12.8 could allow a remote authenticated attacker to obtain sensitive information due to insufficiently protected credentials. | ||||
| CVE-2026-110193 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 8.8 High |
| IBM Langflow OSS 1.0.0 through 1.12.8 could allow a remote attacker with a low-privileged authenticated account to cause the Agentic Assistant to generate or submit component code using these unblocked patterns, resulting in arbitrary operating system command execution on the server. | ||||
| CVE-2026-110196 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 8.8 High |
| IBM Langflow OSS 1.0.0 through 1.12.4 could allow a remote attacker with a low-privileged authenticated account to bypass the administrator-only restriction and execute arbitrary code on the server by configuring a built-in code-execution component with attacker-supplied inputs. | ||||
| CVE-2026-110200 | 1 Ibm | 1 Langflow Oss | 2026-10-29 | 6.5 Medium |
| IBM Langflow OSS 1.0.0 through 1.12.4 could allow a remote authenticated attacker to obtain sensitive information due to cleartext storage of sensitive information. | ||||
| CVE-2026-99109 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: reject SetEA requests that do not fit the request buffer CIFSSMBSetEA() copies the caller's extended attribute value into the SMB request buffer without checking that it fits. The requirement is stated in the source but was never implemented: /*BB add length check to see if it would fit in negotiated SMB buffer size BB */ /* if (ea_value_len > buffer_size - 512 (enough for header)) */ if (ea_value_len) memcpy(parm_data->list.name + name_len + 1, ea_value, ea_value_len); The only bound applied on the way in is in cifs_xattr_set(): #define MAX_EA_VALUE_SIZE CIFSMaxBufSize ... if (size > MAX_EA_VALUE_SIZE) CIFSMaxBufSize is the full payload capacity of the buffer, so a value of exactly that size leaves no room for the SMB header, the TRANS2 parameter block, the fealist header and the EA name that are written ahead of it in the same object. SendReceive() already enforces the correct limit on this very length: if (in_len > CIFSMaxBufSize + MAX_CIFS_HDR_SIZE) but it is called after the copy has taken place. An unprivileged setxattr(2) on an SMB1 mount with a 250-byte name and a 16384-byte value writes 16384 bytes starting 345 bytes into a 16588-byte cifs_request object, ending 141 bytes past it: BUG: KASAN: slab-out-of-bounds in CIFSSMBSetEA+0xabc/0xde0 Write of size 16384 at addr ffff888003aa0159 by task init/68 __asan_memcpy+0x3c/0x60 CIFSSMBSetEA+0xabc/0xde0 cifs_xattr_set+0xd3a/0xff0 __vfs_setxattr+0x13e/0x1a0 The buggy address is located 345 bytes inside of allocated 16588-byte region Apply SendReceive()'s limit to the assembled request before the copy rather than after it, and widen the byte counters so the sum cannot wrap before it is tested. byte_count is also tested against U16_MAX, because it is stored in the 16-bit pSMB->ByteCount. That becomes reachable when CIFSMaxBufSize is raised at module load, where it may be set as high as 1024*127: with a 5-byte EA name and a 65521-byte value, count is exactly U16_MAX while byte_count is 65556, and cpu_to_le16() would truncate it to 20 and transmit a frame whose ByteCount does not match its length. Testing byte_count covers count as well, since byte_count is the larger of the two and count's only 16-bit consumer is written after this point. check_add_overflow() is evaluated first so that total_len is assigned before it is reported. | ||||
| CVE-2026-99111 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 3.3 Low |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: fix data corruption with concurrent writes and O_TRUNC cifs_do_truncate() flushes dirty pages with filemap_write_and_wait() and truncates the file on the server, but in the old code both operations ran without holding i_rwsem or invalidate_lock. A concurrent buffered write via netfs_perform_write() -- which only needs i_rwsem shared -- could dirty new pages after the flush but before the local truncation, and those pages would be silently discarded by cifs_setsize() -> truncate_pagecache(). Fix by acquiring inode_lock (exclusive i_rwsem) and filemap_invalidate_lock at the top of cifs_do_truncate(), so the entire flush-truncate-resize sequence is atomic with respect to: - buffered writes (blocked by exclusive i_rwsem, since netfs_start_io_write takes i_rwsem shared), - read page faults (blocked by exclusive invalidate_lock, since filemap_fault takes it shared), - writeback collection (blocked by netfs_wb_begin/netfs_wb_end around the server truncate and local resize, since netfs_writepages also acquires the wb lock). | ||||
| CVE-2026-99112 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_flower: validate mask pointer after nla_next() fl_set_enc_opt() iterates the key's nested tunnel-option attributes with nla_for_each_attr() while advancing a single mask pointer via nla_next() at the bottom of each loop, so the mask cursor is driven by the number of key attributes rather than by the mask's own attributes. The nla_ok() added by commit c96adff956191 ("cls_flower: call nla_ok() before nla_next()") only validates the mask pointer that was just consumed; the pointer produced by nla_next() is used by the next iteration (fl_set_geneve_opt() and siblings) without any validation. The mask's nested attributes are validated with NL_VALIDATE_LIBERAL, which merely warns on trailing bytes that do not form a complete attribute. A mask carrying one valid attribute plus 1-3 residue bytes (or a non-aligned attribute length making msk_depth negative) therefore reaches the next iteration with msk_depth != 0, so neither the !msk_depth check in fl_set_enc_opt() nor the !depth check in the per-type helpers fires. nla_type() then reads past the mask payload and nla_parse_nested_deprecated() iterates with an nla_len taken from those bytes, reading well beyond the mask attribute (KASAN: slab-out-of-bounds read in __nla_validate_parse from fl_change()). Validate the advanced mask pointer as well: when the mask is not legitimately exhausted (msk_depth != 0) and the new pointer fails nla_ok(), reject the filter with -EINVAL. An exactly exhausted mask still skips the check, preserving exact-match behaviour for the remaining key attributes. | ||||
| CVE-2026-99167 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net/sched: fix use-after-free in __tcf_action_put() __tcf_action_put() decrements the reference count before decrementing the binding count. Another thread can free the action between these operations, causing the binding-count update to access freed memory. KASAN reports it as: BUG: KASAN: slab-use-after-free in __tcf_action_put+0x327/0x340 Write of size 4 at addr ff11000000d46420 by task tc-put-pause/64 Hold the action IDR mutex across both counter updates and IDR removal, keeping cleanup outside the lock. | ||||
| CVE-2026-39735 | 2 Crocoblock, Wordpress-extensions | 2 Jetengine, Jetengine | 2026-10-29 | 6.5 Medium |
| Missing Authorization vulnerability in Crocoblock JetEngine jet-engine allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects JetEngine: from n/a through 3.9.0.1. | ||||