CVE Vulnerability Catalog

In MinIO up to RELEASE.2025-10-15T17-29-55Z, the globalDeploymentID/SessionTokenAuthenticate function in cmd/common-main.go of the Embedded Console component uses a hard-coded cryptographic key. The attack can be launched remotely and the exploit has been publicly disclosed.

In Nerimity Desktop up to 2.2.2, the shell.openExternal function in src/mainWindow.js of the Window Open Handler component improperly authorizes handling of custom URL schemes. Manipulating the url argument allows the attack to be executed remotely, and the exploit has been made public.

launch-editor before 2.14.2 does not force a file path to be interpreted as a positional filename. If an attacker creates a file starting with a plus or minus in the working directory, the selected editor (Vim, gVim, MacVim, Emacs, Emacsclient, Notepad++ with a plugin) treats the attacker-controlled filename as a command-line flag, potentially causing unintended file overwrite or arbitrary command execution.

launch-editor before 2.14.2 did not escape % on Windows when passing an argument to cmd. If an environment variable contained a malicious value, that content could be executed.

In filelock from 3.22.0 until 4.2.1, SoftFileLock trusted a forged process identifier in a marker that an attacker could modify but not remove. This allowed an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder.

In filelock from 4.1.0 until 4.2.1, ReadWriteLock could remove a randomized .filelock-* private-hard-link directory during cleanup. Another local user with rename access in a non-sticky parent could observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion.

In filelock from 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock resolved the lock path and passed it to SQLite without rejecting a final symbolic link. Another local user who can create names in the lock directory could redirect database creation and locking or split mutual exclusion between targets.

In filelock from 3.22.0 until 4.2.1, SoftFileLock could break a stale marker after an attacker freed its own marker following the stale read, an honest contender created a live successor on the reused inode, and the successor's modification time was not newer than the saved observation, causing the live marker to be removed and two holders to be admitted.

In filelock from 4.0.0 until 4.2.1, SoftReadWriteLock refreshed holder records by name. Another local user with rename access to the lock directory could replace a record with a named pipe and stall the lock, or under a permissive hard-link policy link a reachable target file and cause the lock user to write through it.

In filelock from 3.20.4 until 4.2.1, ReadWriteLock could open a crafted SQLite lock database without bounding schema and query work. Another local user who can replace the database could make acquisition stall or hang.

In filelock from 4.1.0 until 4.2.1, SoftFileLock could restore a stale marker by name after moving it aside. Another local user with rename access in a non-sticky lock directory could swap in a symbolic link and, on a runtime that follows the link and a same-filesystem target, make the lock user hard-link one of its files into the lock directory.

In filelock from 3.30.0 until 4.2.1, StrictSoftFileLock (from 3.30.0) and SoftReadWriteLock (from 4.0.0) could adopt a protocol directory created first by another local user in a shared parent directory. This allowed that user to alter protocol state and admit concurrent holders.

filelock before 4.2.1 has a vulnerability in UnixFileLock that can truncate a regular file renamed onto the lock path when another local user has rename permission or hard-linked there under a permissive policy. When an explicit mode is requested, versions from 3.10.2 can also change that file's mode.

filelock from 4.1.0 to 4.2.1 has a vulnerability in SoftFileLock that can reuse a stale observation when an attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, and coarse or matching modification times preserve the observation. This can cause a live marker to be removed as stale.

The Seriously Simple Podcasting WordPress plugin through 3.17.0 contains a missing authorization vulnerability that allows exploitation of incorrectly configured access control security levels.

The Seriously Simple Podcasting WordPress plugin through 3.17.0 contains a stored Cross-site Scripting (XSS) vulnerability due to improper neutralization of input during web page generation.

A2A Java SDK before 1.3.0.Final has a vulnerability in RestHandler.parseRequestBody that logs the entire JSON request body at SEVERE level when protobuf parsing fails. With push notifications enabled, this can expose tokens and authentication credentials in server logs.

A2A Java SDK before 1.3.0.Final has a vulnerability in BasePushNotificationSender that sends task data to a URL without destination validation, scheme restrictions, or redirect limits. An unauthenticated attacker can register an arbitrary destination, causing the server to send requests to internal or local resources.

The USBX host stack has a vulnerability where HID report descriptor parsing checks item size only after advancing past the header and parsing the payload, and does not compare declared sizes against actual received bytes. A HID peripheral returning a short report descriptor causes a heap out-of-bounds read during ordinary enumeration.

The USBX host stack has a vulnerability in the VideoStreaming interface where the wTotalLength field is used as a budget for walking descriptors without validating against the actual received configuration descriptor size. A device reporting a larger wTotalLength than supplied descriptors causes an out-of-bounds read of the configuration buffer.