Export limit exceeded: 24040 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (24040 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-113390 | 1 Draytek | 2 Vigor2960, Vigor2960 Firmware | 2026-10-22 | 9.9 Critical |
| A flaw has been found in DrayTek Vigor2960 1.5.1.6 Revision 8218. Affected by this issue is the function sub_182B0 of the file /cgi-bin/mainfunction.cgi of the component CGI Interface. This manipulation of the argument usefile/usescript/option causes os command injection. Remote exploitation of the attack is possible. The exploit has been published and may be used. The vendor explains: "2960 1.5.1.7 has corrected many security issues. And 2960 is EoS with limited support, only major issues would be reviewed(e.g. unauthenticated vuln.)". This vulnerability only affects products that are no longer supported by the maintainer. | ||||
| CVE-2026-112370 | 1 H3c | 2 Magic Nx15, Magic Nx15 Firmware | 2026-10-22 | 9.9 Critical |
| A vulnerability was found in H3C Magic NX15 100R017. This issue affects the function sub_416874 of the file /usr/bin/usrlist. Performing a manipulation results in os command injection. Remote exploitation of the attack is possible. The exploit has been made public and could be used. The vendor was contacted early about this disclosure. | ||||
| CVE-2026-98635 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 6.2 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: block: Fix zones_cond out-of-bounds write on zone report blk_revalidate_disk_zones() sizes the zones_cond array from the disk capacity and zone size, but the index used by blk_revalidate_zone_cond() comes from the device-driven report_zones() walk and is never checked against the array size. A device reporting more zones than fit the array makes blk_zone_set_cond() write out of bounds. One way to reach this is a zone count exceeding 32 bits: both blk_revalidate_zone_args.nr_zones and struct zoned_disk_info.nr_zones are unsigned int, so a disk advertising more than UINT_MAX zones (e.g. 2^32 + 1024 zones of one 512-byte logical block) gets its zone count truncated to a small value, undersizing the array while the report walk keeps counting upward. Check the index against the array size before storing the zone condition, and refuse to revalidate when the zone count does not fit 32 bits. | ||||
| CVE-2026-101967 | 1 Juniper Networks | 1 Junos Os Evolved | 2026-10-22 | 8.8 High |
| An OS Command Injection vulnerability in the bootzd zero-touch provisioning daemon of Juniper Networks Junos OS Evolved allows an unauthenticated attacker on the management LAN to execute commands as root via crafted DHCP response. | ||||
| CVE-2026-103993 | 1 Juniper Networks | 2 Junos Os, Junos Os Evolved | 2026-10-22 | 6.8 Medium |
| An Out-of-bounds Write vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an adjacent attacker which sends a specific set of BGP communities to cause a Denial-of-Service (DoS) as rpd crashes when graceful-shutdown sender community is added when attempting to advertise. | ||||
| CVE-2026-100236 | 2 Dpdk, Redhat | 4 Dpdk, Enterprise Linux, Openshift and 1 more | 2026-10-22 | 8.6 High |
| A flaw was found in the DPDK GSO library. When software GSO copies packet headers into a new mbuf, it does not check that the header fits in the source first segment or in the destination buffer, and a header longer than the configured GSO segment size can underflow the payload-size calculation. A remote or guest-supplied packet processed with software GSO can trigger an out-of-bounds read or write. | ||||
| CVE-2026-15176 | 1 F5 | 2 Nginx Open Source, Nginx Plus | 2026-10-22 | 8.1 High |
| A vulnerability exists in NGINX Plus and NGINX Open Source when a location is configured that uses the alias directive together with rewrite and a set or return directive referencing the $request_filename variable. Alternatively, the same result could be achieved when the $request_filename variable is used in an access log format directive. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. Impact: This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger a code execution. There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. | ||||
| CVE-2026-84419 | 1 Citrix | 1 Workspace App For Windows | 2026-10-22 | N/A |
| Out-of-bounds write vulnerability in Citrix Workspace app for Windows. This issue affects Workspace app for Windows: before 2603.20 CR, before LTSR 2607 Hotfix 1, and before LTSR 2507 CU3 Hotfix 1. | ||||
| CVE-2026-98703 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: minstrel_ht: validate fixed rate index The fixed_rate_idx debugfs file is a plain u32 attribute, so any value can be written to it. minstrel_ht_update_stats() then copies the value into mi->max_tp_rate[] and mi->max_prob_rate, and minstrel_ht_set_rate() uses MI_RATE_GROUP()/MI_RATE_IDX() to index minstrel_mcs_groups[] (42 entries) and mi->groups[].rates[] (10 entries) with it. Writing e.g. 65535 selects group 4095 and rate index 15, far outside both arrays. The out-of-bounds entries are dereferenced and updated as struct minstrel_rate_stats (retry counts, etc.), so the invalid index corrupts adjacent kernel memory. With CONFIG_UBSAN_BOUNDS the access is reported as an array-index-out-of-bounds in minstrel_ht_set_rate(). Only a valid group/rate pair, or U32_MAX to disable fixed rate processing, can be used safely, so reject any other value when the debugfs file is written. The file is only reachable through a root-only debugfs mount, so this is not a privilege boundary. The out-of-bounds access is still a bug that must not be reachable through a writable debugfs attribute. | ||||
| CVE-2026-98830 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: validate MIB read length before copying to caller wfx_hif_read_mib() copies reply->length bytes from the firmware response into the caller-provided buffer without checking that reply->length does not exceed val_len. A firmware response with a length field larger than expected overruns the caller buffer and reads past the end of the reply allocation. Replace the dead -ENOMEM check with an active validation that reply->length fits within val_len before the memcpy. | ||||
| CVE-2026-15567 | 1 Redhat | 8 Fuse, Jboss Enterprise Application Platform, Jboss Enterprise Application Platform Els and 5 more | 2026-10-22 | 7.5 High |
| A flaw was found in Wildfly. A remote unauthenticated attacker can trigger OutOfMemoryError as CSIv2Util's GSS token decoder reads an attacker-controlled length field without bounds checking and attempts to allocate a byte array of that size. | ||||
| CVE-2026-95637 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2026-10-22 | 7.8 High |
| Photoshop Desktop is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2026-95641 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2026-10-22 | 7.8 High |
| Photoshop Desktop is affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | ||||
| CVE-2025-58773 | 1 Ami | 1 Aptio V | 2026-10-22 | N/A |
| AMI APTIOV contains vulnerabilities in BIOS where users may cause "Out-of-bounds Write” by local access. Successful exploitation of this vulnerability could lead to buffer overflows, memory corruption, and arbitrary code execution, and also impact Confidentiality, Integrity, and Availability. | ||||
| CVE-2026-105044 | 1 Qingteng | 1 Host Adaptive Security Platform | 2026-10-22 | N/A |
| Improper Neutralization of Special Elements used in an OS Command in Security Toolbox versions before 20260929 in Qingteng Host Adaptive Security Platform (Host Monitoring) V3.0 allows an authenticated console administrator to execute arbitrary commands on attached clients via OS command injection | ||||
| CVE-2026-56387 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| The RTMP AMF parser in Apache bRPC accepts AMF string lengths and array counts directly from untrusted input. A remote unauthenticated attacker who can reach a bRPC server with RTMP enabled can send a small AMF payload with an excessive declared long string length or array count, causing excessive memory allocation or resource consumption before the parser rejects the incomplete payload. Root Cause: The AMF long string parser resized the destination string to the declared 32-bit length before validating that the stream contained that many bytes. ECMA array and strict array parsers also accepted 32-bit element counts without a configurable upper bound. Affected Scenarios: Deployments that enable the bRPC RTMP server component and accept RTMP traffic from untrusted clients. Direct uses of the AMF parser on untrusted data are also affected. How to Fix: 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3353 Note: The fix introduces configurable AMF parsing limits. The default maximum string size is 64 MiB and the default maximum array element count is 1,048,576. Payloads above these limits are rejected. The limits can be adjusted with amf_max_string_size and amf_max_array_size. | ||||
| CVE-2026-56388 | 1 Apache | 1 Brpc | 2026-10-22 | N/A |
| The Redis server command parser in Apache bRPC accepts an empty RESP array as a command header. A remote unauthenticated attacker who can reach a bRPC server with Redis service enabled can send an empty array header followed by a bulk string, causing an out-of-bounds write in the parser and crashing the process. Root Cause: RedisCommandParser::ConsumeImpl rejected negative RESP array counts but accepted zero. It resized the command argument vector to zero elements and continued parsing. When a following bulk string was parsed, the only index guard was a CHECK. In configurations where fatal logs do not abort immediately, execution could continue and write to _args[0] even though the vector was empty. Affected Scenarios: Deployments that enable ServerOptions.redis_service and accept Redis protocol traffic from untrusted clients. The issue is reached during parsing before command handling or authentication. How to Fix: 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3354 Note: The fix rejects empty RESP arrays as invalid Redis commands and replaces the internal index CHECK with an explicit parse error so malformed command streams cannot fall through to an indexed vector write. | ||||
| CVE-2026-76490 | 1 Cisco | 1 Expressway Series | 2026-10-22 | 8.6 High |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco Expressway Series software engineering team has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76490 are related to issues concerning out-of-bounds writes that are grouped under the Common Weakness Enumeration (CWE) Base CWE-787. | ||||
| CVE-2026-20043 | 1 Cisco | 5 Cisco Open Source Snort3, Cisco Secure Firewall Threat Defense (ftd) Software, Cisco Utd Snort Ips Engine Software and 2 more | 2026-10-22 | 9 Critical |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco owned Open Source Snort 3 Software engineering team has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-20043 are related to issues concerning out-of-bounds writes that are grouped under the Common Weakness Enumeration (CWE) Base CWE-787. | ||||
| CVE-2026-63886 | 1 Linux | 1 Linux Kernel | 2026-10-22 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the "0b" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this. | ||||