๐จ CVE-2026-17587
The My Agile Privacyยฎ โ CMP, Cookie Consent & Privacy Tools plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.3.6. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to modify plugin settings including missing_cookie_shield, cookie_shield_running, cmode_v2_js_on_error, cmode_v2_js_error_code, and cmode_v2_js_error_motivation stored in the plugin's settings key.
๐@cveNotify
The My Agile Privacyยฎ โ CMP, Cookie Consent & Privacy Tools plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.3.6. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to modify plugin settings including missing_cookie_shield, cookie_shield_running, cmode_v2_js_on_error, cmode_v2_js_error_code, and cmode_v2_js_error_motivation stored in the plugin's settings key.
๐@cveNotify
๐จ CVE-2026-77824
The Media Sweep โ WordPress Media Cleaner plugin for WordPress is vulnerable to generic SQL Injection via the 'fields' parameter in all versions up to, and including, 1.1.3 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with administrator-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.
๐@cveNotify
The Media Sweep โ WordPress Media Cleaner plugin for WordPress is vulnerable to generic SQL Injection via the 'fields' parameter in all versions up to, and including, 1.1.3 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with administrator-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.
๐@cveNotify
๐จ CVE-2026-55526
PraisonAI is a multi-agent teams system. Prior to praisonaiagents 1.6.58, spider_tools._host_is_blocked() does not resolve ordinary hostnames before scrape_page fetches them. A hostname such as 127.0.0.1.nip.io passes validation and resolves to loopback, permitting internal HTTP access. The fix uses socket.getaddrinfo and fails closed on DNS errors. This issue is fixed in version 1.6.58.
๐@cveNotify
PraisonAI is a multi-agent teams system. Prior to praisonaiagents 1.6.58, spider_tools._host_is_blocked() does not resolve ordinary hostnames before scrape_page fetches them. A hostname such as 127.0.0.1.nip.io passes validation and resolves to loopback, permitting internal HTTP access. The fix uses socket.getaddrinfo and fails closed on DNS errors. This issue is fixed in version 1.6.58.
๐@cveNotify
GitHub
refactor: harden input validation and query parameterization ยท MervinPraison/PraisonAI@2f9677a
Co-authored-by: Cursor <cursoragent@cursor.com>
๐จ CVE-2026-55527
PraisonAI is a multi-agent teams system. Prior to praisonaiagents 1.6.58, the FileMemory constructor joins unsanitized user_id into self.user_path. A caller supplying ../ or path separators can escape the memory directory and write JSON data to arbitrary process-writable locations. The fix sanitizes user_id before constructing self.user_path. This issue is fixed in version 1.6.58.
๐@cveNotify
PraisonAI is a multi-agent teams system. Prior to praisonaiagents 1.6.58, the FileMemory constructor joins unsanitized user_id into self.user_path. A caller supplying ../ or path separators can escape the memory directory and write JSON data to arbitrary process-writable locations. The fix sanitizes user_id before constructing self.user_path. This issue is fixed in version 1.6.58.
๐@cveNotify
GitHub
refactor: harden input validation and query parameterization ยท MervinPraison/PraisonAI@2f9677a
Co-authored-by: Cursor <cursoragent@cursor.com>
๐จ CVE-2026-55539
PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.51, the Jobs API create_app function mounts /api/v1/runs without authentication. Any reachable caller can submit jobs, read results, cancel runs, or delete jobs using operator credentials. The fix adds PRAISONAI_JOBS_API_KEY middleware for Authorization or X-API-Key. This issue is fixed in version 4.6.58.
๐@cveNotify
PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.51, the Jobs API create_app function mounts /api/v1/runs without authentication. Any reachable caller can submit jobs, read results, cancel runs, or delete jobs using operator credentials. The fix adds PRAISONAI_JOBS_API_KEY middleware for Authorization or X-API-Key. This issue is fixed in version 4.6.58.
๐@cveNotify
GitHub
refactor: harden input validation and query parameterization ยท MervinPraison/PraisonAI@2f9677a
Co-authored-by: Cursor <cursoragent@cursor.com>
๐จ CVE-2026-55640
Nextcloud MCP Server is a production-ready MCP server that connects AI assistants to a Nextcloud instance. Prior to 0.117.2, the POST /webhooks/nextcloud endpoint in nextcloud_mcp_server/vector/webhook_receiver.py has no authentication by default because WEBHOOK_SECRET defaults to None and startup validation does not require it. When WEBHOOK_SECRET is unset, handle_nextcloud_webhook() accepts unauthenticated requests. The payload["user"]["uid"] field parsed in nextcloud_mcp_server/vector/webhook_parser.py is attacker-controlled and is used without an authenticated-session cross-check for Qdrant operations, allowing a network attacker to delete or trigger re-indexing of vector embeddings for any user and to destroy the semantic search index by sending forged deletion events. This issue is fixed in version 0.117.2.
๐@cveNotify
Nextcloud MCP Server is a production-ready MCP server that connects AI assistants to a Nextcloud instance. Prior to 0.117.2, the POST /webhooks/nextcloud endpoint in nextcloud_mcp_server/vector/webhook_receiver.py has no authentication by default because WEBHOOK_SECRET defaults to None and startup validation does not require it. When WEBHOOK_SECRET is unset, handle_nextcloud_webhook() accepts unauthenticated requests. The payload["user"]["uid"] field parsed in nextcloud_mcp_server/vector/webhook_parser.py is attacker-controlled and is used without an authenticated-session cross-check for Qdrant operations, allowing a network attacker to delete or trigger re-indexing of vector embeddings for any user and to destroy the semantic search index by sending forged deletion events. This issue is fixed in version 0.117.2.
๐@cveNotify
GitHub
fix(security): require WEBHOOK_SECRET for the Nextcloud webhook receiver ยท cbcoutinho/nextcloud-mcp-server@4fc2b10
GHSA-8vh3-g2qg-2h2c (CVSS 9.1, CWE-306): POST /webhooks/nextcloud had no
authentication when WEBHOOK_SECRET was unset (the default). The receiver
trusted the attacker-supplied user.uid and fed it t...
authentication when WEBHOOK_SECRET was unset (the default). The receiver
trusted the attacker-supplied user.uid and fed it t...
๐จ 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....