CVE Database

filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing 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. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock versions from 3.20.4 resolve the lock path and pass it to SQLite without rejecting a final symbolic link, allowing another local user who can create names in the lock directory to redirect database creation and locking or split mutual exclusion between targets. This issue is fixed in version 4.0.9.

filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can break a stale marker after an attacker frees its own marker following the stale read, an honest contender creates a live successor on the reused inode, and the successor's modification time is not newer than the saved observation, causing the live marker to be removed and two holders to be admitted. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock can open a crafted SQLite lock database without bounding schema and query work, allowing another local user who can replace the database to make acquisition stall or hang; versions from 3.20.4 expose this on initial per-instance opening, and versions from 3.30.0 repeat the exposure on every acquisition. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock can restore a stale marker by name after moving it aside, allowing another local user with rename access in a non-sticky lock directory to 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. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. Prior to 4.2.1, UnixFileLock can truncate a regular file renamed onto the lock path when another local user has actual rename permission, or hard-linked there under a permissive hard-link policy; when an explicit mode is requested, affected versions from 3.10.2 can also change that file's mode. This issue is fixed in version 4.2.1.

filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock versions from 4.1.0 can reuse a stale observation when an attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, coarse or matching modification times preserve the observation, and an honest contender creates a fresh marker on the reused inode, causing that live marker to be removed as stale. This issue is fixed in version 4.2.1.

Missing Authorization vulnerability in Castos Seriously Simple Podcasting seriously-simple-podcasting allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Seriously Simple Podcasting: from n/a through 3.17.0.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Castos Seriously Simple Podcasting seriously-simple-podcasting allows Stored XSS.This issue affects Seriously Simple Podcasting: from n/a through 3.17.0.

A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, RestHandler.parseRequestBody in `transport/rest/src/main/java/org/a2aproject/sdk/transport/rest/handler/RestHandler.java` logs the entire JSON request body at SEVERE level when JsonFormat.parser().merge() throws InvalidProtocolBufferException. With push notifications enabled, createTaskPushNotificationConfiguration reaches this parser for requests to `/v1/tenants/{tenant}/tasks/{taskId}/pushNotificationConfigs`, whose token and authentication.credentials fields can contain bearer tokens and authentication credentials for client push endpoints. A valid JSON body that fails protobuf deserialization, including an unknown field under strict parsing or a schema mismatch, causes those secrets to be written to the server logs in cleartext. An attacker with access to the server logs or a log aggregation system can retrieve the credentials and potentially use the credentials to send forged task status updates to the client's push notification endpoint. This issue is fixed in version 1.3.0.Final.

A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, BasePushNotificationSender in server-common sends task data to the URL in TaskPushNotificationConfig without destination validation, scheme restrictions, or bounds on redirects. InMemoryPushNotificationConfigStore.setInfo stores the URL verbatim, and onCreateTaskPushNotificationConfig does not validate the destination. In the default deployment with push notifications enabled, an unauthenticated caller can register a destination through an inline SendMessage configuration or CreateTaskPushNotificationConfig for an existing task, causing task status and artifact updates to send requests from the server's network position to loopback, private, link-local cloud-metadata, IPv6 unique-local, unspecified, or multicast destinations where routing permits. JdkA2AHttpClient and VertxA2AHttpClient follow redirects, allowing a webhook redirect to bypass creation-time destination checks and convert a POST into a GET; hostname-only checks also do not prevent DNS rebinding. Direct POST delivery can push attacker-influenced task data into internal services, whereas a redirected POST-to-GET request drops the body. The sender discards the fetched response and does not expose delivery success or failure, so the demonstrated behavior does not provide response read-back. No credentials or user interaction are required. This issue is fixed in version 1.3.0.Final.

A HID report descriptor is a sequence of items, each declaring in its header how many data bytes follow. The USBX host walks that sequence by advancing over each header and parsing the data behind it. The walk checked that an item fitted in the descriptor only **after** it had advanced past the header and parsed the payload, and the item analysis it relied on never measured the declared sizes against the bytes actually received. A HID peripheral returning a short report descriptor therefore drove a heap out-of-bounds read during ordinary enumeration.

