๐จ CVE-2026-82921
A weakness has been identified in ShopEx ECShop up to 2.5.1. This affects the function check_img_type of the file admin/pack.php. Executing a manipulation of the argument pack_img can lead to unrestricted upload. It is possible to launch the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
A weakness has been identified in ShopEx ECShop up to 2.5.1. This affects the function check_img_type of the file admin/pack.php. Executing a manipulation of the argument pack_img can lead to unrestricted upload. It is possible to launch the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
uvxbywu62qm.feishu.cn
Docs
๐จ CVE-2026-82922
A security vulnerability has been detected in ShopEx ECShop up to 2.5.1. This vulnerability affects the function flow_update_cart of the file /flow.php?step=update_cart. The manipulation of the argument rec_id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
A security vulnerability has been detected in ShopEx ECShop up to 2.5.1. This vulnerability affects the function flow_update_cart of the file /flow.php?step=update_cart. The manipulation of the argument rec_id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
uvxbywu62qm.feishu.cn
Docs
๐จ CVE-2026-82954
A vulnerability was detected in Dokploy up to 0.29.7. This issue affects the function writeTraefikConfigInPath of the file packages/server/src/utils/traefik/application.ts of the component Settings. The manipulation of the argument path results in path traversal. The attack can be launched remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
A vulnerability was detected in Dokploy up to 0.29.7. This issue affects the function writeTraefikConfigInPath of the file packages/server/src/utils/traefik/application.ts of the component Settings. The manipulation of the argument path results in path traversal. The attack can be launched remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
Vulnerability Database
CVE-2026-82954 in Dokploy
A vulnerability was detected in Dokploy up to 0.29.7. This vulnerability is reported as CVE-2026-82954.
๐จ CVE-2026-82957
A vulnerability was found in hyperledger-firefly firefly up to 1.4.0. The impacted element is the function ValidateOptions of the file internal/events/webhooks/webhooks.go of the component Webhook Subscription. Performing a manipulation of the argument url results in server-side request forgery. Remote exploitation of the attack is possible. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
A vulnerability was found in hyperledger-firefly firefly up to 1.4.0. The impacted element is the function ValidateOptions of the file internal/events/webhooks/webhooks.go of the component Webhook Subscription. Performing a manipulation of the argument url results in server-side request forgery. Remote exploitation of the attack is possible. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
Vulnerability Database
CVE-2026-82957 in firefly
A vulnerability was found in hyperledger-firefly firefly up to 1.4.0. This vulnerability is known as CVE-2026-82957.
๐จ CVE-2026-13481
The IEEE 1588 PTP management-message parser in subsys/net/lib/ptp/tlv.c mishandles the PTP_MGMT_TIME management id. In tlv_mgmt_post_recv(), the PTP_MGMT_TIME case casts mgmt_tlv->data to a 10-byte struct ptp_timestamp and reads it (then byte-swaps and writes it back) without first checking that the TLV data field is at least sizeof(struct ptp_timestamp). Every sibling management id in the same switch validates its length first; PTP_MGMT_TIME was the only case lacking that check.
The length passed in is the management data size (tlv->length - 2), and the upstream guard in ptp_tlv_post_recv() only requires tlv->length > 2, while msg_tlv_post_recv() validates only that the TLV fits within the received byte count, not a per-id minimum. A peer on the local PTP segment can therefore send a PTP_MSG_MANAGEMENT message carrying a short PTP_MGMT_TIME TLV (data as small as 2 bytes), causing the parser to read and write 8 bytes beyond the validated data. The message type and TLV contents are taken straight off the wire, so the path is reachable by any adjacent attacker when CONFIG_PTP is enabled.
The over-read and write-back stay within the struct ptp_msg allocation (mgmt_tlv->data lives in the leading mtu[NET_ETH_MTU] union member, so data + 10 lands at most a few bytes past mtu[], inside the same object), so this is an out-of-bounds read of adjacent in-object memory plus a bounded in-place corruption of the message's parsed timestamp, not past-allocation memory corruption. Impact is limited to minor information exposure of adjacent bytes and corruption of the device's parsed management TIME value; there is no crash on the access and no reachable reference-count corruption.
The fix adds if (length < sizeof(struct ptp_timestamp)) { return -EBADMSG; } before the cast, matching the other management-id cases and fully closing the receive-path defect.
๐@cveNotify
The IEEE 1588 PTP management-message parser in subsys/net/lib/ptp/tlv.c mishandles the PTP_MGMT_TIME management id. In tlv_mgmt_post_recv(), the PTP_MGMT_TIME case casts mgmt_tlv->data to a 10-byte struct ptp_timestamp and reads it (then byte-swaps and writes it back) without first checking that the TLV data field is at least sizeof(struct ptp_timestamp). Every sibling management id in the same switch validates its length first; PTP_MGMT_TIME was the only case lacking that check.
The length passed in is the management data size (tlv->length - 2), and the upstream guard in ptp_tlv_post_recv() only requires tlv->length > 2, while msg_tlv_post_recv() validates only that the TLV fits within the received byte count, not a per-id minimum. A peer on the local PTP segment can therefore send a PTP_MSG_MANAGEMENT message carrying a short PTP_MGMT_TIME TLV (data as small as 2 bytes), causing the parser to read and write 8 bytes beyond the validated data. The message type and TLV contents are taken straight off the wire, so the path is reachable by any adjacent attacker when CONFIG_PTP is enabled.
The over-read and write-back stay within the struct ptp_msg allocation (mgmt_tlv->data lives in the leading mtu[NET_ETH_MTU] union member, so data + 10 lands at most a few bytes past mtu[], inside the same object), so this is an out-of-bounds read of adjacent in-object memory plus a bounded in-place corruption of the message's parsed timestamp, not past-allocation memory corruption. Impact is limited to minor information exposure of adjacent bytes and corruption of the device's parsed management TIME value; there is no crash on the access and no reachable reference-count corruption.
The fix adds if (length < sizeof(struct ptp_timestamp)) { return -EBADMSG; } before the cast, matching the other management-id cases and fully closing the receive-path defect.
๐@cveNotify
GitHub
net: ptp: validate TLV length for MGMT_TIME before timestamp access ยท zephyrproject-rtos/zephyr@de98c37
The PTP_MGMT_TIME case in tlv_mgmt_post_recv() read mgmt_tlv->data as a
struct ptp_timestamp (10 bytes) without first checking that length >=
sizeof(struct ptp_timestamp), allowing a ...
struct ptp_timestamp (10 bytes) without first checking that length >=
sizeof(struct ptp_timestamp), allowing a ...
๐จ CVE-2026-82256
SvelteKit before 2.69.1 fails to properly validate remote form function payload sizes, allowing attackers to crash the Node process by sending large payloads. Repeated exploitation causes denial of service by repeatedly crashing the application process.
๐@cveNotify
SvelteKit before 2.69.1 fails to properly validate remote form function payload sizes, allowing attackers to crash the Node process by sending large payloads. Repeated exploitation causes denial of service by repeatedly crashing the application process.
๐@cveNotify
GitHub
Big remote form function payloads can cause Node process to crash
Big remote form function payloads can cause the Node process to crash. Doing this repeatedly can cause DoS.
๐จ CVE-2026-66324
External control of file name or path in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform spoofing over a network.
๐@cveNotify
External control of file name or path in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform spoofing over a network.
๐@cveNotify
๐จ CVE-2026-66798
Use after free in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.
๐@cveNotify
Use after free in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.
๐@cveNotify
๐จ CVE-2026-70309
Origin validation error in Microsoft Edge (Chromium-based) allows an unauthorized attacker to bypass a security feature over a network.
๐@cveNotify
Origin validation error in Microsoft Edge (Chromium-based) allows an unauthorized attacker to bypass a security feature over a network.
๐@cveNotify
๐จ CVE-2026-22244
OpenMetadata is a unified metadata platform. Versions 1.5.0 through 1.11.3 are vulnerable to remote code execution via Server-Side Template Injection (SSTI) in FreeMarker email templates. An attacker must have administrative privileges to exploit the vulnerability. Version 1.11.4 contains a patch.
๐@cveNotify
OpenMetadata is a unified metadata platform. Versions 1.5.0 through 1.11.3 are vulnerable to remote code execution via Server-Side Template Injection (SSTI) in FreeMarker email templates. An attacker must have administrative privileges to exploit the vulnerability. Version 1.11.4 contains a patch.
๐@cveNotify
GitHub
Vulnerability fix for 1.11.4 (#24945) ยท open-metadata/OpenMetadata@bffe7c4
* Vulnerability fix for 1.11.4
* log4j vulnerability fix
(cherry picked from commit fcc1cd9f5aa2a5da6452e4a9fb6cf4c0e16d49ff)
* log4j vulnerability fix
(cherry picked from commit fcc1cd9f5aa2a5da6452e4a9fb6cf4c0e16d49ff)
๐จ CVE-2026-13480
The LoRaWAN TS004 Fragmented Data Block Transport handler frag_transport_package_callback() in subsys/lorawan/services/frag_transport.c parses downlink command bytes without validating that enough payload bytes remain before each access. The loop's only bound is rx_pos < len; after consuming the one-byte command id the handler cast rx_buf + rx_pos to a 10-byte struct frag_transport_setup_req, and for a DATA_FRAGMENT command passed &rx_buf[rx_pos] to the fragment decoder, which reads exactly ctx.frag_size bytes โ with no remaining-length check in either case.
The fragment size is attacker-chosen in a preceding FRAG_SESSION_SETUP command (ctx.frag_size = req->frag_size, capped at CONFIG_LORAWAN_FRAG_TRANSPORT_MAX_FRAG_SIZE, default 232). rx_buf aliases the 255-byte static MacCtx.RxPayload buffer in the loramac-node MAC layer, while len is the actual decrypted payload length. By padding a downlink with mismatched-index DATA_FRAGMENT filler commands (each advancing rx_pos by three bytes without producing an answer) and appending one matching-index fragment near the end of the payload, an attacker can make the decoder read up to roughly frag_size bytes past the end of RxPayload, copying adjacent static memory into the decoder buffers and the FUOTA flash image.
The handler runs only on downlinks that have already passed the LoRaWAN frame MIC and FRMPayload decryption, so the defect is reachable only by a party holding the device's session keys (the FUOTA server or an attacker who has compromised those keys). The out-of-bounds bytes are never returned to the sender โ the only uplink emitted is a status answer carrying fragment counts โ so there is no direct disclosure channel, and on typical flat-memory LoRaWAN MCUs the over-read stays within mapped memory, making a crash unlikely. The impact is therefore a bounded out-of-bounds read with limited confidentiality consequence and no write or control-flow primitive. The fix adds remaining-length guards before each access.
๐@cveNotify
The LoRaWAN TS004 Fragmented Data Block Transport handler frag_transport_package_callback() in subsys/lorawan/services/frag_transport.c parses downlink command bytes without validating that enough payload bytes remain before each access. The loop's only bound is rx_pos < len; after consuming the one-byte command id the handler cast rx_buf + rx_pos to a 10-byte struct frag_transport_setup_req, and for a DATA_FRAGMENT command passed &rx_buf[rx_pos] to the fragment decoder, which reads exactly ctx.frag_size bytes โ with no remaining-length check in either case.
The fragment size is attacker-chosen in a preceding FRAG_SESSION_SETUP command (ctx.frag_size = req->frag_size, capped at CONFIG_LORAWAN_FRAG_TRANSPORT_MAX_FRAG_SIZE, default 232). rx_buf aliases the 255-byte static MacCtx.RxPayload buffer in the loramac-node MAC layer, while len is the actual decrypted payload length. By padding a downlink with mismatched-index DATA_FRAGMENT filler commands (each advancing rx_pos by three bytes without producing an answer) and appending one matching-index fragment near the end of the payload, an attacker can make the decoder read up to roughly frag_size bytes past the end of RxPayload, copying adjacent static memory into the decoder buffers and the FUOTA flash image.
The handler runs only on downlinks that have already passed the LoRaWAN frame MIC and FRMPayload decryption, so the defect is reachable only by a party holding the device's session keys (the FUOTA server or an attacker who has compromised those keys). The out-of-bounds bytes are never returned to the sender โ the only uplink emitted is a status answer carrying fragment counts โ so there is no direct disclosure channel, and on typical flat-memory LoRaWAN MCUs the over-read stays within mapped memory, making a crash unlikely. The impact is therefore a bounded out-of-bounds read with limited confidentiality consequence and no write or control-flow primitive. The fix adds remaining-length guards before each access.
๐@cveNotify
GitHub
lorawan: frag_transport: validate downlink length before struct cast ยท zephyrproject-rtos/zephyr@237309e
Two gaps in frag_transport_service_handler():
1. The FRAG_SESSION_SETUP case cast rx_buf + rx_pos to struct
frag_transport_setup_req (10 bytes) without checking remaining bytes.
2. The DATA_FRAG...
1. The FRAG_SESSION_SETUP case cast rx_buf + rx_pos to struct
frag_transport_setup_req (10 bytes) without checking remaining bytes.
2. The DATA_FRAG...
๐จ CVE-2026-59291
Potential arbitrary file read and SSRF vulnerability in Spring Cloud Function.
Spring Cloud Function 5.0.0 - 5.0.3
Spring Cloud Function 4.3.0 - 4.3.4
Spring Cloud Function 4.2.0 - 4.2.7
๐@cveNotify
Potential arbitrary file read and SSRF vulnerability in Spring Cloud Function.
Spring Cloud Function 5.0.0 - 5.0.3
Spring Cloud Function 4.3.0 - 4.3.4
Spring Cloud Function 4.2.0 - 4.2.7
๐@cveNotify
Potential arbitrary file read and SSRF vulnerability in Spring Cloud Function
Level up your Java code and explore what Spring can do for you.
๐จ CVE-2026-59292
PropertiesPersistingMetadataStore, the default file-based ConcurrentMetadataStore, persists its state to ${java.io.tmpdir}/spring-integration/metadata-store.properties with world-readable permissions.
Spring Integration 7.1.0
Spring Integration 7.0.0 - 7.0.5
Spring Integration 6.5.0 - 6.5.10
Spring Integration 6.4.0 - 6.4.12
Spring Integration 5.5.21 and earlier
๐@cveNotify
PropertiesPersistingMetadataStore, the default file-based ConcurrentMetadataStore, persists its state to ${java.io.tmpdir}/spring-integration/metadata-store.properties with world-readable permissions.
Spring Integration 7.1.0
Spring Integration 7.0.0 - 7.0.5
Spring Integration 6.5.0 - 6.5.10
Spring Integration 6.4.0 - 6.4.12
Spring Integration 5.5.21 and earlier
๐@cveNotify
World-readable metadata file in PropertiesPersistingMetadataStore (insecure temp-file permissions)
Level up your Java code and explore what Spring can do for you.
๐จ CVE-2026-59293
Unless the application explicitly raises smbMinVersion, the jCIFS client will negotiate down to SMB1/CIFS, which lacks mandatory signing/encryption and is vulnerable to NTLM relay and content-tampering MITM.
Spring Integration 7.1.0
Spring Integration 7.0.0 - 7.0.5
Spring Integration 6.5.0 - 6.5.10
Spring Integration 6.4.0 - 6.4.12
๐@cveNotify
Unless the application explicitly raises smbMinVersion, the jCIFS client will negotiate down to SMB1/CIFS, which lacks mandatory signing/encryption and is vulnerable to NTLM relay and content-tampering MITM.
Spring Integration 7.1.0
Spring Integration 7.0.0 - 7.0.5
Spring Integration 6.5.0 - 6.5.10
Spring Integration 6.4.0 - 6.4.12
๐@cveNotify
SMB minimum protocol dialect defaults to SMB1
Level up your Java code and explore what Spring can do for you.
๐จ CVE-2026-82971
A vulnerability was determined in QVidium Opera11 3.3.2a26-Ax4x-opera11. This affects an unknown part of the file /cgi-bin/net_tr.cgi of the component CGI Script. This manipulation of the argument ipaddr causes command injection. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. The vendor explains: "QVidium has now closed its doors and no longer will be able to sell products or provide support." This vulnerability only affects products that are no longer supported by the maintainer.
๐@cveNotify
A vulnerability was determined in QVidium Opera11 3.3.2a26-Ax4x-opera11. This affects an unknown part of the file /cgi-bin/net_tr.cgi of the component CGI Script. This manipulation of the argument ipaddr causes command injection. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. The vendor explains: "QVidium has now closed its doors and no longer will be able to sell products or provide support." This vulnerability only affects products that are no longer supported by the maintainer.
๐@cveNotify
uvxbywu62qm.feishu.cn
Docs
๐จ CVE-2026-83524
A security vulnerability has been detected in RedPort Optimizer wXa-203, Optimizer wXa-213 and Optimizer wXa-223 up to 20260704. This impacts the function exec of the file /xgatev1/system/datetime.php of the component System Clock. The manipulation leads to command injection. The attack may be initiated remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
A security vulnerability has been detected in RedPort Optimizer wXa-203, Optimizer wXa-213 and Optimizer wXa-223 up to 20260704. This impacts the function exec of the file /xgatev1/system/datetime.php of the component System Clock. The manipulation leads to command injection. The attack may be initiated remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
uvxbywu62qm.feishu.cn
Docs
๐จ CVE-2026-13479
The LoRaWAN application-layer clock-synchronization service parses downlinks in clock_sync_package_callback() (subsys/lorawan/services/clock_sync.c). Its command loop only guarantees that the one-byte command id is in bounds; for the CLOCK_SYNC_CMD_APP_TIME (AppTimeAns) command the handler then reads a 4-byte time correction via sys_get_le32() plus a 1-byte token without checking that 5 bytes remain in the receive buffer (len - rx_pos). A short or crafted AppTimeAns therefore reads up to 5 bytes past the end of the decrypted payload.
The payload (rx_buf/len) is the decrypted application frame delivered to the registered downlink callback (mcps_indication->Buffer/BufferSize). Reaching the handler requires a frame on the clock-sync port that passes LoRaWAN's MAC integrity check and FRMPayload decryption, so the practical attacker is a malicious or compromised network/application server (the designated sender of AppTimeAns) or a party holding the session keys, rather than an arbitrary radio listener.
The over-read is bounded: the backing store is a fixed 255-byte static buffer, so the few stray bytes do not fault, and the read values (time_correction, token) are used only internally and never transmitted, so there is no disclosure to the attacker and no crash. The sole effect is that a stale token matching ctx.req_token can apply a garbage time_correction to the device's own clock offset (ctx.time_offset), a minor integrity impact confined to the victim's time estimate. The fix adds an explicit length check that drops a too-short AppTimeAns. Note the sibling one-byte reads in the periodicity and force-resync handlers remain unguarded with the same negligible impact.
๐@cveNotify
The LoRaWAN application-layer clock-synchronization service parses downlinks in clock_sync_package_callback() (subsys/lorawan/services/clock_sync.c). Its command loop only guarantees that the one-byte command id is in bounds; for the CLOCK_SYNC_CMD_APP_TIME (AppTimeAns) command the handler then reads a 4-byte time correction via sys_get_le32() plus a 1-byte token without checking that 5 bytes remain in the receive buffer (len - rx_pos). A short or crafted AppTimeAns therefore reads up to 5 bytes past the end of the decrypted payload.
The payload (rx_buf/len) is the decrypted application frame delivered to the registered downlink callback (mcps_indication->Buffer/BufferSize). Reaching the handler requires a frame on the clock-sync port that passes LoRaWAN's MAC integrity check and FRMPayload decryption, so the practical attacker is a malicious or compromised network/application server (the designated sender of AppTimeAns) or a party holding the session keys, rather than an arbitrary radio listener.
The over-read is bounded: the backing store is a fixed 255-byte static buffer, so the few stray bytes do not fault, and the read values (time_correction, token) are used only internally and never transmitted, so there is no disclosure to the attacker and no crash. The sole effect is that a stale token matching ctx.req_token can apply a garbage time_correction to the device's own clock offset (ctx.time_offset), a minor integrity impact confined to the victim's time estimate. The fix adds an explicit length check that drops a too-short AppTimeAns. Note the sibling one-byte reads in the periodicity and force-resync handlers remain unguarded with the same negligible impact.
๐@cveNotify
GitHub
lorawan: clock_sync: validate AppTimeAns payload length ยท zephyrproject-rtos/zephyr@3d57806
The APP_TIME handler read 5 bytes (4-byte time correction + 1-byte token)
without checking that at least 5 bytes remained in the receive buffer,
allowing a short or crafted downlink to read past th...
without checking that at least 5 bytes remained in the receive buffer,
allowing a short or crafted downlink to read past th...
๐จ CVE-2026-59294
ResourceCacheService.getCacheName() builds the on-disk filename by appending the URI fragment verbatim, without stripping path separators or .. sequences, and passes the result to new File(resourceParentFolder, newFileName) before writing the downloaded bytes there.
Spring AI 2.0.0
Spring AI 1.1.0 - 1.1.8
Spring AI 1.0.9 and earlier
๐@cveNotify
ResourceCacheService.getCacheName() builds the on-disk filename by appending the URI fragment verbatim, without stripping path separators or .. sequences, and passes the result to new File(resourceParentFolder, newFileName) before writing the downloaded bytes there.
Spring AI 2.0.0
Spring AI 1.1.0 - 1.1.8
Spring AI 1.0.9 and earlier
๐@cveNotify
Arbitrary File Write via Path Traversal in ResourceCacheService
Level up your Java code and explore what Spring can do for you.
๐จ CVE-2026-59315
The Spring Cloud Config Monitor is susceptible to Denial of Service attacks via malicious payloads.
Spring Cloud Config 5.0.0 - 5.0.4
Spring Cloud Config 4.3.0 - 4.3.4
Spring Cloud Config 4.0.0 - 4.2.8
Spring Cloud Config 3.1.14 and earlier
๐@cveNotify
The Spring Cloud Config Monitor is susceptible to Denial of Service attacks via malicious payloads.
Spring Cloud Config 5.0.0 - 5.0.4
Spring Cloud Config 4.3.0 - 4.3.4
Spring Cloud Config 4.0.0 - 4.2.8
Spring Cloud Config 3.1.14 and earlier
๐@cveNotify
Spring Cloud Config Monitor Denial of Service
Level up your Java code and explore what Spring can do for you.
๐จ CVE-2026-59316
Spring Authorization Server's default consent page renders user-controlled values without HTML entity encoding. When using the DefaultConsentPage, an attacker can craft an OAuth2 authorization request containing a malicious value that is stored server-side and later rendered unencoded in the default consent page presented to the end user.
Spring Authorization Server 1.5.0 - 1.5.8
Spring Authorization Server 1.4.0 - 1.4.11
๐@cveNotify
Spring Authorization Server's default consent page renders user-controlled values without HTML entity encoding. When using the DefaultConsentPage, an attacker can craft an OAuth2 authorization request containing a malicious value that is stored server-side and later rendered unencoded in the default consent page presented to the end user.
Spring Authorization Server 1.5.0 - 1.5.8
Spring Authorization Server 1.4.0 - 1.4.11
๐@cveNotify
Spring Authorization Server Default Consent Page is vulnerable to Cross-Site Scripting (XSS)
Level up your Java code and explore what Spring can do for you.
๐จ CVE-2026-10659
The Dhara flash translation layer disk driver (drivers/disk/ftl_dhara.c) implemented the dhara_nand_ callbacks so that, on a flash error, the error code was written unconditionally through the caller-supplied dhara_error_t err pointer (e.g. *err = DHARA_E_ECC in dhara_nand_read, and similar in dhara_nand_erase/prog/copy).
The upstream Dhara library calls these callbacks with err == NULL along its journal-resume binary search: find_last_checkblock() invokes find_checkblock(j, mid, &found, NULL), which forwards the NULL pointer into dhara_nand_read(). This path runs during disk_ftl_access_init() -> dhara_map_resume() whenever the FTL disk is mounted/initialised.
If a flash read error (uncorrectable ECC, bad block, controller error) occurs on one of the probed checkpoint pages, the driver dereferences and writes to NULL, faulting the kernel (denial of service). The trigger is conditioned on the NAND medium content/health, which can be influenced by media wear, induced faults, or a corrupted/crafted on-flash image.
The fix routes all error assignments through the library's NULL-safe dhara_set_error() helper. Affects Zephyr v4.4.0, where the driver was introduced.
๐@cveNotify
The Dhara flash translation layer disk driver (drivers/disk/ftl_dhara.c) implemented the dhara_nand_ callbacks so that, on a flash error, the error code was written unconditionally through the caller-supplied dhara_error_t err pointer (e.g. *err = DHARA_E_ECC in dhara_nand_read, and similar in dhara_nand_erase/prog/copy).
The upstream Dhara library calls these callbacks with err == NULL along its journal-resume binary search: find_last_checkblock() invokes find_checkblock(j, mid, &found, NULL), which forwards the NULL pointer into dhara_nand_read(). This path runs during disk_ftl_access_init() -> dhara_map_resume() whenever the FTL disk is mounted/initialised.
If a flash read error (uncorrectable ECC, bad block, controller error) occurs on one of the probed checkpoint pages, the driver dereferences and writes to NULL, faulting the kernel (denial of service). The trigger is conditioned on the NAND medium content/health, which can be influenced by media wear, induced faults, or a corrupted/crafted on-flash image.
The fix routes all error assignments through the library's NULL-safe dhara_set_error() helper. Affects Zephyr v4.4.0, where the driver was introduced.
๐@cveNotify
GitHub
drivers: disk: ftl: fix null pointer dereference ยท zephyrproject-rtos/zephyr@a8371b0
find_last_checkblock() passes a NULL error pointer to
find_checkblock(), which is forwarded to dhara_nand_read().
If a read error occurs, dhara_nand_read() attempts to write
to the NULL pointer, ca...
find_checkblock(), which is forwarded to dhara_nand_read().
If a read error occurs, dhara_nand_read() attempts to write
to the NULL pointer, ca...