A vulnerability in the Zephyr DNS stub resolver causes it to use a fixed UDP source port per configured server for DNS queries, violating RFC 5452 requirements. This allows an off-path attacker with UDP reachability to the device to predict the source port and attempt to spoof DNS responses by guessing only the 16-bit transaction ID. Successful spoofing can cause the application to resolve attacker-chosen addresses, potentially poisoning the DNS cache if enabled. The vulnerability is mitigated by a fix that randomizes the source port per query, increasing the guessing space.
The DHCPv4 client in Zephyr's network subsystem used a predictable transaction identifier (xid) for DHCP transactions, violating RFC 2131 requirements. This predictable xid allows an attacker on the same network segment or with prior knowledge of the xid to forge DHCP replies that the client accepts without verifying the server source. Such forged replies can redirect the device's network traffic by changing its default gateway and DNS resolvers, or disrupt network configuration by sending forged DHCPACK or DHCPNAK messages. The issue affects specific Zephyr versions and has a medium severity rating with a CVSS score of 5.6.
A vulnerability in the Zephyr RTIO streaming completion callback adxl345_process_fifo_samples_cb() causes out-of-bounds writes when the allocated buffer is smaller than a full FIFO batch. This leads to silent corruption of other RTIO consumers' data or potential crashes. Exploitation requires specific hardware with an interrupt-wired ADXL345 sensor and certain buffer pool conditions, with no network or external input vector.
ConnMan versions through 2.0 contain a stack-based buffer overflow vulnerability in the DHCPv6 Reply message processing. The flaw exists in the get_domains function in gdhcp/client.c, where a fixed-size buffer is overflowed by copying a large DOMAIN_LIST option without proper length checks. An unauthenticated on-link attacker can exploit this by sending a crafted Router Advertisement and DHCPv6 Reply, causing connmand (running as root) to crash.
Electron versions prior to 42.11.16, 43.8.1, 44.9.1, and 45.0.0-beta.6 do not properly block compromised eMudhra intermediate certificates. This improper certificate revocation check allows an attacker with a certificate from these intermediates to impersonate a TLS server by intercepting network traffic. The vulnerability is fixed in the specified versions.
CVE-2026-105483 is a high severity vulnerability affecting specific Ubuntu-packaged versions of Node.js. The vulnerability has a CVSS 3.0 score of 7.4, indicating a network attack vector with high impact on confidentiality and integrity but no impact on availability. The exact nature of the vulnerability is unknown as no detailed description is provided.
CVE-2026-105482 is a high severity vulnerability affecting specific Ubuntu-distributed versions of Node.js. The vulnerability has a CVSS 3.0 score of 7.4, indicating a network attack vector with high impact on confidentiality and integrity but requiring high attack complexity and no privileges or user interaction. The exact nature of the vulnerability is unknown as no detailed description or technical details are provided. No known exploits in the wild have been reported. The affected versions are specific Ubuntu package builds of Node.js versions 18.13.0, 18.19.1, and 20.19.4. No patch or remediation information is available, and the patch status is not confirmed.
CVE-2026-105481 is a medium severity vulnerability affecting specific Ubuntu-distributed versions of Node.js. The vulnerability has a CVSS 3.0 score of 6.5, indicating a network attack vector with high impact on integrity but low impact on confidentiality and availability. The exact nature of the vulnerability is unknown as no detailed description or technical details are provided. There are no known exploits in the wild, and no patch or remediation information is available from the provided data.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry
With AF_XDP on a striding RQ, mlx5e defers releasing XSK buffers until
an MPWQE is refilled. If XSK allocation then returns -ENOMEM,
actual_wq_head is not advanced and a later NAPI poll retries the same
WQE.
mlx5e_free_rx_mpwqe() leaves each released slot marked as releasable. On
retry it can therefore call xsk_buff_free() again through stale pointers
after the frames have returned to the XSK pool and been reallocated.
Set all skip_release_bitmap bits in the common error path of
mlx5e_xsk_alloc_rx_mpwqe(). This matches mlx5e_alloc_rx_mpwqe(). A
successful allocation already clears the bitmap after replacing every
buffer, so retries become idempotent without changing the success path.
Fault injection forced three consecutive failures for one selected MPWQE.
Both an early allocation failure and a partial 8-of-16-buffer unwind
released the original 16 XSK buffers only once. Each error left a full
bitmap, the following NAPI retry skipped the release, and a later
successful allocation cleared it. A 20-second AF_XDP zero-copy pressure
run exercised 1,575,262 buffer allocation failures without invalid
descriptors, WQE errors, or kernel warnings.
In the Linux kernel, the following vulnerability has been resolved:
riscv: futex: untag the user pointer before the atomic access
access_ok() checks untagged_addr(uaddr), but arch_futex_atomic_op_inuser()
and futex_atomic_cmpxchg_inatomic() hand the raw uaddr to the inline asm
amoswap/amoadd/.../lr.w+sc.w through the "+m" (*uaddr) operand. When the
tagged address ABI is enabled (CONFIG_RISCV_ISA_SUPM, prctl
PR_SET_TAGGED_ADDR_CTRL with PMLEN != 0), those two addresses differ: a
user pointer whose top PMLEN bits hold a tag passes access_ok() after
untagging, but the atomic is then performed on the still-tagged raw
address.
Supervisor-mode data accesses are not subject to the U-mode pointer
masking (that is governed by menvcfg.PMM, which the kernel does not set),
so hardware does not strip the tag for the kernel's own access. With
Sv57 and PMLEN=16 the tag bits overlap the canonical-address bits, so a
tagged pointer can name a canonical kernel virtual address (e.g. in the
linear map) whose untagged form is a valid user address. An unprivileged
process can thus make FUTEX_WAKE_OP perform an atomic read-modify-write on
an arbitrary kernel address, with the matching FUTEX_OP_CMP_* result
serving as a read oracle.
get_user()/put_user()/raw_copy_{to,from}_user() already untag the pointer
after the access_ok() check; do the same in the futex helpers so the
atomic operates on the address that was actually validated.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: em_text: reject unterminated algo before autoload
This is a follow-up to commit 9c572a83037a ("net/sched: fix potential
stack infoleak in em_text_dump()"), which zero-initialised the dump-side
struct. Sashiko pointed at a pre-existing bug that exposed the change-side
input-validation gap open.
em_text_change() casts the raw netlink attribute payload to struct
tcf_em_text and passes conf->algo, a 16-byte array with no enforced NUL
terminator, to textsearch_prepare(). On the TS_AUTOLOAD retry
textsearch_prepare() calls request_module("ts_%s", algo); vsnprintf()
walks %s until it finds a NUL, so an algo[] with no NUL reads past the
array into the adjacent struct fields and payload and feeds those bytes
to the usermode helper command line. This is an out-of-bounds read and
a kernel memory disclosure.
Reject the attribute when no NUL exists within TC_EM_TEXT_ALGOSIZ bytes,
matching the check xt_string has had since 3ab720881b6e.
Conditions to recreate the bug:
- CAP_NET_ADMIN on the target netns (namespace-local via unshare -Urn
is enough)
- install clsact on an interface, then add a basic filter with one text
ematch whose algo[] is 16 bytes with no NUL (e.g. "A"*16) and
pattern_len at least 1
- the add fails with -ENOENT and the kernel invokes modprobe with a
module name made of "ts_" plus the 16 bytes and the adjacent payload
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix xattr replace when multiple xattrs are packed in the same item
If we have a btrfs_dir_item item that packs multiple xattrs and then we
replace the value of one of them (with the setxattr(2) family of syscalls)
with another value of a different size, we end up not having a fully
initialized btrfs_dir_item, resulting in a corruption that the tree
checker will detect at extent buffer writeback time.
This is because in btrfs_setxattr() when we find a btrfs_dir_item with
multiple xattrs (due to the crc32c hash of their name being the same)
we delete one of the xattr items (btrfs_dir_item) and then insert a new
one, but the deletion and insertion results in shifting existing data in
the leaf and therefore when the new value of a xattr has a different size,
the new btrfs_dir_item is placed in a leaf section that was not
initialized and we only copy the value's data and set the value's length
in the new btrfs_dir_item, without setting the name, the name's length,
the key (which must be all zeroes for xattrs), flags (BTRFS_FT_XATTR) and
transaction ID.
The following script reproduces the issue:
$ cat test.sh
#!/bin/bash
DEV=/dev/sdi
MNT=/mnt/sdi
mkfs.btrfs -f $DEV
mount $DEV $MNT
touch $MNT/testfile
# Add two xattrs that, on btrfs, have the same hash (crc32c) for their
# name and therefore are packed into the same btrfs_dir_item.
setfattr -n user.foobar -v 123 $MNT/testfile
setfattr -n user.WvG1c1Td -v qwerty $MNT/testfile
# Verify the xattrs are present.
echo "xattrs before:"
getfattr --absolute-names --dump $MNT/testfile
# Now replace the value of the foobar xattr with a significantly larger
# value.
setfattr -n user.foobar -v abcdefghijklmnopqrstuvwxyz $MNT/testfile
# Check the xattrs have the expected values.
echo "xattrs after:"
getfattr --absolute-names --dump $MNT/testfile
umount $MNT
Running it:
$ ./test.sh
(...)
xattrs before:
# file: /mnt/sdi/testfile
user.WvG1c1Td="qwerty"
user.foobar="123"
xattrs after:
# file: /mnt/sdi/testfile
user.WvG1c1Td="qwerty"
So the "user.foobar" xattr is missing and there was a transaction abort
when unmounting the fs with the following traces in dmesg:
$ dmesg
[869800.159271] BTRFS warning (device sdi): access to eb bytenr 30474240 len 16384 out of range start 16015 len 25964
[869800.159293] ------------[ cut here ]------------
[869800.159296] WARNING: fs/btrfs/extent_io.c:4408 at report_eb_range+0x44/0x60 [btrfs], CPU#8: getfattr/2605179
[869800.168961] Modules linked in: btrfs dm_thin_pool (...)
[869800.190527] CPU: 8 UID: 0 PID: 2605179 Comm: getfattr Tainted: G W 7.3.0-rc3-btrfs-next-244+ #1 PREEMPT(full)
[869800.193726] Tainted: [W]=WARN
[869800.194502] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
[869800.197576] RIP: 0010:report_eb_range+0x44/0x60 [btrfs]
[869800.198985] Code: 48 8b 7b 18 (...)
[869800.203531] RSP: 0018:ffffce4541937d58 EFLAGS: 00010246
[869800.204609] RAX: 0000000000000000 RBX: ffff8dde054b8738 RCX: 0000000000000000
[869800.206137] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffc04c92a0
[869800.207645] RBP: 0000000000003e8f R08: 0000000000000000 R09: 3fffffffffefffff
[869800.226175] R10: ffffce4541937a88 R11: 0000000000000003 R12: 000000000000656c
[869800.227594] R13: ffff8dde14be800f R14: 000000000000656c R15: 0000000000000069
[869800.229097] FS: 00007f59023bb780(0000) GS:ffff8de5788ed000(0000) knlGS:0000000000000000
[869800.231137] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[869800.232321] CR2: 0000558dc45e6a78 CR3: 0000000765b16004 CR4: 0000000000370ef0
[869800.233783] Call Trace:
[869800.234330] <TASK>
[869800.234791] read_extent_buffer+0x4d/0x100 [btrfs]
[869800.235898] btrfs_listxattr+0x199/0x240 [btrfs]
[869800.236912] vfs_listxattr+0x51/0
---truncated---
Cacti versions from 1.2.27 up to but not including 1.2.31 contain an authenticated stored second-order SQL injection vulnerability in the automation tree rule item handler. A user with Automation realm privileges can inject arbitrary SQL fragments that are later executed when an administrator applies automation rules, leading to potential data exfiltration via the UI. This vulnerability has been fixed in version 1.2.31.
A mailbox quota-accounting vulnerability in Zimbra Collaboration Suite (ZCS) allows an authenticated user to consume another user’s mailbox quota by repeatedly sharing and revoking a document. Creation of the recipient’s shared-file record charges the document size to mailbox-wide usage. Revocation deletes the record and reverses its folder counters without reversing the mailbox-wide charge. Repeated normal share notifications therefore accumulate quota usage after the visible records are gone. On accounts with a finite quota, this can prevent incoming mail and other size-increasing operations without recipient interaction. The issue affects ZCS 10.1.16 and 10.1.20.
An SMTP command injection vulnerability in the data-source testing functionality of Zimbra Collaboration Suite (ZCS) allows an ordinary authenticated user with account options enabled to inject CR/LF into the emailAddress inserted into an SMTP envelope command by a JSON SOAP request. After a successful preliminary POP3 or IMAP login, Zimbra sends the injected commands to the selected SMTP service. If that service accepts the pipelined transaction, the attacker can submit mail with attacker-selected recipients, headers and body content without victim interaction. The vulnerable command-construction path is present in ZCS 10.1.16 and 10.1.20.
A local privilege escalation vulnerability in the optional dnscache package of Zimbra Collaboration Suite (ZCS) allows the Unix zimbra account to access files with root privileges. The passwordless sudo policy permits arbitrary arguments to zmunbound, whose wrapper forwards them to Unbound without restricting the configuration path. An attacker can supply a configuration that retains root privileges and disables the chroot. Include directives expose root-readable file contents through parser errors, while an attacker-selected logfile path creates a root-owned file or appends Unbound log records to an existing file. This can disclose password hashes and private keys and corrupt privileged configuration files, preventing affected services from starting with the modified configuration. The affected configuration is present in ZCS 10.1.16 and 10.1.21 dnscache packages.
A local privilege escalation vulnerability in the Zimbra Collaboration Suite (ZCS) MTA package allows the Unix zimbra account to execute arbitrary commands as root. The installed sudo policy permits passwordless root execution of Postfix administration commands without restricting their arguments. An attacker can select a zimbra-controlled daemon_directory in the Postfix configuration and invoke postfix set-permissions, causing Postfix to execute the attacker's post-install program as root. The Postfix configuration directory is also writable by zimbra, so restricting postconf alone does not remove the execution path. Exploitation requires local command execution as zimbra on an MTA node. ZCS 10.1.16 and 10.1.21 are affected.
A local privilege escalation vulnerability in the zmmailboxdmgr launcher of Zimbra Collaboration Suite (ZCS) allows the Unix zimbra account to execute arbitrary commands as root. The passwordless sudo interface accepts JVM arguments that are not adequately restricted. An attacker can postpone Jetty's privilege drop, register an OnOutOfMemoryError command and force heap exhaustion during startup, causing the command to execute while the JVM still runs as root. Exploitation requires local command execution as zimbra on a mailbox server and interrupts mailboxd during the malicious restart. ZCS 10.1.16 and 10.1.21 are affected.
A missing authorization vulnerability in Zimbra Collaboration Suite (ZCS) allows a delegated administrator with no explicit administrative grants to overwrite global Zimlet configuration through ConfigureZimletRequest. The uploaded configuration can also add an attacker-controlled domain to the proxy allowlist of the default class of service. If a signed-in user in that class opens a crafted /service/proxy URL, Zimbra serves attacker-controlled HTML under its own origin. The resulting JavaScript can read mailbox data and perform authenticated actions as the victim. Exploitation requires a delegated-administrator account and access to the admin SOAP service; the browser compromise additionally requires the victim to open the crafted URL. ZCS 10.1.16 and 10.1.20 are affected.
A reflected cross-site scripting vulnerability in the login page of Zimbra Collaboration Suite (ZCS) allows an unauthenticated attacker to execute JavaScript through the zrememberme parameter. A crafted relogin URL selects a two-factor error display that inserts the parameter into a hidden input attribute without HTML encoding. A victim who opens the URL receives attacker-controlled script and page content under the legitimate Zimbra origin, allowing credential capture through a replacement login form. The relogin path logs out an existing session before rendering the payload, so the demonstrated attack does not inherit that session's mailbox access. ZCS 10.1.16 and 10.1.17 are affected.