Vulnerabilities

i18next-locize-backend is a simple i18next backend for locize.com which can be used in Node.js, in the browser and for Deno. Prior to version 9.0.2, i18next-locize-backend interpolates lng, ns, projectId, and version directly into the configured loadPath / privatePath / addPath / updatePath / getLanguagesPath URL templates with no path-component validation and no encoding. When an application exposes any of these values to user-controlled input (?lng= / ?ns= query parameters via i18next-browser-languagedetector, cookies, request headers, or a URL-derived projectId), a crafted value can change the structure of the outgoing request URL. Affected call sites in lib/index.js (pre-patch): the interpolate() helper is used at the five URL-build sites — _readAny/read (line 415 for private, 426 for public), getLanguages (lines 271 and 296), and writePage (lines 616 and 622) for the missing-key and update POST paths. The helper interpolate in lib/utils.js substitutes raw values with no encoding. This issue has been patched in version 9.0.2.

Akamai Guardicore Platform Agent (GPA) and Zero Trust Client on Linux and macOS allow TOCTOU-based local privilege escalation. The GPA service creates an IPC socket in the world-writable /tmp directory. It accepts unauthenticated IPC control messages. This enables a TOCTOU vulnerability in the HandleSaveLogs() function of the GPA service, by creating a log file and manipulating it into a symlink that points to the targeted path; this can allow an unprivileged local user to make arbitrary root-owned files world-writable. In addition, a diagnostic collection tool (gimmelogs) running with root privileges was vulnerable to command injection from the dbstore, offering a second privilege escalation vector. (On Windows, gimmelogs does not have command injection but does allow writing a ZIP archive to an unintended location.) This affects Akamai Guardicore Platform Agent 7.0 through 7.3.1 and Akamai Zero Trust Client 6.0 through 6.1.5.

An issue was discovered in kosma minmea 0.3.0. The minmea_scan functions format specifier copies NMEA field data to a caller-provided buffer without a size parameter. Applications using minmea_scan on untrusted input are vulnerable to a stack buffer overflow.

lwjson 1.8.1 contains an improper input validation vulnerability in the streaming JSON parser (lwjson_stream.c). The end-of-string detection logic incorrectly identifies escaped quote characters by only checking the immediately preceding character rather than counting consecutive backslashes, causing valid JSON strings ending with an escaped backslash (like "\\") to never terminate parsing. A remote attacker can send well-formed JSON to cause applications using lwjson_stream_parse() to hang indefinitely, resulting in denial of service.

nanoMODBUS through v1.22.0 has a stack-based buffer overflow in recv_read_registers_res() in nanomodbus.c. When a client calls nmbs_read_holding_registers() or nmbs_read_input_registers(), the library writes register data from the server response to the caller-provided buffer based on the response's byte_count field before validating that byte_count matches the requested quantity. A malicious Modbus TCP server can send a response with byte_count=250 (125 registers) regardless of the requested quantity, causing up to 248 bytes of attacker-controlled data to overflow the buffer, potentially allowing remote code execution.

ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.4.0, prior to zebra-chain version 7.0.0, and prior to zebra-network version 6.0.0, several inbound deserialization paths in Zebra allocated buffers sized against generic transport or block-size ceilings before the tighter protocol or consensus limits were enforced. An unauthenticated or post-handshake peer could therefore force the node to preallocate and parse for orders of magnitude more data than the protocol intended, across headers messages, equihash solutions in block headers, Sapling spend vectors in V5/V4 transactions, and coinbase script bytes in blocks. This issue has been patched in zebrad version 4.4.0, zebra-chain version 7.0.0, and zebra-network version 6.0.0.

