| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
| EDK2 contains a vulnerability in BIOS where a user may cause “Out-of-bounds
Write”, Classic
Buffer Overflow, and “Incorrect Calculation of Buffer Size” by remote access. Successful exploitation of this vulnerability
can lead to arbitrary
code execution. It could also impact
Confidentiality,
Integrity,
and Availability. |
| 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. |
| 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. |
| 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. |
| Out-of-bounds read and write in the Count-Min sketch deserialization of Apache DataSketches C++ (repo: datasketches-cpp).
count_min_sketch::deserialize() did not include the preamble in its input size check, so a truncated sketch could cause a read of up to 16 bytes past the end of the input. In addition, the table size was computed from the serialized number of buckets and number of hash functions in 32-bit arithmetic. A crafted sketch could make it wrap to zero, so that the sketch deserialized with an empty table, and later updates and estimate queries read and wrote outside the heap allocation. This can corrupt heap memory, causing a crash and potentially enabling further exploitation.
This issue affects Apache DataSketches C++: from 4.1.0 before 5.3.0. Only applications that deserialize Count-Min sketches from untrusted sources are affected.
Users are recommended to upgrade to version 5.3.0, which fixes this issue. |
| Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D). Supported versions that are affected are Oracle Java SE: 8u503, 8u503-perf, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1, 27; Oracle GraalVM for JDK: 17.0.20.1 and 21.0.12.1; Oracle GraalVM Enterprise Edition: 21.3.19.1.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition as well as unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data and unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H). |
| 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. |
| 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. |
| A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream.
Users need to update any Brotli libraries or binaries between 1.0.3 through 1.2.0 to the latest available version: 1.0.10 or 1.1.1 or 1.2.1. |
| A stack-based buffer overflow vulnerability in Fortinet FortiOS 7.4.0 through 7.4.3, FortiOS 7.2.0 through 7.2.7, FortiOS 7.0.0 through 7.0.14, FortiOS 6.4 all versions, FortiOS 6.2 all versions, FortiOS 6.0 all versions, FortiPAM 1.2 all versions, FortiPAM 1.1 all versions, FortiPAM 1.0 all versions, FortiProxy 7.4.0 through 7.4.3, FortiProxy 7.2.0 through 7.2.9, FortiProxy 7.0.0 through 7.0.16, FortiProxy 2.0 all versions, FortiProxy 01.02 all versions, FortiProxy 1.2 all versions, FortiProxy 01.01 all versions, FortiProxy 1.1 all versions, FortiProxy 01.00 all versions, FortiSwitchManager 7.2.0 through 7.2.3, FortiSwitchManager 7.0.1 through 7.0.3 allows attacker to execute unauthorized code or commands via specially crafted packets. |
| A out-of-bounds write vulnerability in Fortinet FortiOS 7.4.0 through 7.4.2, FortiOS 7.2.0 through 7.2.6, FortiOS 7.0.0 through 7.0.13, FortiOS 6.4.0 through 6.4.14, FortiOS 6.2.0 through 6.2.15, FortiOS 6.0 all versions, FortiProxy 7.4.0 through 7.4.2, FortiProxy 7.2.0 through 7.2.8, FortiProxy 7.0.0 through 7.0.14, FortiProxy 2.0.0 through 2.0.13, FortiProxy 01.02 all versions, FortiProxy 1.2 all versions, FortiProxy 01.01 all versions, FortiProxy 1.1 all versions, FortiProxy 01.00 all versions allows attacker to execute unauthorized code or commands via specifically crafted requests |
| A out-of-bounds write vulnerability in Fortinet FortiOS 7.2.0 through 7.2.3, FortiOS 7.0.0 through 7.0.10, FortiOS 6.4.0 through 6.4.11, FortiOS 6.2.0 through 6.2.13, FortiOS 6.0.0 through 6.0.16, FortiProxy 7.2.0 through 7.2.1, FortiProxy 7.0.0 through 7.0.7, FortiProxy 2.0 all versions, FortiProxy 01.02 all versions, FortiProxy 1.2 all versions, FortiProxy 01.01 all versions, FortiProxy 1.1 all versions, FortiProxy 01.00 all versions allows an authenticated attacker to execute unauthorized code or commands via specifically crafted requests. |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-32, a crafted EXR image can cause the EXR decoder to write beyond a heap buffer, causing the process to crash. This issue is fixed in version 7.1.2-32. |
| Out of bounds write in Forms in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Low) |
| Sharp before 0.35.4 bundles a vulnerable libheif dependency that allows attackers to achieve possible remote code execution on glibc-based Linux by supplying crafted images. Attackers can submit malicious AVIF/HEIF input to applications processing untrusted images with sharp, triggering libheif decoding flaws to execute code. |
| The Nuvoton NPCX eSPI driver parses Target-Attached-Flash (TAF) requests in espi_taf_parse() (drivers/espi/espi_npcx.c), taking the 12-bit length field directly out of the request header in the FLASHRXBUF FIFO. For write and RPMC OP1 requests it copied DIV_ROUND_UP(len, 4) words into struct espi_taf_pckt.src, a fixed 16-word (64-byte) member of a static structure, without ever comparing the length against that buffer or against the negotiated eSPI receive payload size (rx-plsize, 64 bytes on all in-tree NPCX/NPCK SoCs). Both the loop counter and the word count were uint8_t, so the copy ran up to 255 iterations.
An eSPI controller that emits a flash request whose header claims a payload larger than the negotiated maximum therefore drives up to 239 32-bit stores past the end of the structure — roughly 956 bytes of out-of-bounds write into .bss — from the eSPI flash receive interrupt handler, while the source reads walk past the end of the 18-word FLASHRXBUF register array into neighbouring eSPI registers. The same unvalidated length was then passed on to flash_write() in espi_taf_npcx_flash_write() with the 64-byte src buffer as source, reading up to 4 KB of adjacent controller SRAM into SPI flash at a host-chosen address, where the host can read it back. A related fixed-size stack buffer in taf_npcx_completion_handler() was overflowed by four bytes on the maximum-size completion path on SoCs whose tx-plsize is 64.
The defect is reachable only from the eSPI host side, and only by a request that violates the negotiated payload size, so it requires host firmware or bus-level control rather than ordinary host software; a compliant maximum-length write fits the buffer exactly and is handled correctly. Because TAF exists specifically so that the embedded controller arbitrates host access to shared flash (espi_taf_check_read_protect() / espi_taf_check_write_protect()), corrupting controller memory from a host-supplied field crosses the trust boundary the feature asserts; consequences range from controller crash or hang to corruption of driver state that gates the flash protection regions.
The fix widens the counters, rejects any request whose word count exceeds both ARRAY_SIZE(FLASHRXBUF) - NPCX_ESPI_FLASH_HEADER_ADDRESS_LEN and NPCX_TAF_RX_PAYLOAD_WORDS (derived from the devicetree rx-plsize), marks such packets with a new invalid_flag so espi_taf_work() answers them with an unsuccessful completion instead of processing them, bounds the transmit payload against FLASHTXBUF, and adds a default case for unsupported cycle types. Only configurations with CONFIG_ESPI_TAF enabled on an NPCX/NPCK target are affected; no in-tree board enables it by default. |
| A flaw was found in mod_qos. An unauthenticated remote attacker can cause a Denial of Service (DoS) by maintaining numerous concurrent low-rate connections to a target server. When connection rate monitoring is active, the module fails to verify array boundaries when recording client IP addresses, allowing more connection records to be added than the allocated buffer can hold. This issue leads to heap memory corruption, which can crash the web server process. |
| Pillow is a Python imaging library. From 9.4.0 until 13.0.0, ImagingJpegEncode() in src/libImaging/JpegEncode.c can call jpeg_write_marker() for a JPEG COM comment when an ICC profile has exactly filled the 65536-byte encoder buffer. libjpeg writes one byte before checking the exhausted free_in_buffer counter, which then wraps and permits the attacker-controlled comment and subsequent compressed image data to overwrite adjacent heap memory. Re-saving an untrusted image as JPEG while preserving its ICC profile and forwarded comment can crash the process and may enable code execution in suitable runtime and heap layouts. This issue is fixed in version 13.0.0. |
