Vulnerabilidades

*** Pendiente de traducción *** A vulnerability was found in VictoriaMetrics up to 1.146.0. Impacted is the function requestHandler of the file app/vmauth/main.go of the component VMAuth Authentication Endpoint. Performing a manipulation results in improper restriction of excessive authentication attempts. The attack is possible to be carried out remotely. The complexity of an attack is rather high. The exploitability is considered difficult. The exploit has been made public and could be used. Upgrading to version 1.147.0 is recommended to address this issue. The patch is named 119ba0fb5be8024d50c5ba946599b2e69e8803ea. Upgrading the affected component is recommended.

*** Pendiente de traducción *** A vulnerability has been found in mangroup dtale up to 3.22.0. This issue affects the function Login of the file dtale/auth.py of the component Login Endpoint. Such manipulation leads to improper restriction of excessive authentication attempts. The attack can be executed remotely. This attack is characterized by high complexity. The exploitability is assessed as difficult. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through an issue report but has not responded yet.

*** Pendiente de traducción *** A flaw has been found in mangroup dtale up to 3.22.0. This vulnerability affects the function build_secret_key of the file dtale/app.py of the component Flask Session Cookie. This manipulation causes insufficiently random values. Remote exploitation of the attack is possible. The attack's complexity is rated as high. It is stated that the exploitability is difficult. The exploit has been published and may be used. The pull request to fix this issue awaits acceptance.

*** Pendiente de traducción *** @fastify/oauth2 is an OAuth 2.0 plugin for Fastify. In versions from 7.2.0 up to but not including 8.3.0, the plugin validates the OAuth state, and with PKCE the code verifier, by comparing the callback query parameter against an unprefixed, predictable cookie, with no server-side binding to the browser that began the flow. Any party able to write a cookie for the application's host, such as a sibling subdomain under the same registrable domain, can plant matching state and verifier cookies and complete an attacker-owned OAuth flow inside a victim's browser, silently signing the victim in to the attacker's account (login CSRF). It does not expose the victim's own account, credentials, or tokens. The issue is fixed in @fastify/oauth2 8.3.0, which adds an opt-in hostPrefixedCookies option. Users should upgrade to 8.3.0 and enable it, or bind state to a server-side session.

*** Pendiente de traducción *** @fastify/jwt is a JSON Web Token plugin for Fastify. In versions before 10.2.2, a per-request verification key passed to request.jwtVerify({ key }) is silently overridden by the plugin's globally configured secret, because the option merge applies the global key last. Applications that use different keys for different authorization domains, for example separate user and admin keys, therefore accept a token signed with the global key on a route that explicitly requires another key. This lets an ordinary authenticated user cross a key-based trust boundary without knowing either secret. The issue is fixed in @fastify/jwt 10.2.2, where an explicit per-call key takes precedence over the global secret. Users should upgrade to 10.2.2.

*** Pendiente de traducción *** @fastify/multipart is a multipart form-data parser for Fastify. In versions from 5.3.0 up to but not including 10.1.1, when the busboy fileSize limit truncates a file part, the plugin clears its internal current-file reference while the underlying stream is still open. If the client then aborts the connection before sending the terminating boundary, the abort cleanup finds no stream to destroy, so saveRequestFiles() never settles, the request handler hangs, and the temporary file already written to disk is never cleaned up. An unauthenticated client can repeat this to permanently leak temporary files and suspended handler executions, leading to disk and event-loop exhaustion. The issue is fixed in @fastify/multipart 10.1.1. Users should upgrade to 10.1.1.

*** Pendiente de traducción *** @fastify/multipart is a multipart form-data parser for Fastify. In versions from 3.0.0 up to but not including 10.1.1, request.saveRequestFiles() can leave completed temporary files on disk when a client disconnects while the parser is advancing between multipart parts. The iterator rejection that occurs between parts falls outside the per-file cleanup path, so an earlier completed file is never removed. An unauthenticated client can repeat this to cause persistent, linear disk consumption, leading to denial of service. This is an incomplete-fix variant of CVE-2025-24033. The issue is fixed in @fastify/multipart 10.1.1. Users should upgrade to 10.1.1.