ZEBRA is a Zcash node written entirely in Rust. Prior to version 4.4.0, Zebra's block validator undercounts transparent signature operations against the 20000-sigop block limit (MAX_BLOCK_SIGOPS), allowing it to accept blocks that zcashd rejects with bad-blk-sigops. A miner who produces such a block can split the network: Zebra nodes follow the offending chain while zcashd nodes do not. This issue has been patched in version 4.4.0.

ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.4.0 and prior to zebra-script version 6.0.0, the fix for CVE-2026-41583 introduced a separate issue due to insufficient error handling of the case where the sighash type is invalid, during sighash computation. Instead of returning an error, the normal flow would resume, and the input sighash buffer would be left untouched. In scenarios where a previous signature validation could leave a valid sighash in the buffer, an invalid hash-type could be incorrectly accepted, which would create a consensus split between Zebra and zcashd nodes. This issue has been patched in zebrad version 4.4.0 and zebra-script version 6.0.0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: return EISDIR on nfs3_proc_create if d_alias is a dir<br /> <br /> If we found an alias through nfs3_do_create/nfs_add_or_obtain<br /> /d_splice_alias which happens to be a dir dentry, we don&amp;#39;t return<br /> any error, and simply forget about this alias, but the original<br /> dentry we were adding and passed as parameter remains negative.<br /> <br /> This later causes an oops on nfs_atomic_open_v23/finish_open since we<br /> supply a negative dentry to do_dentry_open.<br /> <br /> This has been observed running lustre-racer, where dirs and files are<br /> created/removed concurrently with the same name and O_EXCL is not<br /> used to open files (frequent file redirection).<br /> <br /> While d_splice_alias typically returns a directory alias or NULL, we<br /> explicitly check d_is_dir() to ensure that we don&amp;#39;t attempt to perform<br /> file operations (like finish_open) on a directory inode, which triggers<br /> the observed oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix possible NULL pointer dereference in ufshcd_add_command_trace()<br /> <br /> The kernel log indicates a crash in ufshcd_add_command_trace, due to a NULL<br /> pointer dereference when accessing hwq-&gt;id. This can happen if<br /> ufshcd_mcq_req_to_hwq() returns NULL.<br /> <br /> This patch adds a NULL check for hwq before accessing its id field to<br /> prevent a kernel crash.<br /> <br /> Kernel log excerpt:<br /> [] notify_die+0x4c/0x8c<br /> [] __die+0x60/0xb0<br /> [] die+0x4c/0xe0<br /> [] die_kernel_fault+0x74/0x88<br /> [] __do_kernel_fault+0x314/0x318<br /> [] do_page_fault+0xa4/0x5f8<br /> [] do_translation_fault+0x34/0x54<br /> [] do_mem_abort+0x50/0xa8<br /> [] el1_abort+0x3c/0x64<br /> [] el1h_64_sync_handler+0x44/0xcc<br /> [] el1h_64_sync+0x80/0x88<br /> [] ufshcd_add_command_trace+0x23c/0x320<br /> [] ufshcd_compl_one_cqe+0xa4/0x404<br /> [] ufshcd_mcq_poll_cqe_lock+0xac/0x104<br /> [] ufs_mtk_mcq_intr+0x54/0x74 [ufs_mediatek_mod]<br /> [] __handle_irq_event_percpu+0xc8/0x348<br /> [] handle_irq_event+0x3c/0xa8<br /> [] handle_fasteoi_irq+0xf8/0x294<br /> [] generic_handle_domain_irq+0x54/0x80<br /> [] gic_handle_irq+0x1d4/0x330<br /> [] call_on_irq_stack+0x44/0x68<br /> [] do_interrupt_handler+0x78/0xd8<br /> [] el1_interrupt+0x48/0xa8<br /> [] el1h_64_irq_handler+0x14/0x24<br /> [] el1h_64_irq+0x80/0x88<br /> [] arch_local_irq_enable+0x4/0x1c<br /> [] cpuidle_enter+0x34/0x54<br /> [] do_idle+0x1dc/0x2f8<br /> [] cpu_startup_entry+0x30/0x3c<br /> [] secondary_start_kernel+0x134/0x1ac<br /> [] __secondary_switched+0xc4/0xcc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> unshare: fix unshare_fs() handling<br /> <br /> There&amp;#39;s an unpleasant corner case in unshare(2), when we have a<br /> CLONE_NEWNS in flags and current-&gt;fs hadn&amp;#39;t been shared at all; in that<br /> case copy_mnt_ns() gets passed current-&gt;fs instead of a private copy,<br /> which causes interesting warts in proof of correctness]<br /> <br /> &gt; I guess if private means fs-&gt;users == 1, the condition could still be true.<br /> <br /> Unfortunately, it&amp;#39;s worse than just a convoluted proof of correctness.<br /> Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS<br /> (and current-&gt;fs-&gt;users == 1).<br /> <br /> We pass current-&gt;fs to copy_mnt_ns(), all right. Suppose it succeeds and<br /> flips current-&gt;fs-&gt;{pwd,root} to corresponding locations in the new namespace.<br /> Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM).<br /> We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it&amp;#39;s<br /> destroyed and its mount tree is dissolved, but... current-&gt;fs-&gt;root and<br /> current-&gt;fs-&gt;pwd are both left pointing to now detached mounts.<br /> <br /> They are pinning those, so it&amp;#39;s not a UAF, but it leaves the calling<br /> process with unshare(2) failing with -ENOMEM _and_ leaving it with<br /> pwd and root on detached isolated mounts. The last part is clearly a bug.<br /> <br /> There is other fun related to that mess (races with pivot_root(), including<br /> the one between pivot_root() and fork(), of all things), but this one<br /> is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new<br /> fs_struct even if it hadn&amp;#39;t been shared in the first place". Sure, we could<br /> go for something like "if both CLONE_NEWNS *and* one of the things that might<br /> end up failing after copy_mnt_ns() call in create_new_namespaces() are set,<br /> force allocation of new fs_struct", but let&amp;#39;s keep it simple - the cost<br /> of copy_fs_struct() is trivial.<br /> <br /> Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets<br /> a freshly allocated fs_struct, yet to be attached to anything. That<br /> seriously simplifies the analysis...<br /> <br /> FWIW, that bug had been there since the introduction of unshare(2) ;-/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: init flags_valid before calling vfs_fileattr_get<br /> <br /> syzbot reported a uninit-value bug in [1].<br /> <br /> Similar to the "*get" context where the kernel&amp;#39;s internal file_kattr<br /> structure is initialized before calling vfs_fileattr_get(), we should<br /> use the same mechanism when using fa.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517<br /> fuse_fileattr_get+0xeb4/0x1450 fs/fuse/ioctl.c:517<br /> vfs_fileattr_get fs/file_attr.c:94 [inline]<br /> __do_sys_file_getattr fs/file_attr.c:416 [inline]<br /> <br /> Local variable fa.i created at:<br /> __do_sys_file_getattr fs/file_attr.c:380 [inline]<br /> __se_sys_file_getattr+0x8c/0xbd0 fs/file_attr.c:372