| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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. |
| 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. |
| Ghidra 10.2 through 12.1.4 contains a denial of service vulnerability in the ELF loader's ElfHeader class that allocates arrays sized by unvalidated extended section and program header counts. Attackers can supply a crafted 128-byte ELF file that triggers an OutOfMemoryError during load-spec discovery at import or in headless analysis pipelines. |
| virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, virtualenv's ScriptMakerCustom and pip pass an incompletely quoted interpreter path to distlib ScriptMaker when generating POSIX console scripts. When the path contains a space or produces a shebang longer than 127 bytes, distlib emits a /bin/sh wrapper whose double-quoted interpreter path still expands command substitutions and backticks. An attacker who influences the environment destination can therefore execute commands with the user's privileges when the user later runs a generated launcher; environment creation and activation do not trigger the command. Existing launchers are not repaired by upgrading virtualenv alone and must be regenerated, while a later independent pip installation or upgrade can reintroduce an affected launcher because pip's vendored distlib is unchanged. The virtualenv fix is released in version 21.14.9. |
| virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.9, caller-supplied prompt text can become executable syntax in the bash activation prompt. An attacker must influence the value passed to virtualenv, and a user must subsequently activate the environment and draw the prompt. This vulnerability is fixed in 21.14.9. |
| virtualenv is a tool for creating isolated virtual python environments. Prior to 21.14.7, the bash activate script escapes the environment name for only one of the two passes bash makes over PS1, so a backslash in the name undoes the escaping and a name containing \$(...) runs as commands in the user's shell each time bash draws the prompt. This issue is fixed in version 21.14.7. |
| virtualenv is a tool for creating isolated virtual python environments. From 20.26.6 until 21.14.2, ViaTemplateActivator.instantiate_template() replaces placeholders one key at a time across the complete activation template, so trigger names such as __VIRTUAL_NAME__, __VIRTUAL_ENV__, or __VIRTUAL_PROMPT__ inside an already substituted and quoted environment path or prompt can be replaced during a later pass. The later value's quoting can close the earlier literal and execute the remaining path when a user activates the environment through bash, fish, xonsh, or activate_this.py. The distinct csh prompt-display token __VIRTUAL_PROMPT_DISPLAY_TCSH__ can instead break the generated script without establishing command execution. The attacker must influence the destination path or --prompt, and a value without a relevant placeholder name does not trigger this mechanism. This issue is fixed in version 21.14.2. |
| virtualenv is a tool for creating isolated virtual python environments. Prior to 21.13.0, the bash activate script that zsh also sources leaves the environment name unescaped; from 21.13.0 until 21.14.4, it escapes backslashes, dollar signs, and backticks only when BASH_VERSION is set, so zsh receives the raw value. The script assigns that value to PS1. In zsh with PROMPT_SUBST, an attacker-influenced environment directory, --prompt, or VIRTUALENV_PROMPT value containing command, parameter, or arithmetic expansion syntax can therefore execute commands in the user's shell each time the prompt is drawn. A percent sign is separately interpreted as a zsh prompt escape but does not by itself execute commands. Plain zsh with PROMPT_SUBST disabled and bash are not affected by this mechanism. This issue is fixed in version 21.14.4. |
| 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. |
| 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. |
| Lagoon is an application delivery platform for Kubernetes. Versions prior to 2.33.1 have a vulnerability in the `ssh` service in Lagoon core that would allow an attacker to execute arbitrary code which could lead to, among other things, elevated administrative permissions. It is mitigated by the fact that an attacker must have a Lagoon user account. Exploitation may be detected by checking the container logs of the `ssh` service for: `too many arguments`. The vulnerability was fixed in Lagoon v2.33.2, which is included in the `lagoon/lagoon-core` helm chart v1.62.2. As a workaround, the `ssh` service in Lagoon core can be disabled. The `ssh-portal` service and components are not effected and can continue to be used. |
