The ReadWriteLock and AsyncReadWriteLock classes in poetry versions >=2.3.2_1 and <2.5.1_1 resolve lock file paths following symlinks and open them with sqlite3.connect() without preventing symlink traversal. This allows a local attacker with write access to the lock directory to cause the victim process to create or lock files at attacker-controlled locations, potentially breaking mutual exclusion and corrupting protected resources. The issue affects Linux, macOS, and Windows 11. A fix is available in version 2.5.1_1.
A vulnerability in filelock versions 3.22.0 through 4.2.0 allows a local user with write access to a sticky shared directory (e.g., /tmp) to cause two processes of the lock owner to simultaneously hold the same soft file lock. This occurs due to inode reuse and a race condition in stale-lock breaking logic, which can lead to integrity issues where two holders write protected data without detection.
A vulnerability in filelock versions 4.0.0 through 4.2.0 allows a local user who owns the lock's .rw directory tree to interfere with the lock holder's refresh operations. By replacing the holder record with a FIFO (named pipe), the attacker can cause the lock holder's write or read lock operations to hang indefinitely, preventing heartbeat refreshes and allowing multiple processes to believe they hold the lock simultaneously. Additionally, on systems where the kernel permits hard links to files not owned by the user (e.g., Linux with fs.protected_hardlinks=0), the attacker can cause the lock holder to overwrite the first ~135 bytes of one of its own private files with lock holder data. The vulnerability has a CVSS score of 6.1 (Medium) and affects local users with low privileges but no confidentiality impact.
A vulnerability in filelock's ReadWriteLock and AsyncReadWriteLock components allows a local user who can place or overwrite the lock database file to cause every acquire operation to stall or hang indefinitely, ignoring timeout and blocking settings. This results in a denial of service affecting availability only, with no confidentiality or integrity impact. The issue affects filelock versions 3.20.4 through 4.2.0 and requires the attacker to have write access to the lock file path, typically in a non-sticky shared directory or a writable database owned by the lock user. The vulnerability is rated medium severity with a CVSS score of 5.5 and has been fixed in version 2.5.1_1 of the affected product poetry.
A symlink swap vulnerability in filelock's SoftFileLock writability check allows a local user to leak one bit of information about whether a path exists and is writable by the lock user. This occurs because the check uses os.lstat followed by os.access, which follows symlinks, enabling a time-of-check to time-of-use (TOCTOU) leak. The vulnerability affects filelock versions 3.32.6 through 4.2.0 and requires the attacker to create entries in the lock directory and race the lock user's acquire calls. Linux's fs.protected_symlinks kernel setting mitigates this in sticky world-writable directories like /tmp, but not in others. The impact is limited to a low-severity confidentiality leak of a single bit per acquire attempt. A fix is available in filelock version 2.5.1_1.
A vulnerability in the filelock library versions 3.30.0 through 4.2.0 allows a local unprivileged user to pre-create a protocol directory used by StrictSoftFileLock and SoftReadWriteLock. This causes the lock to adopt a directory owned by the attacker, enabling them to interfere with lock claims, potentially allowing concurrent writers and denial of service conditions. The flaw requires the attacker to create the directory before the lock user's first acquire on that path, typically in shared sticky directories like /tmp. The vulnerability has a medium CVSS score of 6.3 and impacts integrity and availability but not confidentiality. A fix is available in version 2.5.1_1.
UnixFileLock, used by FileLock and AsyncFileLock on Unix systems, truncates and can change permissions of any regular file that another local user renames or hard-links onto the lock path before the lock is acquired. This allows a local attacker with write access to certain directories to cause the lock user to truncate and potentially expose files to unauthorized read/write access. The vulnerability affects all filelock releases up to and including 4.2.0 and requires specific conditions such as writable non-sticky directories or disabled kernel hardlink protections. The CVSS 3.1 score is 6.1 (Medium).
The filelock vulnerability (CVE-2026-112908) affects versions of the poetry package >=2.4.2 and <2.5.1_1. It involves the StrictSoftFileLock and AsyncStrictSoftFileLock classes creating claim directories without applying the intended restrictive mode, resulting in directories that may be writable by other local users under certain umask or ACL configurations. This allows another local user with write access to unlink claim files, causing the lock to be bypassed and potentially allowing concurrent holders to write protected data without detection. The vulnerability has a medium severity with a CVSS score of 5.3 and is fixed in version 2.5.1_1.
PyJWT versions up to 2.13.0 and the current master branch contain a vulnerability where the HMAC verification accepts an empty key when using JWKs with an oct key type and an empty 'k' value. This allows an attacker to forge tokens without knowledge of a secret if the application verifies tokens using such a JWK. The issue arises because the empty key rejection implemented for string/bytes secrets was not applied to the JWK verification path. This flaw is fixed in PyJWT version 0.12.0_5.
The Model Context Protocol (MCP) Python SDK client versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 have a vulnerability where the client fetches server-declared external $ref URLs during tool output schema validation. This can cause the client to synchronously fetch arbitrary HTTP, HTTPS, or file URLs from the client's network position, potentially stalling the client if the target is unresponsive. The issue affects applications using the SDK as a client calling tools on untrusted servers. Fixed in versions 1.30.0 and 2.2.0.
The Model Context Protocol (MCP) Python SDK versions 1.8.0 through 1.29.1 and 2.0.0 through 2.1.1 have a vulnerability where their HTTP client transports follow cross-origin HTTP redirects and send custom headers and, on certain redirects, the request body to the redirected host. This behavior can expose sensitive headers like API keys if an attacker can cause a trusted endpoint to redirect to a malicious or unintended host. The SDK's OAuth client providers are similarly affected. The lone Authorization bearer header is not exposed due to existing HTTP library protections. MCP servers and clients with redirect following disabled are not affected. Fixed in MCP versions 1.30.0 and 2.2.0.
FastMCP versions 3.0.0 through 3.4.9 and 4.0.0 through 4.1.1 contain an authorization vulnerability where direct calls to transformed components skip the final authorization check. This allows low-privilege users to invoke protected tools, resources, templates, or prompts that should be denied by policy. The issue arises because transforms modify component metadata but the authorization check is performed on the original component, not the transformed one. Fixes are available in FastMCP versions 3.4.10 and 4.1.2. Until patched, users should avoid overlapping proxy templates for protected resources and enforce authorization at the handler or server boundary.
Authlib versions prior to 0.23.1_2 contain a critical signature verification bypass vulnerability in the JsonWebSignature.deserialize_json() method. This flaw allows an attacker to submit a JSON Web Signature (JWS) object with an empty signatures array, which is incorrectly accepted as valid without any cryptographic verification. As a result, attacker-crafted payloads can be accepted as authenticated, leading to a complete authentication bypass. The issue is fixed in version 0.23.1_2.
Authlib's RFC 9101 (JAR) extension contains an SSRF vulnerability due to unvalidated use of the attacker-controlled request_uri parameter in a pre-authentication context. The extension forwards the request_uri to a fetch hook without enforcing the existing allowlist or other recommended controls, enabling unauthenticated SSRF. This affects versions from 0.11.11 up to but not including 0.23.1_2. A fix is available in version 0.23.1_2.
Authlib's OpenID Connect implicit grant implementation contains a vulnerability where the raw scope parameter from the client request is checked instead of the filtered allowed scope before issuing ID tokens. This allows a registered OAuth client that is not permitted the 'openid' scope but allowed other scopes like 'profile' to obtain signed ID tokens if the user consents. The issue affects deployments using the OpenID implicit grant and clients permitted 'id_token' response types but excluded from the 'openid' scope. The vulnerability does not affect authorization code flow deployments or setups where clients allowed 'id_token' response types are also allowed the 'openid' scope.
Authlib's default implementation of the RFC 7523 JWT bearer grant does not properly validate the 'aud' (audience) claim in JWT assertions. Instead of verifying that the 'aud' claim matches the authorization server's token endpoint, it only checks for the presence of the claim. This allows an attacker with a valid JWT for one audience to use it to obtain access tokens from a different authorization server sharing the same signing key, effectively bypassing audience restrictions.
Authlib versions prior to 0.23.1_2 contain a vulnerability in the OpenID ID token parsing logic where the nonce validation can be bypassed if the ID token includes a nonce_supported claim set to boolean false. This causes the nonce check to be skipped, allowing replay of a valid signed ID token into an attacker-controlled session, authenticating the attacker as the victim. The issue affects implicit and hybrid flows and direct calls to parse_id_token(), but not the authorization code flow. A fix is available in version 0.23.1_2.
Authlib versions up to 1.7.2 accept an empty HMAC key for JWS/JWT HS256/HS384/HS512 signature verification, allowing attackers to forge tokens that pass signature checks. This occurs because empty keys produce deterministic digests that anyone can reproduce, enabling token forgery and authentication bypass in OAuth 2.0 and OIDC implementations using Authlib. The vulnerability is confirmed in the v1.7.2 release and remains in the current main branch. A fix is available in version 0.23.1_2.