HTSlib versions through 1.24 have a heap out-of-bounds read and write vulnerability in the function bgzf_index_load_hfile() located in bgzf.c. This flaw allows an attacker to corrupt heap memory by providing a specially crafted .gzi index entry count. Specifically, a count value of 0xFFFFFFFF causes truncation of an internal variable to zero, leading to writes beyond a zero-sized malloc buffer and an out-of-bounds read in bgzf_useek(). This can result in heap corruption or crashes in dependent tools such as samtools and bcftools.
CVE-2026-116608 is a medium severity vulnerability in DAMO Academy VideoLLaMA2 versions 1.0 and 1.1. It involves improper validation of an integrity check value in the load_pretrained_model function, which can be triggered by manipulating the _name_or_path argument. Remote exploitation is possible, and public exploit details have been disclosed. The vendor has not yet responded or issued a fix.
FLTK versions up to and including 1.4.5 have a stack-based buffer overflow vulnerability in the Fl_BMP_Image::load_bmp_() function. This flaw occurs when processing BMP or ICO files with a colors_used field value exceeding 256, which overflows a 768-byte colormap array. Exploitation can lead to application crashes or potentially allow code execution.
Seroval facilitates JavaScript value stringification, including complex structures beyond JSON.stringify capabilities. Prior to 1.6.8, fromJSON rebuilds an AsyncIteratorFactoryInstance by calling source.on(listener) without requiring source to be a genuine internal stream. With untrusted Seroval input and an application plugin that returns a callable value or an object exposing an on method, a crafted node can reuse an identifier so the deserializer invokes the plugin-produced value. This is an incomplete-fix variant of CVE-2026-59940. The resulting confidentiality, integrity, or availability impact depends on the behavior exposed by the application plugin. This issue is fixed in version 1.6.8.
CVE-2026-70382 is a cross-site scripting (XSS) vulnerability affecting multiple WolfVision Cynap devices. The flaw arises because some externally supplied values stored by the device are rendered in the web interface without proper output encoding. An attacker who can influence these stored values could cause script execution in the browser of a user who views the affected page. Exploitation requires both attacker control over a stored value and a user viewing the vulnerable page. The vulnerability has a medium severity rating with a CVSS score of 5.1.
CVE-2026-65625 is a vulnerability in the potatosalad jose library affecting versions from 1.2.0 up to but not including 1.11.13. The issue arises in the pure-Erlang AES-GCM fallback implementation where the authentication tag length is derived from attacker-supplied data without proper validation. This allows an attacker controlling a JWE token to truncate the authentication tag to as little as 8 bits, drastically reducing forgery resistance and enabling reliable forgery within 256 attempts. Supplying an overly long tag causes a crash. The vulnerability is fixed in version 1.11.13.
Rembg is a tool to remove images background. Prior to 2.0.82, the public /api/remove endpoint passes attacker-controlled extras.sam_model through rembg/commands/s_command.py to rembg/sessions/sam.py, where it is interpolated into SAM filenames and GitHub download URLs passed to pooch.retrieve() without a pinned hash. An unauthenticated attacker can supply a sam_model value combining path traversal with URL fragment syntax to exploit the HTTP request discarding the fragment while the local POSIX path retains it. The first request primes the attacker-selected path tree, and an identical repeated request downloads malicious ONNX encoder and decoder files beside a readable target file. The graphs can load the target through ONNX external data and encode its bytes into the returned PNG mask, disclosing complete files accessible to the rembg process and allowing arbitrary ONNX computation. This issue is fixed in version 2.0.82.
An integer overflow vulnerability exists in qiujie mall-server 0.0.1-SNAPSHOT within the CartServiceImpl component. This flaw allows an authenticated user to manipulate the cart quantity to a negative value. The order creation process does not validate this quantity, resulting in incorrect stock updates that increase inventory and generate orders with negative values.
A memory allocation vulnerability exists in ONNX versions prior to 1.22.0 where certain tensor unpacking functions can cause excessive memory allocation based on attacker-controlled input. This can lead to memory exhaustion when processing untrusted tensor data. The issue is resolved in version 1.22.0.
A denial of service vulnerability exists in the rust-zip library versions from 1.3.0 up to but not including 9.0.0. The ZipArchive::extract function improperly uses an attacker-controlled ZIP64 uncompressed_size value to allocate memory, which can cause the process to abort before validating the entry. This abort cannot be caught or contained, allowing repeated denial of service attacks. The issue is fixed in version 9.0.0.
When parsing an AS range in Routinator, if the maximum value of the range is smaller than the minimum value of the range, Routinator will never reach the maximum value and run out of memory.
A vulnerability in the zip-rs zip2 library versions from 0.6.0 up to but not including 9.0.0 allows improper validation of the AES entry reader's HMAC authentication tag. Under certain conditions, such as when the encrypted entry has no payload or the underlying reader reaches the end of the archive prematurely, the library may accept modified plaintext without triggering an authentication error. This flaw is fixed in version 9.0.0.
In the Bluetooth Classic Hands-Free Profile Audio Gateway role, hfp_ag_create() in subsys/bluetooth/host/classic/hfp_ag.c starts an SDP discovery toward the peer, which links the embedded ag->sdp_param._node into the SDP client's pending request list in subsys/bluetooth/host/classic/sdp.c. If the subsequent bt_rfcomm_dlc_connect() call fails, bt_hfp_ag_connect() cleaned up by memset()-ing the entire AG object while that node was still linked, and while ag->slc_work could still be queued on the system work queue. An in-flight SDP discovery cannot be cancelled — bt_sdp_discover_cancel() is declared in the public header but has no implementation — so the request stays in the list with its func, pool and uuid pointers zeroed.
The RFCOMM channel passed to bt_hfp_ag_connect() is taken from the peer's own SDP Hands-Free service record in the normal AG flow (bt_sdp_get_proto_param() performs no range validation, and samples/bluetooth/classic/handsfree_ag feeds the value straight through), so a remote BR/EDR device in radio range that advertises an RFCOMM channel outside the valid range 0x01..0x1e deterministically forces bt_rfcomm_dlc_connect() to fail and reach the wipe. Reading the peer's SDP record requires no pairing, and the peer can also trigger the failure by dropping the ACL or racing an RFCOMM DLC on the same DLCI at the right moment.
When the SDP client next advances its request list, sdp_client_discover() dereferences the zeroed parameters — net_buf_alloc(param->pool, …) with a NULL pool and param->uuid->type — and the result-notification paths call through the NULL params->func. Zeroing a linked node also truncates the request list behind a stale tail pointer, and re-arming the freed AG slot re-appends the same node and can produce a self-looping list that hangs the Bluetooth RX thread. The impact is a crash or hang of the Bluetooth stack; the written value is a constant zero at a fixed static address, so no attacker-controlled write is available.
Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_AG that use the Audio Gateway role are affected.
bt_hfp_hf_connect() in subsys/bluetooth/host/classic/hfp_hf.c allocates the per-connection HFP Hands-Free object with hfp_hf_create(), which starts an SDP discovery by passing the object's embedded hf->sdp_param to bt_sdp_discover(). That call links the caller-owned parameter block into the SDP client's request list (session->reqs in subsys/bluetooth/host/classic/sdp.c). If the subsequent bt_rfcomm_dlc_connect() then failed, the affected code wiped the entire object with (void)memset(new_hf, 0, sizeof(*new_hf)) while that discovery was still outstanding, zeroing the sys_snode_t _node that is still linked in the SDP client's list along with the request's func, uuid and pool pointers, and zeroing the hf->slc_work work item that may already be queued on the system workqueue. The discovery could not be retracted instead: bt_sdp_discover_cancel() is declared in include/zephyr/bluetooth/classic/sdp.h but has no implementation.
The failing branch is reachable with peer-supplied input. The documented use of bt_hfp_hf_connect() is to pass the RFCOMM channel read out of the remote Audio Gateway's SDP record; neither bt_sdp_get_proto_param() nor bt_hfp_hf_connect() range-checks that value, so a remote device advertising an HFP AG record with an RFCOMM channel outside 1-30 makes bt_rfcomm_dlc_connect() return -EINVAL and drives the local device into the wipe. The same branch is reached without any application misuse when the remote peer controls connection timing, for example when the RFCOMM session is in BT_RFCOMM_STATE_DISCONNECTING or the ACL is dropped between object creation and the RFCOMM call.
Once the object has been wiped, the Bluetooth host continues to use it: sdp_client_alloc_buf() dereferences session->param->pool, which is now NULL, and the SDP receive paths call session->param->func() through a null function pointer, neither of which is NULL-checked. Because the wipe also clears hf->acl, the pool slot is considered free and a retry or an incoming HFP connection re-appends the same still-linked list node, turning session->reqs into a self-referential list that the host's list walkers never leave. The result is a fault or an unrecoverable hang in the Bluetooth host thread; the stray indirect call is through an all-zero pointer whose target the attacker does not control, so the practical impact is denial of service.
The fix keeps the object allocated and marks it with a new BT_HFP_HF_FLAG_RELEASING flag, letting bt_hfp_hf_discover_cb() release it once the discovery completes instead of destroying it under the SDP client. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_HF enabled are affected.
The IPv6 stack derived the long-lived secret key used to compute RFC 7217 stable interface identifiers (gen_stable_iid() in subsys/net/ip/ipv6.c) and RFC 8981 temporary interface identifiers (gen_temporary_iid() in subsys/net/ip/ipv6_pe.c) with sys_rand_get(). That API is documented as not cryptographically secure, while both RFCs require this key to be an unpredictable random value of at least 128 bits — the unpredictability of every generated IID rests entirely on it.
Depending on the platform, sys_rand_get() resolves either to a hardware entropy device or, on boards whose entropy driver sets CONFIG_ENTROPY_NEEDS_PRNG, to the non-cryptographic xoshiro128++ generator in subsys/random/random_xoshiro128.c, which keeps a single global 128-bit state shared with every other sys_rand_get() consumer. Many of those consumers put their output directly on the wire (ephemeral source ports, DNS query IDs, CoAP message IDs and tokens, DHCPv6 transaction IDs, WebSocket masking keys), and the xoshiro state transition is invertible, so an observer of a device's traffic can recover the generator state and reconstruct the IID secret key. Additionally, with the entropy-device backend sys_rand_get() silently falls back to k_cycle_get_32() samples when the entropy driver fails, and returns no error, so the key could be derived from the cycle counter without the caller noticing.
With the key known, stable IIDs become directly computable for any prefix (the remaining HMAC inputs — prefix, interface index, interface name, DAD counter — are guessable), and temporary IIDs become linkable after a cheap search over the mixed-in k_uptime_get_32() value. This defeats the properties both features exist to provide: an attacker can track a device across networks and prefixes, and can predict its address inside a /64 without scanning, removing the usual barrier to directly targeting the host. There is no memory-safety, integrity, or availability impact.
The fix generates the key with sys_csrand_get() and aborts IID generation with -EIO when no cryptographic randomness is available, instead of silently deriving addresses from a predictable key. Both CONFIG_NET_IPV6_IID_STABLE and CONFIG_NET_IPV6_PE are experimental and disabled by default; builds using CONFIG_TEST_RANDOM_GENERATOR remain predictable by design, as sys_csrand_get() is deliberately routed back to the test generator there.