| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Backstage is an open framework for building developer portals. Multiple Scaffolder actions and archive extraction utilities were vulnerable to symlink-based path traversal attacks. An attacker with access to create and execute Scaffolder templates could exploit symlinks to read arbitrary files via the `debug:log` action by creating a symlink pointing to sensitive files (e.g., `/etc/passwd`, configuration files, secrets); delete arbitrary files via the `fs:delete` action by creating symlinks pointing outside the workspace, and write files outside the workspace via archive extraction (tar/zip) containing malicious symlinks. This affects any Backstage deployment where users can create or execute Scaffolder templates. This vulnerability is fixed in `@backstage/backend-defaults` versions 0.12.2, 0.13.2, 0.14.1, and 0.15.0; `@backstage/plugin-scaffolder-backend` versions 2.2.2, 3.0.2, and 3.1.1; and `@backstage/plugin-scaffolder-node` versions 0.11.2 and 0.12.3. Users should upgrade to these versions or later. Some workarounds are available. Follow the recommendation in the Backstage Threat Model to limit access to creating and updating templates, restrict who can create and execute Scaffolder templates using the permissions framework, audit existing templates for symlink usage, and/or run Backstage in a containerized environment with limited filesystem access. |
| Element Server Suite Community Edition (ESS Community) deploys a Matrix stack using the provided Helm charts and Kubernetes distribution. The ESS Community Helm Chart secrets initialization hook (using matrix-tools container before 0.5.7) is using an insecure Matrix server key generation method, allowing network attackers to potentially recreate the same key pair, allowing them to impersonate the victim server. The secret is generated by the secrets initialization hook, in the ESS Community Helm Chart values, if both initSecrets.enabled is not set to false and synapse.signingKey is not defined. Given a server key in Matrix authenticates both requests originating from and events constructed on a given server, this potentially impacts confidentiality, integrity and availability of rooms which have a vulnerable server present as a member. The confidentiality of past conversations in end-to-end encrypted rooms is not impacted. The key generation issue was fixed in matrix-tools 0.5.7, released as part of ESS Community Helm Chart 25.12.1. |
| Swift W3C TraceContext is a Swift implementation of the W3C Trace Context standard, and Swift OTel is an OpenTelemetry Protocol (OTLP) backend for Swift Log, Swift Metrics, and Swift Distributed Tracing. Prior to Swift W3C TraceContext version 1.0.0-beta.5 and Swift OTel version 1.0.4, a denial-of-service vulnerability due to improper input validation allows a remote attacker to crash the service via a malformed HTTP header. This allows crashing the process with data coming from the network when used with, for example, an HTTP server. Most common way of using Swift W3C Trace Context is through Swift OTel. Version 1.0.0-beta.5 of Swift W3C TraceContext and version 1.0.4 of Swift OTel contain a patch for this issue. As a workaround, disable either Swift OTel or the code that extracts the trace information from an incoming header (such as a `TracingMiddleware`). |
| Tandoor Recipes is a recipe manager than can be installed with the Nix package manager. Starting in version 23.05 and prior to version 26.05, when using the default configuration of Tandoor Recipes, specifically using SQLite and default `MEDIA_ROOT`, the full database file may be externally accessible, potentially on the Internet. The root cause is that the NixOS module configures the working directory of Tandoor Recipes, as well as the value of `MEDIA_ROOT`, to be `/var/lib/tandoor-recipes`. This causes Tandoor Recipes to create its `db.sqlite3` database file in the same directory as `MEDIA_ROOT` causing it to be accessible without authentication through HTTP like any other media file. This is the case when using `GUNICORN_MEDIA=1` or when using a web server like nginx to serve media files. NixOS 26.05 changes the default value of `MEDIA_ROOT` to a sub folder of the data directory. This only applies to configurations with `system.stateVersion` >= 26.05. For older configurations, one of the workarounds should be applied instead. NixOS 25.11 has received a backport of this patch, though it doesn't fix this vulnerability without user intervention. A recommended workaround is to move `MEDIA_ROOT` into a subdirectory. Non-recommended workarounds include switching to PostgreSQL or disallowing access to `db.sqlite3`. |
| VB-Audio Voicemeeter, Voicemeeter Banana, and Voicemeeter Potato (versions ending in 1.1.1.9, 2.1.1.9, and 3.1.1.9 and earlier, respectively), as well as VB-Audio Matrix and Matrix Coconut (versions ending in 1.0.2.2 and 2.0.2.2 and earlier, respectively), contain a vulnerability in their virtual audio drivers (vbvoicemeetervaio64*.sys, vbmatrixvaio64*.sys, vbaudio_vmauxvaio*.sys, vbaudio_vmvaio*.sys, and vbaudio_vmvaio3*.sys). The drivers allocate non-paged pool and map it into user space, where a length value associated with the allocation is exposed and can be modified by an unprivileged local attacker. On subsequent IOCTL handling, the corrupted length is used directly as the IoAllocateMdl length argument without adequate integrity checks before building and mapping the MDL, which can cause a kernel crash (BSoD), typically PAGE_FAULT_IN_NONPAGED_AREA. This flaw allows a local user to trigger a denial-of-service on affected Windows systems. |
| VB-Audio Matrix and Matrix Coconut (versions ending in 1.0.2.2 and 2.0.2.2 and earlier, respectively), contain a local privilege escalation vulnerability in the VBMatrix VAIO virtual audio driver (vbmatrixvaio64*_win10.sys). The driver allocates a 128-byte non-paged pool buffer and, upon receiving IOCTL 0x222060, maps it into user space using an MDL and MmMapLockedPagesSpecifyCache. Because the allocation size is not page-aligned, the mapping exposes the entire 0x1000-byte kernel page containing the buffer plus adjacent non-paged pool allocations with read/write permissions. An unprivileged local attacker can open a device handle (using the required 0x800 attribute flag), invoke the IOCTL to obtain the mapping, and then read or modify live kernel objects and pointers present on that page. This enables bypass of KASLR, arbitrary kernel memory read/write within the exposed page, corruption of kernel objects, and escalation to SYSTEM. |
| VB-Audio Voicemeeter, Voicemeeter Banana, and Voicemeeter Potato (versions ending in 1.1.1.9, 2.1.1.9, and 3.1.1.9 and earlier, respectively), as well as VB-Audio Matrix and Matrix Coconut (versions ending in 1.0.2.2 and 2.0.2.2 and earlier, respectively), contain a vulnerability in their virtual audio drivers (vbvoicemeetervaio64*.sys, vbmatrixvaio64*.sys, vbaudio_vmauxvaio*.sys, vbaudio_vmvaio*.sys, and vbaudio_vmvaio3*.sys). The drivers map non-paged pool memory into user space via MmMapLockedPagesSpecifyCache using UserMode access without proper exception handling. If the mapping fails, such as when a process has exhausted available virtual address space, MmMapLockedPagesSpecifyCache raises an exception that is not caught, causing a kernel crash (BSoD), typically SYSTEM_SERVICE_EXCEPTION with STATUS_NO_MEMORY. This flaw allows a local unprivileged user to trigger a denial-of-service on affected Windows systems. |
| Entrust Instant Financial Issuance (IFI) On Premise software (formerly referred to as CardWizard) versions 5.x, prior to 6.10.5, and prior to 6.11.1 contain an insecure .NET Remoting exposure in the SmartCardController service (DCG.SmartCardControllerService.exe). The service registers a TCP remoting channel with unsafe formatter/settings that permit untrusted remoting object invocation. A remote, unauthenticated attacker who can reach the remoting port can invoke exposed remoting objects to read arbitrary files from the server and coerce outbound authentication, and may achieve arbitrary file write and remote code execution via known .NET Remoting exploitation techniques. This can lead to disclosure of sensitive installation and service-account data and compromise of the affected host. |
| ElementsKit Elementor Addons – Advanced Widgets & Templates Addons for Elementor (elementskit-lite) WordPress plugin versions prior to 3.7.9 expose the REST endpoint /wp-json/elementskit/v1/widget/mailchimp/subscribe without authentication. The endpoint accepts client-supplied Mailchimp API credentials and insufficiently validates certain parameters, including the list parameter, when constructing upstream Mailchimp API requests. An unauthenticated attacker can abuse the endpoint as an open proxy to Mailchimp, potentially triggering unauthorized API calls, manipulating subscription data, exhausting API quotas, or causing resource consumption on the affected WordPress site. |
| The WP Accessibility plugin for WordPress is vulnerable to Stored DOM-Based Cross-Site Scripting via the 'alt' attribute of images processed by the "Long Description UI" feature in all versions up to, and including, 2.3.1. This is due to the plugin's JavaScript retrieving the alt attribute using getAttribute() and unsafely concatenating it into innerHTML and insertAdjacentHTML calls without proper sanitization or escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. Exploitation requires the "Long Description UI" setting to be enabled and set to "Link to description." |
| PostgreSQL Anonymizer contains a vulnerability that allows a user to gain superuser privileges by creating a custom operator in the public schema and place malicious code in that operator. This operator will later be executed with superuser privileges when the extension is created. The risk is higher with PostgreSQL 14 or with instances upgraded from PostgreSQL 14 or a prior version. With PostgreSQL 15 and later, the creation permission on the public schema is revoked by default and this exploit can only be achieved if a superuser adds a new schema in her/his own search_path and grants the CREATE privilege on that schema to untrusted users, both actions being clearly discouraged by the PostgreSQL documentation. The problem is resolved in PostgreSQL Anonymizer 3.0.1 and further versions |
| In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: Coalesce only linear skb
vsock/virtio common tries to coalesce buffers in rx queue: if a linear skb
(with a spare tail room) is followed by a small skb (length limited by
GOOD_COPY_LEN = 128), an attempt is made to join them.
Since the introduction of MSG_ZEROCOPY support, assumption that a small skb
will always be linear is incorrect. In the zerocopy case, data is lost and
the linear skb is appended with uninitialized kernel memory.
Of all 3 supported virtio-based transports, only loopback-transport is
affected. G2H virtio-transport rx queue operates on explicitly linear skbs;
see virtio_vsock_alloc_linear_skb() in virtio_vsock_rx_fill(). H2G
vhost-transport may allocate non-linear skbs, but only for sizes that are
not considered for coalescence; see PAGE_ALLOC_COSTLY_ORDER in
virtio_vsock_alloc_skb().
Ensure only linear skbs are coalesced. Note that skb_tailroom(last_skb) > 0
guarantees last_skb is linear. |
| In the Linux kernel, the following vulnerability has been resolved:
ftrace: Do not over-allocate ftrace memory
The pg_remaining calculation in ftrace_process_locs() assumes that
ENTRIES_PER_PAGE multiplied by 2^order equals the actual capacity of the
allocated page group. However, ENTRIES_PER_PAGE is PAGE_SIZE / ENTRY_SIZE
(integer division). When PAGE_SIZE is not a multiple of ENTRY_SIZE (e.g.
4096 / 24 = 170 with remainder 16), high-order allocations (like 256 pages)
have significantly more capacity than 256 * 170. This leads to pg_remaining
being underestimated, which in turn makes skip (derived from skipped -
pg_remaining) larger than expected, causing the WARN(skip != remaining)
to trigger.
Extra allocated pages for ftrace: 2 with 654 skipped
WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7295 ftrace_process_locs+0x5bf/0x5e0
A similar problem in ftrace_allocate_records() can result in allocating
too many pages. This can trigger the second warning in
ftrace_process_locs().
Extra allocated pages for ftrace
WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7276 ftrace_process_locs+0x548/0x580
Use the actual capacity of a page group to determine the number of pages
to allocate. Have ftrace_allocate_pages() return the number of allocated
pages to avoid having to calculate it. Use the actual page group capacity
when validating the number of unused pages due to skipped entries.
Drop the definition of ENTRIES_PER_PAGE since it is no longer used. |
| In the Linux kernel, the following vulnerability has been resolved:
pNFS: Fix a deadlock when returning a delegation during open()
Ben Coddington reports seeing a hang in the following stack trace:
0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415
1 [ffffd0b50e177548] schedule at ffffffff9ca05717
2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1
3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb
4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5
5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4]
6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4]
7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4]
8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4]
9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4]
10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4]
11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4]
12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4]
13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4]
14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4]
15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4]
16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4]
17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea
18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e
19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935
The issue is that the delegreturn is being asked to wait for a layout
return that cannot complete because a state recovery was initiated. The
state recovery cannot complete until the open() finishes processing the
delegations it was given.
The solution is to propagate the existing flags that indicate a
non-blocking call to the function pnfs_roc(), so that it knows not to
wait in this situation. |
| In the Linux kernel, the following vulnerability has been resolved:
libceph: make calc_target() set t->paused, not just clear it
Currently calc_target() clears t->paused if the request shouldn't be
paused anymore, but doesn't ever set t->paused even though it's able to
determine when the request should be paused. Setting t->paused is left
to __submit_request() which is fine for regular requests but doesn't
work for linger requests -- since __submit_request() doesn't operate
on linger requests, there is nowhere for lreq->t.paused to be set.
One consequence of this is that watches don't get reestablished on
paused -> unpaused transitions in cases where requests have been paused
long enough for the (paused) unwatch request to time out and for the
subsequent (re)watch request to enter the paused state. On top of the
watch not getting reestablished, rbd_reregister_watch() gets stuck with
rbd_dev->watch_mutex held:
rbd_register_watch
__rbd_register_watch
ceph_osdc_watch
linger_reg_commit_wait
It's waiting for lreq->reg_commit_wait to be completed, but for that to
happen the respective request needs to end up on need_resend_linger list
and be kicked when requests are unpaused. There is no chance for that
if the request in question is never marked paused in the first place.
The fact that rbd_dev->watch_mutex remains taken out forever then
prevents the image from getting unmapped -- "rbd unmap" would inevitably
hang in D state on an attempt to grab the mutex. |
| In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix NULL pointer crash in bnxt_ptp_enable during error cleanup
When bnxt_init_one() fails during initialization (e.g.,
bnxt_init_int_mode returns -ENODEV), the error path calls
bnxt_free_hwrm_resources() which destroys the DMA pool and sets
bp->hwrm_dma_pool to NULL. Subsequently, bnxt_ptp_clear() is called,
which invokes ptp_clock_unregister().
Since commit a60fc3294a37 ("ptp: rework ptp_clock_unregister() to
disable events"), ptp_clock_unregister() now calls
ptp_disable_all_events(), which in turn invokes the driver's .enable()
callback (bnxt_ptp_enable()) to disable PTP events before completing the
unregistration.
bnxt_ptp_enable() attempts to send HWRM commands via bnxt_ptp_cfg_pin()
and bnxt_ptp_cfg_event(), both of which call hwrm_req_init(). This
function tries to allocate from bp->hwrm_dma_pool, causing a NULL
pointer dereference:
bnxt_en 0000:01:00.0 (unnamed net_device) (uninitialized): bnxt_init_int_mode err: ffffffed
KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
Call Trace:
__hwrm_req_init (drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c:72)
bnxt_ptp_enable (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:323 drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:517)
ptp_disable_all_events (drivers/ptp/ptp_chardev.c:66)
ptp_clock_unregister (drivers/ptp/ptp_clock.c:518)
bnxt_ptp_clear (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:1134)
bnxt_init_one (drivers/net/ethernet/broadcom/bnxt/bnxt.c:16889)
Lines are against commit f8f9c1f4d0c7 ("Linux 6.19-rc3")
Fix this by clearing and unregistering ptp (bnxt_ptp_clear()) before
freeing HWRM resources. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/userq: Fix fence reference leak on queue teardown v2
The user mode queue keeps a pointer to the most recent fence in
userq->last_fence. This pointer holds an extra dma_fence reference.
When the queue is destroyed, we free the fence driver and its xarray,
but we forgot to drop the last_fence reference.
Because of the missing dma_fence_put(), the last fence object can stay
alive when the driver unloads. This leaves an allocated object in the
amdgpu_userq_fence slab cache and triggers
This is visible during driver unload as:
BUG amdgpu_userq_fence: Objects remaining on __kmem_cache_shutdown()
kmem_cache_destroy amdgpu_userq_fence: Slab cache still has objects
Call Trace:
kmem_cache_destroy
amdgpu_userq_fence_slab_fini
amdgpu_exit
__do_sys_delete_module
Fix this by putting userq->last_fence and clearing the pointer during
amdgpu_userq_fence_driver_free().
This makes sure the fence reference is released and the slab cache is
empty when the module exits.
v2: Update to only release userq->last_fence with dma_fence_put()
(Christian)
(cherry picked from commit 8e051e38a8d45caf6a866d4ff842105b577953bb) |
| In the Linux kernel, the following vulnerability has been resolved:
null_blk: fix kmemleak by releasing references to fault configfs items
When CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blk
driver sets up fault injection support by creating the timeout_inject,
requeue_inject, and init_hctx_fault_inject configfs items as children
of the top-level nullbX configfs group.
However, when the nullbX device is removed, the references taken to
these fault-config configfs items are not released. As a result,
kmemleak reports a memory leak, for example:
unreferenced object 0xc00000021ff25c40 (size 32):
comm "mkdir", pid 10665, jiffies 4322121578
hex dump (first 32 bytes):
69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_
69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject..........
backtrace (crc 1a018c86):
__kmalloc_node_track_caller_noprof+0x494/0xbd8
kvasprintf+0x74/0xf4
config_item_set_name+0xf0/0x104
config_group_init_type_name+0x48/0xfc
fault_config_init+0x48/0xf0
0xc0080000180559e4
configfs_mkdir+0x304/0x814
vfs_mkdir+0x49c/0x604
do_mkdirat+0x314/0x3d0
sys_mkdir+0xa0/0xd8
system_call_exception+0x1b0/0x4f0
system_call_vectored_common+0x15c/0x2ec
Fix this by explicitly releasing the references to the fault-config
configfs items when dropping the reference to the top-level nullbX
configfs group. |
| vCluster Platform provides a Kubernetes platform for managing virtual clusters, multi-tenancy, and cluster sharing. Prior to versions 4.6.0, 4.5.4, 4.4.2, and 4.3.10, when an access key is created with a limited scope, the scope can be bypassed to access resources outside of it. However, the user still cannot access resources beyond what is accessible to the owner of the access key. Versions 4.6.0, 4.5.4, 4.4.2, and 4.3.10 fix the vulnerability. Some other mitigations are available. Users can limit exposure by reviewing access keys which are scoped and ensuring any users with access to them have appropriate permissions set. Creating automation users with very limited permissions and using access keys for these automation users can be used as a temporary workaround where upgrading is not immediately possible but scoped access keys are needed. |
| The @fastify/express plugin adds full Express compatibility to Fastify. A security vulnerability exists in @fastify/express prior to version 4.0.3 where middleware registered with a specific path prefix can be bypassed using URL-encoded characters (e.g., `/%61dmin` instead of `/admin`). While the middleware engine fails to match the encoded path and skips execution, the underlying Fastify router correctly decodes the path and matches the route handler, allowing attackers to access protected endpoints without the middleware constraints. The vulnerability is caused by how @fastify/express matches requests against registered middleware paths. This vulnerability is similar to, but differs from, CVE-2026-22031 because this is a different npm module with its own code. Version 4.0.3 of @fastify/express contains a patch fort the issue. |
