🚨 CVE-2026-13216
The virtio PCI driver (drivers/virtio/virtio_pci.c) parses a device's PCI capability list during driver initialization. In virtio_pci_read_cap() the device-supplied capability length byte cap_len (read from PCI config space via pcie_conf_read()) was only checked with assert(tmp.cap_len == cap_struct_size). That assert resolves to __ASSERT_NO_MSG(), gated by CONFIG_ASSERT, which defaults off in production builds, so the value reached the copy logic completely unvalidated.
The length then drives a loop that copies extra capability dwords into a fixed-size stack buffer supplied by the caller. A cap_len below the 24-byte base struct virtio_pci_cap underflows the unsigned extra_data_words count to a near-SIZE_MAX value, producing an effectively unbounded stack write; a cap_len above the caller's buffer (up to 255) writes up to roughly 228 bytes of device-controlled data past the buffer. Both are out-of-bounds writes of attacker-controlled content executed in kernel mode during boot-time device probe.
The input originates from the virtio device. In the common deployment where Zephyr runs as a guest under a hypervisor, the device backend is the host, which already fully outranks the guest, so the bug yields no privilege escalation. The exploitable case is a virtio device that is untrusted relative to the Zephyr kernel — an untrusted or physical/passthrough virtio PCIe device on a bare-metal system, or a confidential-computing posture where the guest must defend against the host — where a malicious device can corrupt the kernel stack and potentially achieve code execution or a crash.
The fix replaces the compiled-out assert with a runtime range check rejecting cap_len outside [sizeof(struct virtio_pci_cap), cap_struct_size] before any arithmetic or copy.
🎖@cveNotify
The virtio PCI driver (drivers/virtio/virtio_pci.c) parses a device's PCI capability list during driver initialization. In virtio_pci_read_cap() the device-supplied capability length byte cap_len (read from PCI config space via pcie_conf_read()) was only checked with assert(tmp.cap_len == cap_struct_size). That assert resolves to __ASSERT_NO_MSG(), gated by CONFIG_ASSERT, which defaults off in production builds, so the value reached the copy logic completely unvalidated.
The length then drives a loop that copies extra capability dwords into a fixed-size stack buffer supplied by the caller. A cap_len below the 24-byte base struct virtio_pci_cap underflows the unsigned extra_data_words count to a near-SIZE_MAX value, producing an effectively unbounded stack write; a cap_len above the caller's buffer (up to 255) writes up to roughly 228 bytes of device-controlled data past the buffer. Both are out-of-bounds writes of attacker-controlled content executed in kernel mode during boot-time device probe.
The input originates from the virtio device. In the common deployment where Zephyr runs as a guest under a hypervisor, the device backend is the host, which already fully outranks the guest, so the bug yields no privilege escalation. The exploitable case is a virtio device that is untrusted relative to the Zephyr kernel — an untrusted or physical/passthrough virtio PCIe device on a bare-metal system, or a confidential-computing posture where the guest must defend against the host — where a malicious device can corrupt the kernel stack and potentially achieve code execution or a crash.
The fix replaces the compiled-out assert with a runtime range check rejecting cap_len outside [sizeof(struct virtio_pci_cap), cap_struct_size] before any arithmetic or copy.
🎖@cveNotify
GitHub
drivers: virtio: validate PCI capability length at runtime · zephyrproject-rtos/zephyr@d98dace
virtio_pci_read_cap() only asserted cap_len == cap_struct_size, which
compiles out in production. A device-supplied cap_len below the base
struct size underflows extra_data_words, and a value above...
compiles out in production. A device-supplied cap_len below the base
struct size underflows extra_data_words, and a value above...
🚨 CVE-2026-13217
The OCPP 1.6 client in subsys/net/lib/ocpp/ocpp.c reconstructs a session handle and PDU id from the uid field of a CALLRESULT message. In ocpp_process_server_msg() the code calls atoi(strtok_r(uid, "-", &tmp)) without checking the strtok_r return value. When the server-supplied uid is empty or contains no - delimiter, strtok_r() returns NULL and atoi(NULL) dereferences a NULL pointer, which is undefined behaviour.
The uid originates from network data: parse_rpc_msg() in subsys/net/lib/ocpp/ocpp_j.c JSON-parses a frame received from the OCPP central system over TCP/WebSocket and copies the server-controlled string into the local buffer. A malicious or compromised central system, or a man-in-the-middle on a non-TLS ws:// connection, can return a malformed uid to reach the defect. No authentication beyond the existing server connection (or MITM position) is required, and the reconstructed pointer is membership-validated by ocpp_session_is_valid(), so the impact is limited to the NULL dereference rather than arbitrary pointer use.
On Zephyr targets that trap access to address 0 (MMU/MPU platforms or CONFIG_NULL_POINTER_EXCEPTION_DETECTION), the dereference faults inside the OCPP reader thread and invokes the fatal handler, producing a remote denial of service of the charge point; on bare targets where address 0 is readable the call returns 0 and is benign, so the impact is availability-only and platform-conditional.
The applied fix guards only the first atoi(); the second strtok_r(NULL, "-", &tmp) followed by pdu = atoi(buf) in the same function remains unguarded and the identical NULL dereference is still reachable from the same network input when the uid has a first token but no second --delimited token. A complete fix should validate the second token as well.
🎖@cveNotify
The OCPP 1.6 client in subsys/net/lib/ocpp/ocpp.c reconstructs a session handle and PDU id from the uid field of a CALLRESULT message. In ocpp_process_server_msg() the code calls atoi(strtok_r(uid, "-", &tmp)) without checking the strtok_r return value. When the server-supplied uid is empty or contains no - delimiter, strtok_r() returns NULL and atoi(NULL) dereferences a NULL pointer, which is undefined behaviour.
The uid originates from network data: parse_rpc_msg() in subsys/net/lib/ocpp/ocpp_j.c JSON-parses a frame received from the OCPP central system over TCP/WebSocket and copies the server-controlled string into the local buffer. A malicious or compromised central system, or a man-in-the-middle on a non-TLS ws:// connection, can return a malformed uid to reach the defect. No authentication beyond the existing server connection (or MITM position) is required, and the reconstructed pointer is membership-validated by ocpp_session_is_valid(), so the impact is limited to the NULL dereference rather than arbitrary pointer use.
On Zephyr targets that trap access to address 0 (MMU/MPU platforms or CONFIG_NULL_POINTER_EXCEPTION_DETECTION), the dereference faults inside the OCPP reader thread and invokes the fatal handler, producing a remote denial of service of the charge point; on bare targets where address 0 is readable the call returns 0 and is benign, so the impact is availability-only and platform-conditional.
The applied fix guards only the first atoi(); the second strtok_r(NULL, "-", &tmp) followed by pdu = atoi(buf) in the same function remains unguarded and the identical NULL dereference is still reachable from the same network input when the uid has a first token but no second --delimited token. A complete fix should validate the second token as well.
🎖@cveNotify
GitHub
net: ocpp: guard second strtok_r return before atoi · zephyrproject-rtos/zephyr@3a55507
ocpp_process_server_msg() guards the first strtok_r(uid, "-", &tmp)
result but then calls atoi() on the second strtok_r(NULL, "-", &tmp)
result w...
result but then calls atoi() on the second strtok_r(NULL, "-", &tmp)
result w...
🚨 CVE-2026-13478
The Zephyr ext2 filesystem driver validates the on-disk block bitmap in ext2_init_fs() (subsys/fs/ext2/ext2_impl.c) by passing fs_blocks = s_blocks_count - s_first_data_block to ext2_bitmap_count_set(). That helper (subsys/fs/ext2/ext2_bitmap.c) treats its argument as a number of bits and reads one bitmap byte per eight bits, but the bitmap buffer (BGROUP_BLOCK_BITMAP) is a single fetched block of only fs->block_size bytes (capacity fs->block_size * 8 bits). s_blocks_count and s_first_data_block are taken verbatim from the superblock and were never bounded against this single-group capacity; ext2_verify_disk_superblock() checks the magic, revision, and block-size shift but not the block count.
A crafted ext2 image with an oversized s_blocks_count (up to ~4 billion, against a maximum 4096-byte block / 32768-bit bitmap) makes ext2_bitmap_count_set() scan roughly 512 MB of memory past the bitmap block — a large out-of-bounds read of the static block slab and adjacent memory.
The defect is reached during mount: ext2_init_fs() is invoked from ext2_mount() (subsys/fs/ext2/ext2_ops.c), the registered .mount operation. Any path that mounts an attacker-supplied ext2 image (removable media, a disk/flash partition, or a downloaded image) triggers it. The kernel-privileged parser operates on attacker-controlled data, so the bug is exploitable wherever untrusted ext2 media can be mounted.
Impact is an out-of-bounds read only: the resulting bit count is compared internally and the mount is rejected, so no attacker-controlled bytes are returned (not a useful information leak). The ~512 MB over-read will almost certainly cross an unmapped or MPU-protected boundary and fault, crashing the system — a denial of service triggered by mounting a single malformed image. The fix rejects any image whose fs_blocks exceeds fs->block_size * 8 before the scan.
🎖@cveNotify
The Zephyr ext2 filesystem driver validates the on-disk block bitmap in ext2_init_fs() (subsys/fs/ext2/ext2_impl.c) by passing fs_blocks = s_blocks_count - s_first_data_block to ext2_bitmap_count_set(). That helper (subsys/fs/ext2/ext2_bitmap.c) treats its argument as a number of bits and reads one bitmap byte per eight bits, but the bitmap buffer (BGROUP_BLOCK_BITMAP) is a single fetched block of only fs->block_size bytes (capacity fs->block_size * 8 bits). s_blocks_count and s_first_data_block are taken verbatim from the superblock and were never bounded against this single-group capacity; ext2_verify_disk_superblock() checks the magic, revision, and block-size shift but not the block count.
A crafted ext2 image with an oversized s_blocks_count (up to ~4 billion, against a maximum 4096-byte block / 32768-bit bitmap) makes ext2_bitmap_count_set() scan roughly 512 MB of memory past the bitmap block — a large out-of-bounds read of the static block slab and adjacent memory.
The defect is reached during mount: ext2_init_fs() is invoked from ext2_mount() (subsys/fs/ext2/ext2_ops.c), the registered .mount operation. Any path that mounts an attacker-supplied ext2 image (removable media, a disk/flash partition, or a downloaded image) triggers it. The kernel-privileged parser operates on attacker-controlled data, so the bug is exploitable wherever untrusted ext2 media can be mounted.
Impact is an out-of-bounds read only: the resulting bit count is compared internally and the mount is rejected, so no attacker-controlled bytes are returned (not a useful information leak). The ~512 MB over-read will almost certainly cross an unmapped or MPU-protected boundary and fault, crashing the system — a denial of service triggered by mounting a single malformed image. The fix rejects any image whose fs_blocks exceeds fs->block_size * 8 before the scan.
🎖@cveNotify
GitHub
fs: ext2: reject s_blocks_count exceeding single-group bitmap capacity · zephyrproject-rtos/zephyr@9c0f869
The block bitmap validation passed
fs_blocks = s_blocks_count - s_first_data_block
directly to ext2_bitmap_count_set() without checking whether it exceeds
the bitmap's capacity of block_s...
fs_blocks = s_blocks_count - s_first_data_block
directly to ext2_bitmap_count_set() without checking whether it exceeds
the bitmap's capacity of block_s...
🚨 CVE-2026-18444
There is an integer conversion vulnerability resulting in an out-of-bounds read when loading images recently discovered in NI LabVIEW. This may result in information disclosure or arbitrary code execution. Successful exploitation requires an attacker to get a user to open a specially crafted VI file. This vulnerability affects NI LabVIEW 2026 Q3 and prior versions.
🎖@cveNotify
There is an integer conversion vulnerability resulting in an out-of-bounds read when loading images recently discovered in NI LabVIEW. This may result in information disclosure or arbitrary code execution. Successful exploitation requires an attacker to get a user to open a specially crafted VI file. This vulnerability affects NI LabVIEW 2026 Q3 and prior versions.
🎖@cveNotify
Ni
Integer Conversion Vulnerability Resulting in an Out of Bounds Read in NI LabVIEW
There is an integer conversion vulnerability resulting in an out-of-bounds read when loading images recently discovered in NI LabVIEW. This may result in information disclosure or arbitrary code execution. Successful exploitation requires an attacker to…
🚨 CVE-2026-18445
There is an integer overflow vulnerability resulting in an out-of-bounds write recently discovered in NI LabVIEW. This may result in information disclosure or arbitrary code execution. Successful exploitation requires an attacker to get a user to open a specially crafted VI file. This vulnerability affects NI LabVIEW 2026 Q3 and prior versions.
🎖@cveNotify
There is an integer overflow vulnerability resulting in an out-of-bounds write recently discovered in NI LabVIEW. This may result in information disclosure or arbitrary code execution. Successful exploitation requires an attacker to get a user to open a specially crafted VI file. This vulnerability affects NI LabVIEW 2026 Q3 and prior versions.
🎖@cveNotify
Ni
Integer Overflow Vulnerability Resulting in an Out of Bounds Write in NI LabVIEW
There is an integer overflow vulnerability resulting in an out-of-bounds write recently discovered in NI LabVIEW. This may result in information disclosure or arbitrary code execution. Successful exploitation requires an attacker to get a user to open a…
🚨 CVE-2026-24166
NVIDIA UFM Enterprise contains a vulnerability in the session management component, where an attacker could use a hard-coded cryptographic key to extract information. A successful exploit of this vulnerability might lead to information disclosure and escalation of privileges.
🎖@cveNotify
NVIDIA UFM Enterprise contains a vulnerability in the session management component, where an attacker could use a hard-coded cryptographic key to extract information. A successful exploit of this vulnerability might lead to information disclosure and escalation of privileges.
🎖@cveNotify
GitHub
product-security/2026/5809 at main · NVIDIA/product-security
Starting October 1, 2025, NVIDIA PSIRT will publish an initial set of security bulletins on GitHub in Markdown, CSAF, and CVE formats. Coverage will expand over time, while all bulletins remain ava...
🚨 CVE-2026-24167
NVIDIA UFM Enterprise contains a vulnerability in the user management component, where an authenticated administrator could inject commands by sending a crafted API request. A successful exploit of this vulnerability might lead to code execution, escalation of privileges and information disclosure.
🎖@cveNotify
NVIDIA UFM Enterprise contains a vulnerability in the user management component, where an authenticated administrator could inject commands by sending a crafted API request. A successful exploit of this vulnerability might lead to code execution, escalation of privileges and information disclosure.
🎖@cveNotify
GitHub
product-security/2026/5809 at main · NVIDIA/product-security
Starting October 1, 2025, NVIDIA PSIRT will publish an initial set of security bulletins on GitHub in Markdown, CSAF, and CVE formats. Coverage will expand over time, while all bulletins remain ava...
🚨 CVE-2026-24168
NVIDIA UFM Enterprise contains a vulnerability in the IBDiagnet API where an authenticated attacker with administrative privileges may cause command injection by sending crafted API requests. A successful exploit of this vulnerability may lead to code execution, escalation of privileges and information disclosure.
🎖@cveNotify
NVIDIA UFM Enterprise contains a vulnerability in the IBDiagnet API where an authenticated attacker with administrative privileges may cause command injection by sending crafted API requests. A successful exploit of this vulnerability may lead to code execution, escalation of privileges and information disclosure.
🎖@cveNotify
GitHub
product-security/2026/5809 at main · NVIDIA/product-security
Starting October 1, 2025, NVIDIA PSIRT will publish an initial set of security bulletins on GitHub in Markdown, CSAF, and CVE formats. Coverage will expand over time, while all bulletins remain ava...
🚨 CVE-2026-24169
NVIDIA UFM Enterprise contains a vulnerability in the plugin management API, where an authenticated user with low privileges could inject code by sending a specially crafted API request. A successful exploit of this vulnerability might lead to code execution, escalation of privileges and information disclosure.
🎖@cveNotify
NVIDIA UFM Enterprise contains a vulnerability in the plugin management API, where an authenticated user with low privileges could inject code by sending a specially crafted API request. A successful exploit of this vulnerability might lead to code execution, escalation of privileges and information disclosure.
🎖@cveNotify
GitHub
product-security/2026/5809 at main · NVIDIA/product-security
Starting October 1, 2025, NVIDIA PSIRT will publish an initial set of security bulletins on GitHub in Markdown, CSAF, and CVE formats. Coverage will expand over time, while all bulletins remain ava...
🚨 CVE-2026-24170
NVIDIA UFM Enterprise contains a vulnerability in the web interface authorization component, where an authenticated user could cause improper authentication by sending specially crafted HTTP requests. A successful exploit of this vulnerability might lead to code execution and escalation of privileges.
🎖@cveNotify
NVIDIA UFM Enterprise contains a vulnerability in the web interface authorization component, where an authenticated user could cause improper authentication by sending specially crafted HTTP requests. A successful exploit of this vulnerability might lead to code execution and escalation of privileges.
🎖@cveNotify
GitHub
product-security/2026/5809 at main · NVIDIA/product-security
Starting October 1, 2025, NVIDIA PSIRT will publish an initial set of security bulletins on GitHub in Markdown, CSAF, and CVE formats. Coverage will expand over time, while all bulletins remain ava...
🚨 CVE-2026-24225
NVIDIA DGX Spark contains a vulnerability in the standalone MM firmware where an attacker could be able to cause an out-of-bounds read. A successful exploit of this vulnerability might lead to information disclosure.
🎖@cveNotify
NVIDIA DGX Spark contains a vulnerability in the standalone MM firmware where an attacker could be able to cause an out-of-bounds read. A successful exploit of this vulnerability might lead to information disclosure.
🎖@cveNotify
GitHub
product-security/2026/5867 at main · NVIDIA/product-security
Starting October 1, 2026, NVIDIA PSIRT will only publish security bulletins on GitHub in Markdown, CSAF, and CVE formats to meet industry demand for easier integration. - NVIDIA/product-security
🚨 CVE-2026-24262
NVIDIA DGX Spark contains a vulnerability in the system firmware, where a privileged attacker could be able to cause an out-of-bounds write. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, denial of service, information disclosure, and data tampering.
🎖@cveNotify
NVIDIA DGX Spark contains a vulnerability in the system firmware, where a privileged attacker could be able to cause an out-of-bounds write. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, denial of service, information disclosure, and data tampering.
🎖@cveNotify
GitHub
product-security/2026/5867 at main · NVIDIA/product-security
Starting October 1, 2026, NVIDIA PSIRT will only publish security bulletins on GitHub in Markdown, CSAF, and CVE formats to meet industry demand for easier integration. - NVIDIA/product-security
🚨 CVE-2026-24263
NVIDIA DGX Spark contains a vulnerability in the system firmware, where a privileged attacker could be able to cause a NULL pointer dereference. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, denial of service, information disclosure, and data tampering.
🎖@cveNotify
NVIDIA DGX Spark contains a vulnerability in the system firmware, where a privileged attacker could be able to cause a NULL pointer dereference. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, denial of service, information disclosure, and data tampering.
🎖@cveNotify
GitHub
product-security/2026/5867 at main · NVIDIA/product-security
Starting October 1, 2026, NVIDIA PSIRT will only publish security bulletins on GitHub in Markdown, CSAF, and CVE formats to meet industry demand for easier integration. - NVIDIA/product-security
🚨 CVE-2026-47626
NVIDIA DGX Spark contains a vulnerability in the system firmware, where a privileged attacker could be able to cause an out-of-bounds write. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, denial of service, information disclosure, and data tampering.
🎖@cveNotify
NVIDIA DGX Spark contains a vulnerability in the system firmware, where a privileged attacker could be able to cause an out-of-bounds write. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, denial of service, information disclosure, and data tampering.
🎖@cveNotify
GitHub
product-security/2026/5867 at main · NVIDIA/product-security
Starting October 1, 2026, NVIDIA PSIRT will only publish security bulletins on GitHub in Markdown, CSAF, and CVE formats to meet industry demand for easier integration. - NVIDIA/product-security
🚨 CVE-2026-59184
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. Versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 allow a crafted EXR with a nonzero dataWindow.min to make TypedFlatImageChannel::row() return an invalid heap pointer, causing out-of-bounds or use-after-free writes. This occurs when an application writes rows through FlatHalfChannel::row(). Affected consumers are tools, converters, render pipeline components, or image-processing services that accept untrusted EXR files and use FlatHalfChannel::row() on loaded images. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
🎖@cveNotify
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. Versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 allow a crafted EXR with a nonzero dataWindow.min to make TypedFlatImageChannel::row() return an invalid heap pointer, causing out-of-bounds or use-after-free writes. This occurs when an application writes rows through FlatHalfChannel::row(). Affected consumers are tools, converters, render pipeline components, or image-processing services that accept untrusted EXR files and use FlatHalfChannel::row() on loaded images. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
🎖@cveNotify
GitHub
Fix OpenEXRUtil row() OOB read with non-zero data window origin (#2488) · AcademySoftwareFoundation/openexr@37f03b6
The row() method in TypedDeepImageChannel, TypedFlatImageChannel, and
SampleCountChannel is documented as 0-based within the data window,
but used the _base offset meant for absolute (x, y) access....
SampleCountChannel is documented as 0-based within the data window,
but used the _base offset meant for absolute (x, y) access....
🚨 CVE-2026-59982
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. OpenEXR versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 can return an out-of-bounds pointer from TypedDeepImageChannel::row() when a crafted deep EXR has a nonzero dataWindow origin. This vulnerability occurs because the API combines zero-based row access with an absolute-coordinate-adjusted base pointer, allowing a crash or limited information disclosure. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
🎖@cveNotify
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. OpenEXR versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 can return an out-of-bounds pointer from TypedDeepImageChannel::row() when a crafted deep EXR has a nonzero dataWindow origin. This vulnerability occurs because the API combines zero-based row access with an absolute-coordinate-adjusted base pointer, allowing a crash or limited information disclosure. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.
🎖@cveNotify
GitHub
Fix OpenEXRUtil row() OOB read with non-zero data window origin (#2488) · AcademySoftwareFoundation/openexr@37f03b6
The row() method in TypedDeepImageChannel, TypedFlatImageChannel, and
SampleCountChannel is documented as 0-based within the data window,
but used the _base offset meant for absolute (x, y) access....
SampleCountChannel is documented as 0-based within the data window,
but used the _base offset meant for absolute (x, y) access....
🚨 CVE-2026-80051
github.com/graphql-go/graphql (GraphQL for Go) through 0.8.1 does not validate that a scalar variable value matches its declared type. The built-in coerceString and coerceBool functions (scalars.go) accept input whose type does not match the declared String, ID, or Boolean scalar instead of raising the request error that the GraphQL specification mandates. In some cases (but not any typical case of JSON sent to a website), a deeply nested value leads to an unrecoverable "fatal error: stack overflow" condition.
🎖@cveNotify
github.com/graphql-go/graphql (GraphQL for Go) through 0.8.1 does not validate that a scalar variable value matches its declared type. The built-in coerceString and coerceBool functions (scalars.go) accept input whose type does not match the declared String, ID, or Boolean scalar instead of raising the request error that the GraphQL specification mandates. In some cases (but not any typical case of JSON sent to a website), a deeply nested value leads to an unrecoverable "fatal error: stack overflow" condition.
🎖@cveNotify
GitHub
graphql/scalars.go at v0.8.1 · graphql-go/graphql
An implementation of GraphQL for Go / Golang. Contribute to graphql-go/graphql development by creating an account on GitHub.
🚨 CVE-2026-55619
eml_parser serves as a python module for parsing eml files and returning various information found in the e-mail as well as computed information. Prior to 3.0.2, eml_parser.parser.HeaderParser.header_fetch_parse in eml_parser/parser.py uses email.utils.getaddresses() to parse address-bearing e-mail headers. A deeply nested CFWS comment construct exhausts the standard-library recursive descent parser's call stack and raises RecursionError, which is not caught and therefore aborts parsing of the entire message. An attacker can disrupt SOC pipelines that process untrusted EML files, although callers already need to handle exceptions from malformed or pathological messages. This issue is fixed in version 3.0.2.
🎖@cveNotify
eml_parser serves as a python module for parsing eml files and returning various information found in the e-mail as well as computed information. Prior to 3.0.2, eml_parser.parser.HeaderParser.header_fetch_parse in eml_parser/parser.py uses email.utils.getaddresses() to parse address-bearing e-mail headers. A deeply nested CFWS comment construct exhausts the standard-library recursive descent parser's call stack and raises RecursionError, which is not caught and therefore aborts parsing of the entire message. An attacker can disrupt SOC pipelines that process untrusted EML files, although callers already need to handle exceptions from malformed or pathological messages. This issue is fixed in version 3.0.2.
🎖@cveNotify
GitHub
Address security advisories (#90) · GOVCERT-LU/eml_parser@746a69f
* handle exceeded stack limit in header parsing
* fix slow parenthesis removal
* Improve documentation of `noparenthesis`.
* Properly handle HTML entities in URLs
This also runs the domain pars...
* fix slow parenthesis removal
* Improve documentation of `noparenthesis`.
* Properly handle HTML entities in URLs
This also runs the domain pars...
🚨 CVE-2026-62986
OpenEXR is the reference implementation and specification for the EXR image file format, widely used in the motion picture industry. In versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13, the PyOpenEXR Python bindings return stale heap data when reading a crafted deep scanline EXR that uses layer-prefixed RGB channels. With the default channel coalescing (separate_channels=False), the wrapper groups channels such as left.R, left.G, and left.B into a single RGB sample array, but the lane-offset calculation in PyPart::setDeepSliceData() only recognizes the exact unprefixed names G, B, and A. As a result, prefixed channels like left.G and left.B are decoded into lane 0 while lanes 1 and 2 are left uninitialized and returned to Python. A Python application that reads untrusted deep EXR files through the default OpenEXR.File API and then logs, serializes, previews, or otherwise processes the resulting NumPy sample arrays may expose uninitialized same-process heap contents, in addition to receiving incorrect green and blue channel data. This issue is fixed in versions 3.3.13 and 3.4.14.
🎖@cveNotify
OpenEXR is the reference implementation and specification for the EXR image file format, widely used in the motion picture industry. In versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13, the PyOpenEXR Python bindings return stale heap data when reading a crafted deep scanline EXR that uses layer-prefixed RGB channels. With the default channel coalescing (separate_channels=False), the wrapper groups channels such as left.R, left.G, and left.B into a single RGB sample array, but the lane-offset calculation in PyPart::setDeepSliceData() only recognizes the exact unprefixed names G, B, and A. As a result, prefixed channels like left.G and left.B are decoded into lane 0 while lanes 1 and 2 are left uninitialized and returned to Python. A Python application that reads untrusted deep EXR files through the default OpenEXR.File API and then logs, serializes, previews, or otherwise processes the resulting NumPy sample arrays may expose uninitialized same-process heap contents, in addition to receiving incorrect green and blue channel data. This issue is fixed in versions 3.3.13 and 3.4.14.
🎖@cveNotify
GitHub
Fix name comparison in deep prefixed RGB channel coalescing (#2522) · AcademySoftwareFoundation/openexr@36ff096
setDeepSliceData() used strcmp(c.name(), "G"/"B"/"A") to select the
RGB channel offset, which only matched unprefixed channel names. For
layer-...
RGB channel offset, which only matched unprefixed channel names. For
layer-...
🚨 CVE-2026-65979
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk's compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.
🎖@cveNotify
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. From version 3.4.0 through 3.4.12, the HTJ2K decoder parses a header-length field (PLEN) from a chunk's compressed data but never checks that this value fits within the available buffer before using it. When decoding, it advances the codestream pointer by the attacker-supplied header size and passes the resulting offset and remaining length to the OpenJPH memory-input path, so a crafted value pushes the pointer past the end of the buffer and causes an out-of-bounds read. Because this field comes straight from attacker-controlled EXR chunk data, the flaw is reachable during normal decoding of an untrusted file. This issue is fixed in version 3.4.13.
🎖@cveNotify
GitHub
Validate HTJ2K chunk header length before decode (#2434) · AcademySoftwareFoundation/openexr@c7af2d2
* Validate HTJ2K chunk header length before decode
Reject oversized or inconsistent header payload lengths so corrupted
chunks cannot advance the codestream pointer past the compressed buffer.
Add...
Reject oversized or inconsistent header payload lengths so corrupted
chunks cannot advance the codestream pointer past the compressed buffer.
Add...
🚨 CVE-2026-78379
Improper neutralization of input used for LLM prompting in the python_repl tool in Amazon Strands Agents Tools before 0.8.5 might allow remote actors to execute arbitrary Python code on the agent's host by bypassing the human consent gate, via a crafted prompt that forwards non_interactive_mode as a keyword argument through the batch tool. To remediate this issue, users should upgrade to version 0.8.5 or later.
🎖@cveNotify
Improper neutralization of input used for LLM prompting in the python_repl tool in Amazon Strands Agents Tools before 0.8.5 might allow remote actors to execute arbitrary Python code on the agent's host by bypassing the human consent gate, via a crafted prompt that forwards non_interactive_mode as a keyword argument through the batch tool. To remediate this issue, users should upgrade to version 0.8.5 or later.
🎖@cveNotify