CVE-2026-19735 - Predictable TCP initial sequence numbers when the RFC 6528 secret key generation fails silently in the Zephyr TCP stack
CVE ID :CVE-2026-19735
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The RFC 6528 initial-sequence-number implementation in subsys/net/ip/tcp.c derived every TCP ISN from SHA-256(unique_key || four-tuple) plus a uptime-derived offset, where unique_key is a 128-bit secret filled once by sys_csrand_get(). The return value of that call was discarded and the once guard was latched to true even when the call failed. Because sys_csrand_get() leaves the destination buffer untouched on failure (it deliberately propagates the entropy-driver error rather than filling the buffer), a single failed call left unique_key as its all-zero BSS content for the remainder of the boot, with no retry, no log message and no fallback. A failure of the cryptographic random source is required to reach the weak state — for example -ENODEV/-EIO from the entropy driver in subsys/random/random_entropy_device.c (the in-tree comment notes that the hardware RNG "might still be gathering entropy during early boot situations"), or psa_generate_random() failing in subsys/random/random_psa.c when PSA crypto is not initialised or is backed by a Bluetooth-HCI entropy device that is not yet up. The first TCP connection is what triggers key generation, so a remote peer that reaches a listening port immediately after boot, or that can provoke a reboot, has indirect influence over whether generation coincides with that window. tcp_init_isn() is called for every passive open in tcp_conn_new() and every active open in net_tcp_connect(), so the poisoned key governs all TCP connections for that boot. With an all-zero key the ISN becomes a public function of the connection four-tuple plus a device-wide time offset. An off-path attacker can compute the hash term offline for any four-tuple and recover the shared time offset from a single observed ISN, after which the ISN the device will pick for other four-tuples is predictable. That defeats exactly the protection RFC 6528 provides: blind TCP connection spoofing against peers that trust the source address, and blind data injection into or reset of connections whose four-tuple can be guessed. Devices whose entropy source never errors were never in the weak state. The fix moves key generation into a single guarded helper that latches only on success, logs the error otherwise, and makes tcp_init_isn() fall back to sys_rand32_get() — the behaviour already used when CONFIG_NET_TCP_ISN_RFC6528 is disabled — instead of hashing with a known-constant key.
Severity: 4.8 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-19735
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The RFC 6528 initial-sequence-number implementation in subsys/net/ip/tcp.c derived every TCP ISN from SHA-256(unique_key || four-tuple) plus a uptime-derived offset, where unique_key is a 128-bit secret filled once by sys_csrand_get(). The return value of that call was discarded and the once guard was latched to true even when the call failed. Because sys_csrand_get() leaves the destination buffer untouched on failure (it deliberately propagates the entropy-driver error rather than filling the buffer), a single failed call left unique_key as its all-zero BSS content for the remainder of the boot, with no retry, no log message and no fallback. A failure of the cryptographic random source is required to reach the weak state — for example -ENODEV/-EIO from the entropy driver in subsys/random/random_entropy_device.c (the in-tree comment notes that the hardware RNG "might still be gathering entropy during early boot situations"), or psa_generate_random() failing in subsys/random/random_psa.c when PSA crypto is not initialised or is backed by a Bluetooth-HCI entropy device that is not yet up. The first TCP connection is what triggers key generation, so a remote peer that reaches a listening port immediately after boot, or that can provoke a reboot, has indirect influence over whether generation coincides with that window. tcp_init_isn() is called for every passive open in tcp_conn_new() and every active open in net_tcp_connect(), so the poisoned key governs all TCP connections for that boot. With an all-zero key the ISN becomes a public function of the connection four-tuple plus a device-wide time offset. An off-path attacker can compute the hash term offline for any four-tuple and recover the shared time offset from a single observed ISN, after which the ISN the device will pick for other four-tuples is predictable. That defeats exactly the protection RFC 6528 provides: blind TCP connection spoofing against peers that trust the source address, and blind data injection into or reset of connections whose four-tuple can be guessed. Devices whose entropy source never errors were never in the weak state. The fix moves key generation into a single guarded helper that latches only on success, logs the error otherwise, and makes tcp_init_isn() fall back to sys_rand32_get() — the behaviour already used when CONFIG_NET_TCP_ISN_RFC6528 is disabled — instead of hashing with a known-constant key.
Severity: 4.8 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-19736 - Out-of-bounds write in the NXP MCUX TRNG entropy driver for non-word-multiple request lengths
CVE ID :CVE-2026-19736
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The NXP MCUX TRNG entropy driver in drivers/entropy/entropy_mcux_trng.c passed the caller's byte count straight to the vendor SDK routine TRNG_GetRandomData(). On i.MX RT5xx and RT6xx parts the SDK compiles its TRNG_SW_HEALTH_TESTS variant, which always copies whole 32-bit words and draws entropy rounded up to a multiple of 128 bytes. Its "caller buffer is full" guard tests dataSize == 0, so a request whose length is not a multiple of four makes dataSize underflow past zero and the SDK keeps writing into the caller's buffer for the entire extraction: a 1-byte request results in 128 bytes written, and any non-word-multiple length overflows by up to 127 bytes. entropy_get_entropy() is a syscall, and its verifier in drivers/entropy/entropy_handlers.c validates only the requested length via K_SYSCALL_MEMORY_WRITE(). With CONFIG_USERSPACE enabled, an unprivileged user-mode thread that has merely been granted the entropy device can therefore choose both the destination address and a length such as 1, and cause the kernel to write up to 127 bytes beyond the region it proved it owns. On these Cortex-M33 targets there is no MMU, so user partitions and kernel data share one SRAM and the overflow can land in adjacent kernel state. The same defect is reached from kernel mode by any caller requesting a non-word-multiple length, including getentropy() and, in builds where sys_csrand_get()/sys_rand_get() resolve to the hardware generator, sys_rand8_get() and sys_rand16_get(). Impact is memory corruption of up to 127 bytes immediately following the supplied buffer — typically the caller's stack in kernel-mode use, or memory outside the caller's partition when driven through the syscall. The overflow offset is fully determined by the requested length and is therefore deterministic, while the written content is uncontrolled TRNG output; the practical consequences range from crashes and unpredictable state corruption to opportunistic escalation when kernel bookkeeping such as object permission bitmaps is overwritten. The affected devices are those where the MCUX SDK enables TRNG_SW_HEALTH_TESTS (MIMXRT595S, MIMXRT555S, MIMXRT533S, MIMXRT685S, MIMXRT633S), on which the TRNG is the zephyr,entropy chosen node; other SoCs using this driver take the SDK path that clamps the copy size and are unaffected. The fix routes any unaligned prefix and any sub-word tail through a local bounce word and hands the SDK only word-multiple sizes, so the SDK's word-granular writes can no longer pass the end of the caller's buffer.
Severity: 7.8 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-19736
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The NXP MCUX TRNG entropy driver in drivers/entropy/entropy_mcux_trng.c passed the caller's byte count straight to the vendor SDK routine TRNG_GetRandomData(). On i.MX RT5xx and RT6xx parts the SDK compiles its TRNG_SW_HEALTH_TESTS variant, which always copies whole 32-bit words and draws entropy rounded up to a multiple of 128 bytes. Its "caller buffer is full" guard tests dataSize == 0, so a request whose length is not a multiple of four makes dataSize underflow past zero and the SDK keeps writing into the caller's buffer for the entire extraction: a 1-byte request results in 128 bytes written, and any non-word-multiple length overflows by up to 127 bytes. entropy_get_entropy() is a syscall, and its verifier in drivers/entropy/entropy_handlers.c validates only the requested length via K_SYSCALL_MEMORY_WRITE(). With CONFIG_USERSPACE enabled, an unprivileged user-mode thread that has merely been granted the entropy device can therefore choose both the destination address and a length such as 1, and cause the kernel to write up to 127 bytes beyond the region it proved it owns. On these Cortex-M33 targets there is no MMU, so user partitions and kernel data share one SRAM and the overflow can land in adjacent kernel state. The same defect is reached from kernel mode by any caller requesting a non-word-multiple length, including getentropy() and, in builds where sys_csrand_get()/sys_rand_get() resolve to the hardware generator, sys_rand8_get() and sys_rand16_get(). Impact is memory corruption of up to 127 bytes immediately following the supplied buffer — typically the caller's stack in kernel-mode use, or memory outside the caller's partition when driven through the syscall. The overflow offset is fully determined by the requested length and is therefore deterministic, while the written content is uncontrolled TRNG output; the practical consequences range from crashes and unpredictable state corruption to opportunistic escalation when kernel bookkeeping such as object permission bitmaps is overwritten. The affected devices are those where the MCUX SDK enables TRNG_SW_HEALTH_TESTS (MIMXRT595S, MIMXRT555S, MIMXRT533S, MIMXRT685S, MIMXRT633S), on which the TRNG is the zephyr,entropy chosen node; other SoCs using this driver take the SDK path that clamps the copy size and are unaffected. The fix routes any unaligned prefix and any sub-word tail through a local bounce word and hands the SDK only word-multiple sizes, so the SDK's word-granular writes can no longer pass the end of the caller's buffer.
Severity: 7.8 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-19737 - NULL pointer dereference in the ESP32 I2S driver when triggering an unsupported direction
CVE ID :CVE-2026-19737
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :i2s_esp32_trigger_check() in drivers/i2s/i2s_esp32.c validates the requested direction only for I2S_DIR_BOTH. The I2S_DIR_RX and I2S_DIR_TX branches read dev_cfg->rx.data->configured / dev_cfg->tx.data->configured without first checking the stream pointers. The device instantiation macro I2S_ESP32_STREAM_INIT() sets both .conf and .data to NULL for a direction the devicetree does not describe, so on an instance that wires only one direction — the normal shape for audio output or a worldsemi,ws2812-i2s LED strip — the other direction dereferences a NULL pointer instead of returning an error. i2s_trigger() is a Zephyr syscall, and z_vrfy_i2s_trigger() in drivers/i2s/i2s_handlers.c validates only the device object and the presence of the trigger API pointer; the dir argument is passed to the driver unvalidated. On a build with CONFIG_USERSPACE enabled, a user-mode thread that has been granted the I2S device can issue a single i2s_trigger() call naming the unwired direction and cause a load from address 0 in kernel mode. Among the Espressif parts that carry this driver, userspace is available in-tree only on RISC-V SoCs with CONFIG_RISCV_PMP, and v4.4.0 is the first release where that is buildable: the ESP32-C6 HPCORE selects RISCV_PMP when it is not built for MCUboot. ESP32-C5 in v4.4.x carries the same PMP-region and userspace linker support but does not select RISCV_PMP by default. Espressif Xtensa targets do not support Zephyr userspace, and in a non-userspace build the bad direction can only come from in-kernel application code. The impact is limited to availability: the access is a read at offset 0 of the missing stream structure, so there is no attacker-controlled offset, no write primitive and no information disclosure. With the default fatal-error handler the resulting exception halts the system, giving an unprivileged user-mode thread a system-wide denial of service. The fix adds the same pointer check the I2S_DIR_BOTH branch already performed and returns -ENOSYS for a direction the instance does not implement; the driver's other entry points (i2s_esp32_config_check(), i2s_esp32_config_get(), i2s_esp32_read(), i2s_esp32_write()) already guarded the pointers, and a static audit found no equivalent unguarded path. The driver defect is older than the affected range. The unguarded dereference is present from v4.2.0 (reached through i2s_esp32_trigger_stream(), whose if (stream) guard tests the address of a struct member and is never false) and takes its present i2s_esp32_trigger_check() form in v4.3.0. No in-tree Espressif configuration before v4.4.0 can run a user-mode thread, so in v4.2.x and v4.3.x the direction argument can only come from trusted kernel code. Those releases carry the bug but are not listed as affected; the fix has also been merged to v4.3-branch as hardening.
Severity: 5.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-19737
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :i2s_esp32_trigger_check() in drivers/i2s/i2s_esp32.c validates the requested direction only for I2S_DIR_BOTH. The I2S_DIR_RX and I2S_DIR_TX branches read dev_cfg->rx.data->configured / dev_cfg->tx.data->configured without first checking the stream pointers. The device instantiation macro I2S_ESP32_STREAM_INIT() sets both .conf and .data to NULL for a direction the devicetree does not describe, so on an instance that wires only one direction — the normal shape for audio output or a worldsemi,ws2812-i2s LED strip — the other direction dereferences a NULL pointer instead of returning an error. i2s_trigger() is a Zephyr syscall, and z_vrfy_i2s_trigger() in drivers/i2s/i2s_handlers.c validates only the device object and the presence of the trigger API pointer; the dir argument is passed to the driver unvalidated. On a build with CONFIG_USERSPACE enabled, a user-mode thread that has been granted the I2S device can issue a single i2s_trigger() call naming the unwired direction and cause a load from address 0 in kernel mode. Among the Espressif parts that carry this driver, userspace is available in-tree only on RISC-V SoCs with CONFIG_RISCV_PMP, and v4.4.0 is the first release where that is buildable: the ESP32-C6 HPCORE selects RISCV_PMP when it is not built for MCUboot. ESP32-C5 in v4.4.x carries the same PMP-region and userspace linker support but does not select RISCV_PMP by default. Espressif Xtensa targets do not support Zephyr userspace, and in a non-userspace build the bad direction can only come from in-kernel application code. The impact is limited to availability: the access is a read at offset 0 of the missing stream structure, so there is no attacker-controlled offset, no write primitive and no information disclosure. With the default fatal-error handler the resulting exception halts the system, giving an unprivileged user-mode thread a system-wide denial of service. The fix adds the same pointer check the I2S_DIR_BOTH branch already performed and returns -ENOSYS for a direction the instance does not implement; the driver's other entry points (i2s_esp32_config_check(), i2s_esp32_config_get(), i2s_esp32_read(), i2s_esp32_write()) already guarded the pointers, and a static audit found no equivalent unguarded path. The driver defect is older than the affected range. The unguarded dereference is present from v4.2.0 (reached through i2s_esp32_trigger_stream(), whose if (stream) guard tests the address of a struct member and is never false) and takes its present i2s_esp32_trigger_check() form in v4.3.0. No in-tree Espressif configuration before v4.4.0 can run a user-mode thread, so in v4.2.x and v4.3.x the direction argument can only come from trusted kernel code. Those releases carry the bug but are not listed as affected; the fix has also been merged to v4.3-branch as hardening.
Severity: 5.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-19738 - Retained RX node leak and reachable assertion in Bluetooth Controller CIS Create procedures
CVE ID :CVE-2026-19738
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The Bluetooth Link Layer Control Procedure (LLCP) implementation for Connected Isochronous Stream (CIS) creation retains an RX node (ctx->node_ref.rx, marked NODE_RX_TYPE_RETAIN) so it can later be reused as the host notification — on the peripheral while awaiting the Host's reply to an LL_CIS_REQ, and on the central for the whole duration of a locally initiated CIS Create. In subsys/bluetooth/controller/ll_sw/ull_llcp_cc.c, the "invalid PDU received" paths of llcp_rp_cc_rx() and llcp_lp_cc_rx() terminated the connection and completed the procedure without releasing that retained node, breaking the invariant checked in llcp_lr_check_done() and llcp_rr_check_done() and orphaning the node's memory. A peer device within radio range can reach this with a single extra LL Control PDU on an unauthenticated, unencrypted ACL link. Against a peripheral, the attacker sends a valid LL_CIS_REQ and then, before the Host replies, any unrelated LL Control PDU (for example LL_VERSION_IND), which ull_cp_rx() routes into the active remote procedure. Against a central performing a CIS Create, a malicious peripheral answers with LL_UNKNOWN_RSP for CIS_REQ, which is dispatched into the active local procedure. No pairing, encryption or user interaction is required; the code is compiled in when CONFIG_BT_CTLR_PERIPHERAL_ISO or CONFIG_BT_CTLR_CENTRAL_ISO is enabled. In default builds (CONFIG_BT_CTLR_ASSERT_DEBUG is default y) the retained-node assertion fires immediately, producing a controller fatal error and, typically, a system reset from one injected PDU. With the development assertions disabled, each attempt permanently loses one node from the controller's small LL notification pool (LL_PDU_RX_CNT, 2 * CONFIG_BT_CTLR_LLCP_CONN) together with its memq_link_t; repeating the connect-attack-reconnect cycle exhausts the pool, after which notification allocation always fails, RX flow control stalls, and the non-disableable LL_ASSERT_ERR() in llcp_lp_cc_flush() faults. The impact is limited to availability — the leaked node is orphaned, never reused or double-freed — and recovery requires a reboot.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-19738
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The Bluetooth Link Layer Control Procedure (LLCP) implementation for Connected Isochronous Stream (CIS) creation retains an RX node (ctx->node_ref.rx, marked NODE_RX_TYPE_RETAIN) so it can later be reused as the host notification — on the peripheral while awaiting the Host's reply to an LL_CIS_REQ, and on the central for the whole duration of a locally initiated CIS Create. In subsys/bluetooth/controller/ll_sw/ull_llcp_cc.c, the "invalid PDU received" paths of llcp_rp_cc_rx() and llcp_lp_cc_rx() terminated the connection and completed the procedure without releasing that retained node, breaking the invariant checked in llcp_lr_check_done() and llcp_rr_check_done() and orphaning the node's memory. A peer device within radio range can reach this with a single extra LL Control PDU on an unauthenticated, unencrypted ACL link. Against a peripheral, the attacker sends a valid LL_CIS_REQ and then, before the Host replies, any unrelated LL Control PDU (for example LL_VERSION_IND), which ull_cp_rx() routes into the active remote procedure. Against a central performing a CIS Create, a malicious peripheral answers with LL_UNKNOWN_RSP for CIS_REQ, which is dispatched into the active local procedure. No pairing, encryption or user interaction is required; the code is compiled in when CONFIG_BT_CTLR_PERIPHERAL_ISO or CONFIG_BT_CTLR_CENTRAL_ISO is enabled. In default builds (CONFIG_BT_CTLR_ASSERT_DEBUG is default y) the retained-node assertion fires immediately, producing a controller fatal error and, typically, a system reset from one injected PDU. With the development assertions disabled, each attempt permanently loses one node from the controller's small LL notification pool (LL_PDU_RX_CNT, 2 * CONFIG_BT_CTLR_LLCP_CONN) together with its memq_link_t; repeating the connect-attack-reconnect cycle exhausts the pool, after which notification allocation always fails, RX flow control stalls, and the non-disableable LL_ASSERT_ERR() in llcp_lp_cc_flush() faults. The impact is limited to availability — the leaked node is orphaned, never reused or double-freed — and recovery requires a reboot.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-19739 - Bluetooth LE controller leaks a retained RX node when an unexpected LL Control PDU arrives during a Connection Update
CVE ID :CVE-2026-19739
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The Bluetooth Link Layer control procedure code in subsys/bluetooth/controller/ll_sw/ull_llcp_conn_upd.c retains the received RX node while a Connection Update / Connection Parameter procedure waits for its instant, so the node can later carry the host notification (llcp_rx_node_retain(), which marks it NODE_RX_TYPE_RETAIN and thereby suppresses the normal recycling in ull.c). The default: arm of llcp_rp_cu_rx() and llcp_lp_cu_rx() — the "invalid PDU, terminate the connection" path — completed the procedure without releasing that retained node. llcp_rr_check_done() then dequeued and freed the procedure context with ctx->node_ref.rx still pointing at the retained node, dropping the last reference to it. A peer device in radio range can reach this without pairing, bonding, or encryption. Against a peripheral, the peer sends a well-formed LL_CONNECTION_UPDATE_IND with an instant a few connection events in the future (the node is retained and the procedure enters RP_CU_STATE_WAIT_INSTANT), then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ. ull_cp_rx() routes that PDU into the active remote Connection Update procedure, which takes the invalid-PDU path. The central role is reachable symmetrically after accepting an LL_CONNECTION_PARAM_REQ, and the local-procedure variant is reachable with LL_REJECT_IND. With CONFIG_BT_CTLR_ASSERT_DEBUG enabled (its default), the resulting state violates the invariant asserted in llcp_rr_check_done(), so the two-PDU sequence produces an immediate fatal error in the controller. With those asserts disabled, each occurrence permanently loses one node from the controller's small fixed RX pool (sized from CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1); repeating the sequence across reconnections exhausts the pool, after which the link-layer receive path operates on a NULL node. The impact is an unauthenticated, remotely triggerable denial of service persisting until reboot; there is no memory-disclosure or memory-corruption consequence, since the leaked node simply becomes unreachable.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-19739
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The Bluetooth Link Layer control procedure code in subsys/bluetooth/controller/ll_sw/ull_llcp_conn_upd.c retains the received RX node while a Connection Update / Connection Parameter procedure waits for its instant, so the node can later carry the host notification (llcp_rx_node_retain(), which marks it NODE_RX_TYPE_RETAIN and thereby suppresses the normal recycling in ull.c). The default: arm of llcp_rp_cu_rx() and llcp_lp_cu_rx() — the "invalid PDU, terminate the connection" path — completed the procedure without releasing that retained node. llcp_rr_check_done() then dequeued and freed the procedure context with ctx->node_ref.rx still pointing at the retained node, dropping the last reference to it. A peer device in radio range can reach this without pairing, bonding, or encryption. Against a peripheral, the peer sends a well-formed LL_CONNECTION_UPDATE_IND with an instant a few connection events in the future (the node is retained and the procedure enters RP_CU_STATE_WAIT_INSTANT), then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ. ull_cp_rx() routes that PDU into the active remote Connection Update procedure, which takes the invalid-PDU path. The central role is reachable symmetrically after accepting an LL_CONNECTION_PARAM_REQ, and the local-procedure variant is reachable with LL_REJECT_IND. With CONFIG_BT_CTLR_ASSERT_DEBUG enabled (its default), the resulting state violates the invariant asserted in llcp_rr_check_done(), so the two-PDU sequence produces an immediate fatal error in the controller. With those asserts disabled, each occurrence permanently loses one node from the controller's small fixed RX pool (sized from CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1); repeating the sequence across reconnections exhausts the pool, after which the link-layer receive path operates on a NULL node. The impact is an unauthenticated, remotely triggerable denial of service persisting until reboot; there is no memory-disclosure or memory-corruption consequence, since the leaked node simply becomes unreachable.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-19740 - Bluetooth LE Controller: retained RX node leak and reachable assertion in the PHY Update procedure
CVE ID :CVE-2026-19740
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The Link Layer Control Procedure (LLCP) implementation of the Zephyr software Bluetooth LE Controller retains the receive node that carried an accepted LL_PHY_UPDATE_IND so that it can later be reused for the host notification when the update instant is reached (llcp_rx_node_retain() in subsys/bluetooth/controller/ll_sw/ull_llcp.c, and the node is deliberately not recycled while marked NODE_RX_TYPE_RETAIN). The invalid-PDU arms of llcp_lp_pu_rx() and llcp_rp_pu_rx() in subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c completed the procedure via llcp_lr_complete() / llcp_rr_complete() without first releasing that retained node, so the procedure context — the only remaining reference to the node — was freed while the node was still held out of the receive pool. A peer device on an established LE connection can drive this deterministically and without pairing or encryption. Against a peripheral it sends LL_PHY_REQ, receives LL_PHY_RSP, sends a valid LL_PHY_UPDATE_IND with an instant a few connection events in the future (so the node becomes retained), and then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ; ull_cp_rx() routes it to the active remote PHY Update procedure, which takes the invalid-PDU path. The mirror case applies to a locally initiated PHY Update followed by an LL_REJECT_IND. In the default configuration (CONFIG_BT_ASSERT and CONFIG_BT_CTLR_ASSERT_DEBUG both default y) the violated invariant in llcp_lr_check_done() / llcp_rr_check_done() triggers a controller assertion, ending in k_oops() (or k_panic()) — a single crafted PDU sequence from radio range faults the device. With those assertions compiled out, each attempt silently leaks one receive PDU node and its memq link; because the controller receive pool is small (PDU_RX_CNT, driven by CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1) and each attempt costs the attacker only a reconnect, a few repetitions exhaust the pool and leave Bluetooth inoperable until reboot. On releases v3.4.0 through v3.7.x the assertion is never reached, whatever the configuration, so every attempt leaks silently. The impact is limited to availability: the orphaned node leaves no dangling pointer that is later dereferenced and is never delivered to the host, so there is no memory corruption or information disclosure. The same pull request applies the identical release to the Connection Update and CIS-create procedures, whose invalid-PDU arms had the same omission.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-19740
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The Link Layer Control Procedure (LLCP) implementation of the Zephyr software Bluetooth LE Controller retains the receive node that carried an accepted LL_PHY_UPDATE_IND so that it can later be reused for the host notification when the update instant is reached (llcp_rx_node_retain() in subsys/bluetooth/controller/ll_sw/ull_llcp.c, and the node is deliberately not recycled while marked NODE_RX_TYPE_RETAIN). The invalid-PDU arms of llcp_lp_pu_rx() and llcp_rp_pu_rx() in subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c completed the procedure via llcp_lr_complete() / llcp_rr_complete() without first releasing that retained node, so the procedure context — the only remaining reference to the node — was freed while the node was still held out of the receive pool. A peer device on an established LE connection can drive this deterministically and without pairing or encryption. Against a peripheral it sends LL_PHY_REQ, receives LL_PHY_RSP, sends a valid LL_PHY_UPDATE_IND with an instant a few connection events in the future (so the node becomes retained), and then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ; ull_cp_rx() routes it to the active remote PHY Update procedure, which takes the invalid-PDU path. The mirror case applies to a locally initiated PHY Update followed by an LL_REJECT_IND. In the default configuration (CONFIG_BT_ASSERT and CONFIG_BT_CTLR_ASSERT_DEBUG both default y) the violated invariant in llcp_lr_check_done() / llcp_rr_check_done() triggers a controller assertion, ending in k_oops() (or k_panic()) — a single crafted PDU sequence from radio range faults the device. With those assertions compiled out, each attempt silently leaks one receive PDU node and its memq link; because the controller receive pool is small (PDU_RX_CNT, driven by CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1) and each attempt costs the attacker only a reconnect, a few repetitions exhaust the pool and leave Bluetooth inoperable until reboot. On releases v3.4.0 through v3.7.x the assertion is never reached, whatever the configuration, so every attempt leaks silently. The impact is limited to availability: the orphaned node leaves no dangling pointer that is later dereferenced and is never delivered to the host, so there is no memory corruption or information disclosure. The same pull request applies the identical release to the Connection Update and CIS-create procedures, whose invalid-PDU arms had the same omission.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-19935 - Use-after-free of an L2CAP CoC channel object in the Zephyr Bluetooth host: RX work item is not cancelled on channel teardown
CVE ID :CVE-2026-19935
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The Bluetooth LE host queues received L2CAP connection-oriented channel (CoC) data for deferred processing through a struct k_work embedded in the channel object (le_chan->rx_work, handler l2cap_rx_process()) whenever the channel uses a dynamic PSM (0x0080-0x00FF). Channel teardown in l2cap_chan_destroy() in subsys/bluetooth/host/l2cap.c cancels the retransmission-timeout work and drains the RX FIFO, but never cancels rx_work. Because that work item was submitted to the system workqueue while HCI receive processing runs on the dedicated Bluetooth RX workqueue (CONFIG_BT_RECV_WORKQ_BT, the default), a queued rx_work item can outlive the channel it points into. A remote, unauthenticated peer with an established CoC channel triggers this by sending a data K-frame immediately followed by an L2CAP Disconnect Request. The K-frame submits rx_work to the system workqueue; because both workqueue threads are cooperative and the Bluetooth RX workqueue runs at the higher priority (K_PRIO_COOP(CONFIG_BT_RX_PRIO) versus CONFIG_SYSTEM_WORKQUEUE_PRIORITY), the pending item cannot run before the following Disconnect Request is processed in le_disconn_req() -> l2cap_chan_del() -> l2cap_chan_destroy(). The stack then invokes the released() callback, which the API documents as meaning the stack has dropped all references and the application may free the channel memory. The application therefore frees or re-accepts into an object that the system workqueue still holds in its pending list. If the memory is freed and reallocated, the workqueue later dereferences a list node and a handler function pointer read from reused memory; if the object is re-used for a later connection, l2cap_chan_add() calls k_work_init() on a still-enqueued work item, corrupting the workqueue's pending list so that unrelated work items are dropped or the queue spins on a looped list. A related variant lets l2cap_rx_process() run concurrently with teardown, racing the net_buf unref of le_chan->_sdu and the clearing of chan->conn. The fix routes the channel RX work to the Bluetooth workqueue - the same context in which every teardown path runs - and adds an explicit k_work_cancel() of le_chan->rx_work in l2cap_chan_destroy(), so no reference to the channel survives the released() callback. Configurations without CONFIG_BT_L2CAP_DYNAMIC_CHANNEL, or that only use SIG-assigned PSMs (EATT 0x0027, OTS 0x0025) which take the inline receive path, are not affected.
Severity: 7.5 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-19935
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :The Bluetooth LE host queues received L2CAP connection-oriented channel (CoC) data for deferred processing through a struct k_work embedded in the channel object (le_chan->rx_work, handler l2cap_rx_process()) whenever the channel uses a dynamic PSM (0x0080-0x00FF). Channel teardown in l2cap_chan_destroy() in subsys/bluetooth/host/l2cap.c cancels the retransmission-timeout work and drains the RX FIFO, but never cancels rx_work. Because that work item was submitted to the system workqueue while HCI receive processing runs on the dedicated Bluetooth RX workqueue (CONFIG_BT_RECV_WORKQ_BT, the default), a queued rx_work item can outlive the channel it points into. A remote, unauthenticated peer with an established CoC channel triggers this by sending a data K-frame immediately followed by an L2CAP Disconnect Request. The K-frame submits rx_work to the system workqueue; because both workqueue threads are cooperative and the Bluetooth RX workqueue runs at the higher priority (K_PRIO_COOP(CONFIG_BT_RX_PRIO) versus CONFIG_SYSTEM_WORKQUEUE_PRIORITY), the pending item cannot run before the following Disconnect Request is processed in le_disconn_req() -> l2cap_chan_del() -> l2cap_chan_destroy(). The stack then invokes the released() callback, which the API documents as meaning the stack has dropped all references and the application may free the channel memory. The application therefore frees or re-accepts into an object that the system workqueue still holds in its pending list. If the memory is freed and reallocated, the workqueue later dereferences a list node and a handler function pointer read from reused memory; if the object is re-used for a later connection, l2cap_chan_add() calls k_work_init() on a still-enqueued work item, corrupting the workqueue's pending list so that unrelated work items are dropped or the queue spins on a looped list. A related variant lets l2cap_rx_process() run concurrently with teardown, racing the net_buf unref of le_chan->_sdu and the clearing of chan->conn. The fix routes the channel RX work to the Bluetooth workqueue - the same context in which every teardown path runs - and adds an explicit k_work_cancel() of le_chan->rx_work in l2cap_chan_destroy(), so no reference to the channel survives the released() callback. Configurations without CONFIG_BT_L2CAP_DYNAMIC_CHANNEL, or that only use SIG-assigned PSMs (EATT 0x0027, OTS 0x0025) which take the inline receive path, are not affected.
Severity: 7.5 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-59508 - Interuse i-Bos CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
CVE ID :CVE-2026-59508
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :Improper neutralization of special elements used in an SQL command ('SQL injection') vulnerability in Interuse i-Bos. This issue affects i-Bos: 3.0.
Severity: 5.9 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-59508
Published : Oct. 11, 2026, 6:16 p.m. | 4 hours, 19 minutes ago
Description :Improper neutralization of special elements used in an SQL command ('SQL injection') vulnerability in Interuse i-Bos. This issue affects i-Bos: 3.0.
Severity: 5.9 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108768 - zhayujie CowAgent Streaming Tool-Call Argument json.loads allocation of resources
CVE ID :CVE-2026-108768
Published : Oct. 11, 2026, 7:16 p.m. | 3 hours, 19 minutes ago
Description :A vulnerability was identified in zhayujie CowAgent up to 2.2.0. Affected by this issue is the function json.loads of the component Streaming Tool-Call Argument Handler. The manipulation leads to allocation of resources. It is possible to initiate the attack remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.
Severity: 4.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108768
Published : Oct. 11, 2026, 7:16 p.m. | 3 hours, 19 minutes ago
Description :A vulnerability was identified in zhayujie CowAgent up to 2.2.0. Affected by this issue is the function json.loads of the component Streaming Tool-Call Argument Handler. The manipulation leads to allocation of resources. It is possible to initiate the attack remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.
Severity: 4.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108925 - Cohesity - CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
CVE ID :CVE-2026-108925
Published : Oct. 11, 2026, 7:16 p.m. | 3 hours, 19 minutes ago
Description :Improper neutralization of Script-Related HTML tags in a web page (basic XSS) vulnerability in Cohesity NetBackup Administration Console web interface. This issue affects NetBackup Administration Console web interface: versions before 11.2. https://github.com/cohesity/SecAdvisory/blob/master/COH-2026-0002.md
Severity: 6.1 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108925
Published : Oct. 11, 2026, 7:16 p.m. | 3 hours, 19 minutes ago
Description :Improper neutralization of Script-Related HTML tags in a web page (basic XSS) vulnerability in Cohesity NetBackup Administration Console web interface. This issue affects NetBackup Administration Console web interface: versions before 11.2. https://github.com/cohesity/SecAdvisory/blob/master/COH-2026-0002.md
Severity: 6.1 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108963 - Databasement Argument Injection Remote Code Execution
CVE ID :CVE-2026-108963
Published : Oct. 11, 2026, 8:16 p.m. | 2 hours, 19 minutes ago
Description :databasement before 1.8.2 allows remote code execution because it runs certain commands (e.g., mariadb-dump) with a database name that can be specified by any authenticated user. For example, --result-file=/app/public/index.php can write to index.php. In other words, quoting prevents OS command injection in mariadb-dump, but the argument injection alone is sufficient for code execution indirectly. NOTE: the project's composer.json file does not indicate an independently published databasement Composer package.
Severity: 8.8 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108963
Published : Oct. 11, 2026, 8:16 p.m. | 2 hours, 19 minutes ago
Description :databasement before 1.8.2 allows remote code execution because it runs certain commands (e.g., mariadb-dump) with a database name that can be specified by any authenticated user. For example, --result-file=/app/public/index.php can write to index.php. In other words, quoting prevents OS command injection in mariadb-dump, but the argument injection alone is sufficient for code execution indirectly. NOTE: the project's composer.json file does not indicate an independently published databasement Composer package.
Severity: 8.8 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108976 - GNU Emacs TRAMP OS Command Injection
CVE ID :CVE-2026-108976
Published : Oct. 11, 2026, 9:16 p.m. | 1 hour, 19 minutes ago
Description :GNU Emacs before 31.2 (and TRAMP through 2.8.2) allows OS command injection via a filename because tramp-user-regexp has an incomplete list of disallowed inputs. NOTE: this issue exists because of an incomplete fix for CVE-2026-79992.
Severity: 7.8 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108976
Published : Oct. 11, 2026, 9:16 p.m. | 1 hour, 19 minutes ago
Description :GNU Emacs before 31.2 (and TRAMP through 2.8.2) allows OS command injection via a filename because tramp-user-regexp has an incomplete list of disallowed inputs. NOTE: this issue exists because of an incomplete fix for CVE-2026-79992.
Severity: 7.8 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108770 - Appwrite Browser Screenshot Service Get.php PublicHostname server-side request forgery
CVE ID :CVE-2026-108770
Published : Oct. 11, 2026, 10:15 p.m. | 21 minutes ago
Description :A weakness has been identified in Appwrite up to 2.3.0. This vulnerability affects the function PublicHostname of the file src/Appwrite/Platform/Modules/Avatars/Http/Screenshots/Get.php of the component Browser Screenshot Service. This manipulation of the argument url causes server-side request forgery. The attack can be initiated remotely. Upgrading to version 2.4.0 is able to resolve this issue. Patch name: 393255e7302ae5503331d45802e2eee01c6a47fe. You should upgrade the affected component.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108770
Published : Oct. 11, 2026, 10:15 p.m. | 21 minutes ago
Description :A weakness has been identified in Appwrite up to 2.3.0. This vulnerability affects the function PublicHostname of the file src/Appwrite/Platform/Modules/Avatars/Http/Screenshots/Get.php of the component Browser Screenshot Service. This manipulation of the argument url causes server-side request forgery. The attack can be initiated remotely. Upgrading to version 2.4.0 is able to resolve this issue. Patch name: 393255e7302ae5503331d45802e2eee01c6a47fe. You should upgrade the affected component.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108769 - zhayujie CowAgent Markdown Rendering Markdown.tsx denial of service
CVE ID :CVE-2026-108769
Published : Oct. 11, 2026, 10:16 p.m. | 19 minutes ago
Description :A security flaw has been discovered in zhayujie CowAgent up to 2.2.0. This affects an unknown part of the file Markdown.tsx of the component Markdown Rendering. The manipulation results in denial of service. It is possible to launch the attack remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
Severity: 4.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108769
Published : Oct. 11, 2026, 10:16 p.m. | 19 minutes ago
Description :A security flaw has been discovered in zhayujie CowAgent up to 2.2.0. This affects an unknown part of the file Markdown.tsx of the component Markdown Rendering. The manipulation results in denial of service. It is possible to launch the attack remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
Severity: 4.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108978 - Samsung rlottie Heap-based Buffer Overflow
CVE ID :CVE-2026-108978
Published : Oct. 11, 2026, 10:16 p.m. | 19 minutes ago
Description :Heap-based buffer overflow vulnerability in Samsung Opensource rlottie allows Buffer Overflow via Environment Variables. This issue affects rlottie: e57b094f03c39a751a1fded6f7d6c13f1ed95ec9.
Severity: 5.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108978
Published : Oct. 11, 2026, 10:16 p.m. | 19 minutes ago
Description :Heap-based buffer overflow vulnerability in Samsung Opensource rlottie allows Buffer Overflow via Environment Variables. This issue affects rlottie: e57b094f03c39a751a1fded6f7d6c13f1ed95ec9.
Severity: 5.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-104703
Published : Oct. 11, 2026, 10:24 p.m. | 11 minutes ago
Description :None
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
Published : Oct. 11, 2026, 10:24 p.m. | 11 minutes ago
Description :None
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108772 - bleenco abstruse Cache Endpoint download_cache.go filepath.Join path traversal
CVE ID :CVE-2026-108772
Published : Oct. 11, 2026, 11:16 p.m. | 3 hours, 19 minutes ago
Description :A security vulnerability has been detected in bleenco abstruse up to 2.1.0. This issue affects the function filepath.Join of the file server/api/worker/download_cache.go of the component Cache Endpoint. Such manipulation of the argument File leads to path traversal. The attack can be launched 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.
Severity: 5.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108772
Published : Oct. 11, 2026, 11:16 p.m. | 3 hours, 19 minutes ago
Description :A security vulnerability has been detected in bleenco abstruse up to 2.1.0. This issue affects the function filepath.Join of the file server/api/worker/download_cache.go of the component Cache Endpoint. Such manipulation of the argument File leads to path traversal. The attack can be launched 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.
Severity: 5.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108773 - erzhongxmu JEEWMS WmOmNoticeHController.java docheck sql injection
CVE ID :CVE-2026-108773
Published : Oct. 11, 2026, 11:16 p.m. | 3 hours, 19 minutes ago
Description :A vulnerability was detected in erzhongxmu JEEWMS up to 2026.09.27-W39. Impacted is the function docheck of the file src/main/java/com/zzjee/wm/controller/WmOmNoticeHController.java. Performing a manipulation of the argument goodscode results in sql injection. The attack may be initiated 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.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108773
Published : Oct. 11, 2026, 11:16 p.m. | 3 hours, 19 minutes ago
Description :A vulnerability was detected in erzhongxmu JEEWMS up to 2026.09.27-W39. Impacted is the function docheck of the file src/main/java/com/zzjee/wm/controller/WmOmNoticeHController.java. Performing a manipulation of the argument goodscode results in sql injection. The attack may be initiated 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.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108774 - erzhongxmu JEEWMS MdBinController.java getbinallagv sql injection
CVE ID :CVE-2026-108774
Published : Oct. 12, 2026, 12:17 a.m. | 2 hours, 19 minutes ago
Description :A flaw has been found in erzhongxmu JEEWMS up to 2026.09.27-W39. The affected element is the function getbinall/getbinallagv of the file src/main/java/com/zzjee/md/controller/MdBinController.java. Executing a manipulation of the argument binstore/binid/des/cengshu can lead to sql injection. The attack may be launched remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108774
Published : Oct. 12, 2026, 12:17 a.m. | 2 hours, 19 minutes ago
Description :A flaw has been found in erzhongxmu JEEWMS up to 2026.09.27-W39. The affected element is the function getbinall/getbinallagv of the file src/main/java/com/zzjee/md/controller/MdBinController.java. Executing a manipulation of the argument binstore/binid/des/cengshu can lead to sql injection. The attack may be launched remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108775 - erzhongxmu JEEWMS Search Endpoint WvNoticeController.java WvNoticeController.list sql injection
CVE ID :CVE-2026-108775
Published : Oct. 12, 2026, 12:17 a.m. | 2 hours, 19 minutes ago
Description :A vulnerability has been found in erzhongxmu JEEWMS up to 2026.09.27-W39. The impacted element is the function WvNoticeController.list of the file com/zzjee/wmapi/controller/WvNoticeController.java of the component Search Endpoint. The manipulation of the argument searchstr leads to sql injection. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108775
Published : Oct. 12, 2026, 12:17 a.m. | 2 hours, 19 minutes ago
Description :A vulnerability has been found in erzhongxmu JEEWMS up to 2026.09.27-W39. The impacted element is the function WvNoticeController.list of the file com/zzjee/wmapi/controller/WvNoticeController.java of the component Search Endpoint. The manipulation of the argument searchstr leads to sql injection. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-108777 - erzhongxmu JEEWMS WvGiController.java WvGiController.list sql injection
CVE ID :CVE-2026-108777
Published : Oct. 12, 2026, 12:17 a.m. | 2 hours, 19 minutes ago
Description :A vulnerability was found in erzhongxmu JEEWMS up to 2026.09.27-W39. This affects the function WvGiController.list of the file src/main/java/com/zzjee/wmapi/controller/WvGiController.java. The manipulation of the argument searchstr results in sql injection. The attack can be executed remotely. 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.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-108777
Published : Oct. 12, 2026, 12:17 a.m. | 2 hours, 19 minutes ago
Description :A vulnerability was found in erzhongxmu JEEWMS up to 2026.09.27-W39. This affects the function WvGiController.list of the file src/main/java/com/zzjee/wmapi/controller/WvGiController.java. The manipulation of the argument searchstr results in sql injection. The attack can be executed remotely. 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.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...