Vulnerabilidades

*** Pendiente de traducción *** Glances is an open-source system cross-platform monitoring tool. The GHSA-gh4x fix (commit 5d3de60) addressed unauthenticated configuration secrets exposure on the `/api/v4/config` endpoints by introducing `as_dict_secure()` redaction. However, the `/api/v4/args` and `/api/v4/args/{item}` endpoints were not addressed by this fix. These endpoints return the complete command-line arguments namespace via `vars(self.args)`, which includes the password hash (salt + pbkdf2_hmac), SNMP community strings, SNMP authentication keys, and the configuration file path. When Glances runs without `--password` (the default), these endpoints are accessible without any authentication. Version 4.5.2 provides a more complete fix.

*** Pendiente de traducción *** In Juju from version 3.0.0 through 3.6.18, when a secret owner grants permissions to a secret to a grantee, the secret owner relies exclusively on a predictable XID of the secret to verify ownership. This allows a malicious grantee which can request secrets to predict past secrets granted by the same secret owner to different grantees, allowing them to use the resources granted by those past secrets. Successful exploitation relies on a very specific configuration, specific data semantic, and the administrator having the need to deploy at least two different applications, one of them controlled by the attacker.

*** Pendiente de traducción *** Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in OpenText™ ZENworks Service Desk allows Cross-Site Scripting (XSS). The vulnerability could allow an attacker to execute arbitrary JavaScript leading to unauthorized actions on behalf of the user.This issue affects ZENworks Service Desk: 25.2, 25.3.

*** Pendiente de traducción *** Deserialization of Untrusted Data vulnerability in Shinetheme Traveler allows Object Injection.This issue affects Traveler: from n/a before 3.2.8.1.

*** Pendiente de traducción *** A race condition in the secrets management subsystem of Juju versions 3.0.0 through 3.6.18 allows an authenticated unit agent to claim ownership of a newly initialized secret. Between generating a Juju Secret ID and creating the secret's first revision, an attacker authenticated as another unit agent can claim ownership of a known secret. This leads to the attacking unit being able to read the content of the initial secret revision.

*** Pendiente de traducción *** An authorization bypass vulnerability in the Vault secrets back-end implementation of Juju versions 3.1.6 through 3.6.18 allows an authenticated unit agent to perform unauthorized updates to secret revisions. With sufficient information, an attacker can poison any existing secret revision within the scope of that Vault secret back-end.

*** Pendiente de traducción *** In Juju from version 3.0.0 through 3.6.18, the authorization of the "secret-set" tool is not performed correctly, which allows a grantee to update the secret content, and can lead to reading or updating other secrets. When the "secret-set" tool logs an error in an exploitation attempt, the secret is still updated contrary to expectations, and the new value is visible to both the owner and the grantee.

*** Pendiente de traducción *** In LibreChat 0.8.1-rc2, a logged-in user obtains a JWT for both the LibreChat API and the RAG API.

