CVE Vulnerability Catalog

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.

launch-editor-middleware prior to 2.14.2 mishandles an attacker-controlled Windows file argument ending in a parent-directory component plus a line-and-column suffix. The path is resolved with the suffix present, and the suffix is removed before the existsSync check, bypassing filename existence validation. Combined with a separate Windows percent-expansion flaw, this can lead to OS command injection.

In filelock from 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the <path>.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user.

In filelock from 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name. On POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations; a writable adjacent hot journal is additionally required for attacker-chosen content overwrites.

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.32.6 until 4.2.1, SoftFileLock can follow a swapped symbolic link during the conditional os.access writability check for a node without its owner-write bit, allowing another local user on a platform and directory configuration that follows the link to infer whether a chosen path exists and is writable from the observable acquisition result.

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.