*** Pendiente de traducción *** A vulnerability was detected in opensourcepos Open Source Point of Sale up to 3.4.2. This affects the function Login::index of the file app/Config/Filters.php of the component Login Endpoint. The manipulation results in improper restriction of excessive authentication attempts. The attack may be launched remotely. The attack requires a high level of complexity. It is indicated that the exploitability is difficult. The exploit is now public and may be used. The project was informed of the problem early through an issue report but has not responded yet.

*** Pendiente de traducción *** Dancer2::Plugin::Auth::Extensible versions through 0.713 for Perl allow password reset link poisoning via the request Host header in _default_email_password_reset and _default_welcome_send.<br /> <br /> Both default emails emit a link of the form `$base/login/$code`, whose authority comes from the request Host header, or from X-Forwarded-Host under behind_proxy (obtained from Dancer2&amp;#39;s request-&gt;base function). A POST to /login carrying submit_reset and a username needs no authentication: it stores a fresh reset code against that account and mails the account holder a link to a host of the sender&amp;#39;s choosing. The welcome mail takes the same path when the application calls create_user with email_welcome set.<br /> <br /> Through 0.711 the handlers read `request-&gt;uri_base` and `request-&gt;base` directly; Versions 0.712 and later provide an uri_base configuration key that defaults to the untrusted `request-&gt;uri_base` when unset.<br /> <br /> The default configuration with reset_password_handler enabled and the default message text, a recipient who follows the link hands a working reset code to the sender&amp;#39;s host, which is enough to take over the account.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: fix fdev setup failure cleanup in idxd_cdev_open()<br /> <br /> The failed_dev_add and failed_dev_name paths drop the file-device<br /> reference while wq-&gt;wq_lock is still held. If put_device(fdev) drops the<br /> last reference, idxd_file_dev_release() runs synchronously and tries to<br /> take wq-&gt;wq_lock again, deadlocking.<br /> <br /> Those paths also fall through into the later ctx cleanup labels even<br /> though idxd_file_dev_release() owns that cleanup and frees ctx. This can<br /> make idxd_xa_pasid_remove(ctx) and kfree(ctx) operate on a freed context.<br /> <br /> Move idxd_wq_get() before file-device setup can fail, since the release<br /> callback always calls idxd_wq_put(). Then unlock wq-&gt;wq_lock before<br /> put_device(fdev) and return directly from the file-device setup failure<br /> path, leaving ctx cleanup to the release callback.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Prevent XDomain delayed work use-after-free on disconnect<br /> <br /> tb_xdp_handle_request() runs on system_wq and queues<br /> xd-&gt;state_work via queue_delayed_work() in three request handlers:<br /> PROPERTIES_CHANGED_REQUEST, UUID_REQUEST (via start_handshake),<br /> and LINK_STATE_CHANGE_REQUEST. Similarly, update_xdomain() queues<br /> xd-&gt;properties_changed_work when local properties change.<br /> <br /> Concurrently, tb_xdomain_remove() calls stop_handshake() which does<br /> cancel_delayed_work_sync() on both delayed works. Later,<br /> tb_xdomain_unregister() calls device_unregister() which eventually<br /> frees the xdomain. Since commit 559c1e1e0134 ("thunderbolt: Run<br /> tb_xdp_handle_request() in system workqueue") moved the request<br /> handler off tb-&gt;wq, the handler and the remove path are no longer<br /> serialized. If queue_delayed_work() executes after<br /> cancel_delayed_work_sync() but before the xdomain is freed, the<br /> delayed work fires on a freed object.<br /> <br /> Add xd-&gt;removing that tb_xdomain_remove() sets under xd-&gt;lock<br /> before calling stop_handshake(). Each external queue site holds<br /> the same lock and checks removing before calling<br /> queue_delayed_work(). This provides the mutual exclusion needed:<br /> either the queue site acquires the lock first and queues work that<br /> the subsequent cancel will see, or the remove path acquires the<br /> lock first and the queue site observes removing == true and skips<br /> the queue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slab: prevent unbounded recursion in free path with new kmalloc type<br /> <br /> Commit 280ea9c3154b ("mm/slab: avoid allocating slabobj_ext array from<br /> its own slab") avoided recursive allocation of obj_exts from kmalloc<br /> caches of the same size, by bumping the obj_exts array&amp;#39;s allocation<br /> size whenever the array size equals the size of the object being<br /> allocated.<br /> <br /> However, as reported by Danielle Costantino and Shakeel Butt,<br /> even slabs from kmalloc caches of different sizes can form a cycle<br /> by allocating obj_exts arrays from each other [1]:<br /> <br /> What happened: a KMALLOC_NORMAL slab&amp;#39;s obj_exts array (used by<br /> allocation profiling / memcg accounting) is itself kmalloc()&amp;#39;d from a<br /> KMALLOC_NORMAL cache, so the "slab holds another slab&amp;#39;s obj_exts array"<br /> relation can form cycles. With sizeof(struct slabobj_ext) == 16 and<br /> the host&amp;#39;s geometry:<br /> <br /> - kmalloc-512 has 64 objects/slab -&gt; array is 64*16 == 1024 bytes,<br /> served from kmalloc-1k;<br /> - kmalloc-1k has 32 objects/slab -&gt; array is 32*16 == 512 bytes,<br /> served from kmalloc-512.<br /> <br /> A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other&amp;#39;s<br /> obj_exts array. Discarding one frees the other&amp;#39;s array, which empties<br /> and discards that slab, which frees the first&amp;#39;s array, and so on:<br /> __free_slab() -&gt; free_slab_obj_exts() -&gt; kfree() -&gt; discard_slab() -&gt;<br /> __free_slab() recurses along the cycle until the stack is exhausted.<br /> <br /> With memory allocation profiling, this allows unbounded recursion<br /> in the free path and led to a stack overflow on a production host in<br /> the Meta fleet [1]:<br /> <br /> BUG: TASK stack guard page was hit<br /> Oops: stack guard page<br /> RIP: 0010:kfree+0x8/0x5d0<br /> Call Trace:<br /> __free_slab+0x66/0xc0<br /> kfree+0x3f0/0x5d0<br /> ... ( ~125x __free_slab kfree ) ...<br /> <br /> do_syscall_64<br /> <br /> It is proposed [1] to resolve this issue by always serving the obj_exts<br /> array allocation from kmalloc caches (or large kmalloc) of sizes larger<br /> than the object size. However, as pointed out by Vlastimil Babka [2],<br /> this can waste an excessive amount of memory as slabs from large<br /> kmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much<br /> smaller than the object size.<br /> <br /> Therefore, rather than bumping the size, let us take a different<br /> approach; disallow formation of cycles between kmalloc types when<br /> allocating obj_exts arrays. Currently, all obj_exts arrays are served<br /> from normal kmalloc caches. Cycles cannot be created if obj_exts arrays<br /> of normal kmalloc caches are served from a special kmalloc type that can<br /> never have obj_exts arrays.<br /> <br /> To achieve this, create a new kmalloc type called KMALLOC_NO_OBJ_EXT.<br /> KMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag when<br /> either 1) memory allocation profiling is not permanently disabled,<br /> or 2) kmalloc types with a priority higher than KMALLOC_CGROUP are<br /> aliased with KMALLOC_NORMAL.<br /> <br /> Sheaf bootstrapping for KMALLOC_NO_OBJ_EXT caches now must be deferred<br /> because allocation of a barn can trigger obj_exts array allocation of<br /> normal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size<br /> is not ready yet. For simplicity, perform bootstrapping of sheaves for<br /> all kmalloc caches later.<br /> <br /> Introduce a new slab alloc flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent<br /> allocation of obj_exts arrays, and let kmalloc_slab() override the type<br /> to KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains<br /> unchanged because kmalloc_flags() bypasses the kmalloc fastpath.<br /> <br /> Do not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in<br /> alloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when<br /> the objects are allocated from normal kmalloc caches. While this<br /> prevents unbounded recursive allocation of obj_exts, it allows<br /> KMALLOC_NO_OBJ_EXT caches to have sheaves.<br /> <br /> Since sheaf allocations specify SLAB_ALLOC_NO_RECURSE that prevents<br /> allocation of both sheaves and obj_exts arrays, the recursion depth<br /> is bounded.<br /> <br /> obj_exts arrays for non-<br /> ---truncated---