*** Pendiente de traducción *** LibreChat version 0.8.1-rc2 uses the same JWT secret for the user session mechanism and RAG API which compromises the service-level authentication of the RAG API.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/umad: Reject negative data_len in ib_umad_write<br /> <br /> ib_umad_write computes data_len from user-controlled count and the<br /> MAD header sizes. With a mismatched user MAD header size and RMPP<br /> header length, data_len can become negative and reach ib_create_send_mad().<br /> This can make the padding calculation exceed the segment size and trigger<br /> an out-of-bounds memset in alloc_send_rmpp_list().<br /> <br /> Add an explicit check to reject negative data_len before creating the<br /> send buffer.<br /> <br /> KASAN splat:<br /> [ 211.363464] BUG: KASAN: slab-out-of-bounds in ib_create_send_mad+0xa01/0x11b0<br /> [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spray_thread/102<br /> [ 211.365867] ib_create_send_mad+0xa01/0x11b0<br /> [ 211.365887] ib_umad_write+0x853/0x1c80

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: fix memory allocation in nvme_pr_read_keys()<br /> <br /> nvme_pr_read_keys() takes num_keys from userspace and uses it to<br /> calculate the allocation size for rse via struct_size(). The upper<br /> limit is PR_KEYS_MAX (64K).<br /> <br /> A malicious or buggy userspace can pass a large num_keys value that<br /> results in a 4MB allocation attempt at most, causing a warning in<br /> the page allocator when the order exceeds MAX_PAGE_ORDER.<br /> <br /> To fix this, use kvzalloc() instead of kzalloc().<br /> <br /> This bug has the same reasoning and fix with the patch below:<br /> https://lore.kernel.org/linux-block/20251212013510.3576091-1-kartikey406@gmail.com/<br /> <br /> Warning log:<br /> WARNING: mm/page_alloc.c:5216 at __alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216, CPU#1: syz-executor117/272<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 272 Comm: syz-executor117 Not tainted 6.19.0 #1 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216<br /> Code: ff 83 bd a8 fe ff ff 0a 0f 86 69 fb ff ff 0f b6 1d f9 f9 c4 04 80 fb 01 0f 87 3b 76 30 ff 83 e3 01 75 09 c6 05 e4 f9 c4 04 01 0b 48 c7 85 70 fe ff ff 00 00 00 00 e9 8f fd ff ff 31 c0 e9 0d<br /> RSP: 0018:ffffc90000fcf450 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff920001f9ea0<br /> RDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000040dc0<br /> RBP: ffffc90000fcf648 R08: ffff88800b6c3380 R09: 0000000000000001<br /> R10: ffffc90000fcf840 R11: ffff88807ffad280 R12: 0000000000000000<br /> R13: 0000000000040dc0 R14: 0000000000000001 R15: ffffc90000fcf620<br /> FS: 0000555565db33c0(0000) GS:ffff8880be26c000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000002000000c CR3: 0000000003b72000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> alloc_pages_mpol+0x236/0x4d0 mm/mempolicy.c:2486<br /> alloc_frozen_pages_noprof+0x149/0x180 mm/mempolicy.c:2557<br /> ___kmalloc_large_node+0x10c/0x140 mm/slub.c:5598<br /> __kmalloc_large_node_noprof+0x25/0xc0 mm/slub.c:5629<br /> __do_kmalloc_node mm/slub.c:5645 [inline]<br /> __kmalloc_noprof+0x483/0x6f0 mm/slub.c:5669<br /> kmalloc_noprof include/linux/slab.h:961 [inline]<br /> kzalloc_noprof include/linux/slab.h:1094 [inline]<br /> nvme_pr_read_keys+0x8f/0x4c0 drivers/nvme/host/pr.c:245<br /> blkdev_pr_read_keys block/ioctl.c:456 [inline]<br /> blkdev_common_ioctl+0x1b71/0x29b0 block/ioctl.c:730<br /> blkdev_ioctl+0x299/0x700 block/ioctl.c:786<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl fs/ioctl.c:583 [inline]<br /> __x64_sys_ioctl+0x1bf/0x220 fs/ioctl.c:583<br /> x64_sys_call+0x1280/0x21b0 mnt/fuzznvme_1/fuzznvme/linux-build/v6.19/./arch/x86/include/generated/asm/syscalls_64.h:17<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x71/0x330 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fb893d3108d<br /> Code: 28 c3 e8 46 1e 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffff61f2f38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffff61f3138 RCX: 00007fb893d3108d<br /> RDX: 0000000020000040 RSI: 00000000c01070ce RDI: 0000000000000003<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 00007ffff61f3138<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001<br /> R13: 00007ffff61f3128 R14: 00007fb893dae530 R15: 0000000000000001<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_gate: snapshot parameters with RCU on replace<br /> <br /> The gate action can be replaced while the hrtimer callback or dump path is<br /> walking the schedule list.<br /> <br /> Convert the parameters to an RCU-protected snapshot and swap updates under<br /> tcf_lock, freeing the previous snapshot via call_rcu(). When REPLACE omits<br /> the entry list, preserve the existing schedule so the effective state is<br /> unchanged.