A VideoStreaming interface reports the size of its whole class-specific descriptor block in the `wTotalLength` field of its input header. The USBX host recorded that figure and used it as the budget for walking the format, frame and frame-interval descriptors, without holding it against the configuration descriptor actually received. A device that reports a `wTotalLength` larger than the descriptors it supplies therefore had its own claim believed. Once the real bytes ran out the walk kept going, dereferencing the cursor past the end of the configuration buffer, in the host's context, whenever the application queried format or frame data.

A vulnerability was determined in DrayTek Vigor2960 1.5.1.6 Revision 8218. This issue affects some unknown processing of the file /cgi-bin/mainfunction.cgi of the component commonupload. Executing a manipulation of the argument upload_path/upload_name can lead to unrestricted upload. The attack may be performed from remote. The exploit has been publicly disclosed and may be utilized. Upgrading to version 1.5.1.7 is capable of addressing this issue. It is advisable to upgrade the affected component. The vendor explains: "2960 1.5.1.7 has corrected many security issues. And 2960 is EoS with limited support, only major issues would be reviewed(e.g. unauthenticated vuln.)". This vulnerability only affects products that are no longer supported by the maintainer.

Denial-of-service in the PDF Viewer component. This vulnerability was fixed in Firefox 158.0.1 and Thunderbird 158.0.1.

Mozilla blocked compromised intermediate eMudhra certificates via OneCRL on the 17th of October which was distributed to clients via RemoteSettings the same day. This update contains the updated OneCRL block list, ensuring clients will block the compromised certificates even if RemoteSettings is disabled by policy or otherwise unavailable in the user's network environment. This vulnerability was fixed in Firefox 158.0.1, Firefox ESR 153.5.1, Firefox ESR 115.43.1, Thunderbird 158.0.1, and Thunderbird 153.5.1.

Uninitialized memory in the Audio/Video: cubeb component. This vulnerability was fixed in Firefox 158.0.1 and Thunderbird 158.0.1.

Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Ticimax Informatics Technologies Inc. Ticimax E-Commerce Platform allows Reflected XSS. This issue affects Ticimax E-Commerce Platform: through 2026-09-02.

Cypht webmail 2.0.0 through 2.12.2 contains a DOM-based cross-site scripting vulnerability that allows remote attackers to execute arbitrary JavaScript by crafting malicious alt text or URL values in an HTML email's external image tag when ALLOW_EXTERNAL_IMAGE_SOURCES is enabled. Attackers can send a specially crafted email so that when the victim opens it, the externalResources.js code builds the blocked-image notice using innerHTML with decoded email-derived values, triggering script execution in the victim's authenticated session to read mailboxes, send email, or change settings.

A flaw was found in cockpit-machines. When saving Virtual Network Computing (VNC) console settings, the configured password is passed directly as a command-line argument to an underlying system utility. A local unprivileged attacker on a host that allows cross-user process inspection could read the exposed password from the process list while another user modifies settings. This credential disclosure can allow unauthorized access to the guest virtual machine's graphical console.

A flaw was found in cockpit-machines. Red Hat Subscription Management (RHSM) authentication tokens are passed as command-line arguments to background helper processes during image retrieval operations. A local, unprivileged attacker on a system permitting cross-user process inspection can view these arguments while the process is active. This flaw can lead to information disclosure, potentially allowing unauthorized access to RHSM resources within the token's validity period.

A security flaw has been discovered in opensource-socialnetwork up to 9.11/10.1. This affects the function input of the file actions/administrator/cache/dynamic.php of the component Cache Settings. Performing a manipulation of the argument host/port/username/password/type/status results in code injection. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. The patch is named 40945057cb451f0f35153110bc7e889c094400e1. Applying a patch is the recommended action to fix this issue. The vendor explains: "While we have implemented this patch as a defense-in-depth measure, we emphasize that in Open Source Social Network (OSSN), site administrators are fully trusted users who are intentionally granted broad system authority by design including the native ability to upload custom components/themes containing arbitrary PHP code."