| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Zed, a code editor, has an extension installer allows tar/gzip downloads. Prior to version 0.224.4, the tar extractor (`async_tar::Archive::unpack`) creates symlinks from the archive without validation, and the path guard (`writeable_path_from_extension`) only performs lexical prefix checks without resolving symlinks. An attacker can ship a tar that first creates a symlink inside the extension workdir pointing outside (e.g., `escape -> /`), then writes files through the symlink, causing writes to arbitrary host paths. This escapes the extension sandbox and enables code execution. Version 0.224.4 patches the issue. |
| Audiobookshelf is a self-hosted audiobook and podcast server. A cross-site scripting (XSS) vulnerability exists in versions prior to 0.12.0-beta of the Audiobookshelf mobile application that allows arbitrary JavaScript execution through malicious library metadata. Attackers with library modification privileges (or control over a malicious podcast RSS feed) can execute code in victim users' WebViews, potentially leading to session hijacking, data exfiltration, and unauthorized access to native device APIs. audiobookshelf-app version 0.12.0-beta fixes the issue. |
| Audiobookshelf is a self-hosted audiobook and podcast server. A stored cross-site scripting (XSS) vulnerability exists in versions prior to 0.12.0-beta of the Audiobookshelf mobile application that allows arbitrary JavaScript execution through malicious library metadata. Attackers with library modification privileges can execute code in victim users' browsers/WebViews, potentially leading to session hijacking, data exfiltration, and unauthorized access to native device APIs. The issue is fixed in audiobookshelf-app version 0.12.0-beta, corresponding to audiobookshelf version 2.12.0. |
| Vitess is a database clustering system for horizontal scaling of MySQL. Prior to versions 23.0.3 and 22.0.4, anyone with read/write access to the backup storage location (e.g. an S3 bucket) can manipulate backup manifest files so that files in the manifest — which may be files that they have also added to the manifest and backup contents — are written to any accessible location on restore. This is a common path traversal security issue. This can be used to provide that attacker with unintended/unauthorized access to the production deployment environment — allowing them to access information available in that environment as well as run any additional arbitrary commands there. Versions 23.0.3 and 22.0.4 contain a patch. No known workarounds are available. |
| Packistry is a self-hosted Composer repository designed to handle PHP package distribution. Prior to version 0.13.0, RepositoryAwareController::authorize() verified token presence and ability, but did not enforce token expiration. As a result, an expired deploy token with the correct ability could still access repository endpoints (e.g., Composer metadata/download APIs). The fix in version 0.13.0 adds an explicit expiration check, and tests now test expired deploy tokens to ensure they are rejected. |
| Live Helper Chat is an open-source application that enables live support websites. In versions up to and including 4.52, three chat action endpoints (holdaction.php, blockuser.php, and transferchat.php) load chat objects by ID without calling `erLhcoreClassChat::hasAccessToRead()`, allowing operators to act on chats in departments they are not assigned to. Operators with the relevant role permissions (holduse, allowblockusers, allowtransfer) can hold, block users from, or transfer chats in departments they are not assigned to. This is a horizontal privilege escalation within one organization. As of time of publication, no known patched versions are available. |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to version 3.23.0, the fix for the heap-use-after-free described in CVE-2026-24680 is incomplete. While the vulnerable execution flow referenced in the advisory exists in the SDL2 implementation, the fix appears to have been applied only to the SDL3 code path. In the SDL2 implementation, the pointer is not nulled after free. This creates a situation where the advisory suggests the vulnerability is fully resolved, while builds or environments still using SDL2 may retain the vulnerable logic. A complete fix is available in version 3.23.0. |
| ZITADEL is an open source identity management platform. Prior to versions 4.11.1 and 3.4.7, a vulnerability in Zitadel's self-management capability allowed users to mark their email and phone as verified without going through an actual verification process. The patch in versions 4.11.1 and 3.4.7 resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address and/or phone number itself. If an upgrade is not possible, an action (v2) could be used to prevent setting the verification flag on the own user. |
| WPGraphQL provides a GraphQL API for WordPress sites. Prior to version 2.9.1, the `wp-graphql/wp-graphql` repository contains a GitHub Actions workflow (`release.yml`) vulnerable to OS command injection through direct use of `${{ github.event.pull_request.body }}` inside a `run:` shell block. When a pull request from `develop` to `master` is merged, the PR body is injected verbatim into a shell command, allowing arbitrary command execution on the Actions runner. Version 2.9.1 contains a fix for the vulnerability. |
| Spin is an open source developer tool for building and running serverless applications powered by WebAssembly. When Spin is configured to allow connections to a database or web server which could return responses of unbounded size (e.g. tables with many rows or large content bodies), Spin may in some cases attempt to buffer the entire response before delivering it to the guest, which can lead to the host process running out of memory, panicking, and crashing. In addition, a malicious guest application could incrementally insert a large number of rows or values into a database and then retrieve them all in a single query, leading to large host allocations. Spin 3.6.1, SpinKube 0.6.2, and `containerd-shim-spin` 0.22.1 have been patched to address the issue. As a workaround, configure Spin to only allow access to trusted databases and HTTP servers which limit response sizes. |
| ZITADEL is an open source identity management platform. Starting in version 2.31.0 and prior to versions 3.4.7 and 4.11.0, opaque OIDC access tokens in the v2 format truncated to 80 characters are still considered valid. Zitadel uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade. The cleartext payload has a format of `<token_id>:<user_id>`. v2 tokens distinguished further where the `token_id` is of the format `v2_<oidc_session_id>-at_<access_token_id>`. V1 token authZ/N session data is retrieved from the database using the (simple) `token_id` value and `user_id` value. The `user_id` (called `subject` in some parts of our code) was used as being the trusted user ID. V2 token authZ/N session data is retrieved from the database using the `oidc_session_id` and `access_token_id` and in this case the `user_id` from the token is ignored and taken from the session data in the database. By truncating the token to 80 chars, the user_id is now missing from the cleartext of the v2 token. The back-end still accepts this for above reasons. This issue is not considered exploitable, but may look awkward when reproduced. The patch in versions 4.11.0 and 3.4.7 resolves the issue by verifying the `user_id` from the token against the session data from the database. No known workarounds are available. |
| Dottie provides nested object access and manipulation in JavaScript. Versions 2.0.4 through 2.0.6 contain an incomplete fix for CVE-2023-26132. The prototype pollution guard introduced in commit `7d3aee1` only validates the first segment of a dot-separated path, allowing an attacker to bypass the protection by placing `__proto__` at any position other than the first. Both `dottie.set()` and `dottie.transform()` are affected. Version 2.0.7 contains an updated fix to address the residual vulnerability. |
| c3p0, a JDBC Connection pooling library, is vulnerable to attack via maliciously crafted Java-serialized objects and `javax.naming.Reference` instances. Several c3p0 `ConnectionPoolDataSource` implementations have a property called `userOverridesAsString` which conceptually represents a `Map<String,Map<String,String>>`. Prior to v0.12.0, that property was maintained as a hex-encoded serialized object. Any attacker able to reset this property, on an existing `ConnectionPoolDataSource` or via maliciously crafted serialized objects or `javax.naming.Reference` instances could be tailored execute unexpected code on the application's `CLASSPATH`. The danger of this vulnerability was strongly magnified by vulnerabilities in c3p0's main dependency, mchange-commons-java. This library includes code that mirrors early implementations of JNDI functionality, including ungated support for remote `factoryClassLocation` values. Attackers could set c3p0's `userOverridesAsString` hex-encoded serialized objects that include objects "indirectly serialized" via JNDI references. Deserialization of those objects and dereferencing of the embedded `javax.naming.Reference` objects could provoke download and execution of malicious code from a remote `factoryClassLocation`. Although hazard presented by c3p0's vulnerabilites are exarcerbated by vulnerabilities in mchange-commons-java, use of Java-serialized-object hex as the format for a writable Java-Bean property, of objects that may be exposed across JNDI interfaces, represents a serious independent fragility. The `userOverridesAsString` property of c3p0 `ConnectionPoolDataSource` classes has been reimplemented to use a safe CSV-based format, rather than rely upon potentially dangerous Java object deserialization. c3p0-0.12.0+ and above depend upon mchange-commons-java 0.4.0+, which gates support for remote `factoryClassLocation` values by configuration parameters that default to restrictive values. c3p0 additionally enforces the new mchange-commons-java `com.mchange.v2.naming.nameGuardClassName` to prevent injection of unexpected, potentially remote JNDI names. There is no supported workaround for versions of c3p0 prior to 0.12.0. |
| LangChain is a framework for building LLM-powered applications. Prior to version 1.1.8, a redirect-based Server-Side Request Forgery (SSRF) bypass exists in `RecursiveUrlLoader` in `@langchain/community`. The loader validates the initial URL but allows the underlying fetch to follow redirects automatically, which permits a transition from a safe public URL to an internal or metadata endpoint without revalidation. This is a bypass of the SSRF protections introduced in 1.1.14 (CVE-2026-26019). Users should upgrade to `@langchain/community` 1.1.18, which validates every redirect hop by disabling automatic redirects and re-validating `Location` targets before following them. In this version, automatic redirects are disabled (`redirect: "manual"`), each 3xx `Location` is resolved and validated with `validateSafeUrl()` before the next request, and a maximum redirect limit prevents infinite loops. |
| LangGraph Checkpoint defines the base interface for LangGraph checkpointers. Prior to version 4.0.0, a Remote Code Execution vulnerability exists in LangGraph's caching layer when applications enable cache backends that inherit from `BaseCache` and opt nodes into caching via `CachePolicy`. Prior to `langgraph-checkpoint` 4.0.0, `BaseCache` defaults to `JsonPlusSerializer(pickle_fallback=True)`. When msgpack serialization fails, cached values can be deserialized via `pickle.loads(...)`. Caching is not enabled by default. Applications are affected only when the application explicitly enables a cache backend (for example by passing `cache=...` to `StateGraph.compile(...)` or otherwise configuring a `BaseCache` implementation), one or more nodes opt into caching via `CachePolicy`, and the attacker can write to the cache backend (for example a network-accessible Redis instance with weak/no auth, shared cache infrastructure reachable by other tenants/services, or a writable SQLite cache file). An attacker must be able to write attacker-controlled bytes into the cache backend such that the LangGraph process later reads and deserializes them. This typically requires write access to a networked cache (for example a network-accessible Redis instance with weak/no auth or shared cache infrastructure reachable by other tenants/services) or write access to local cache storage (for example a writable SQLite cache file via permissive file permissions or a shared writable volume). Because exploitation requires write access to the cache storage layer, this is a post-compromise / post-access escalation vector. LangGraph Checkpoint 4.0.0 patches the issue. |
| The Angular SSR is a server-rise rendering tool for Angular applications. Versions prior to 21.2.0-rc.1, 21.1.5, 20.3.17, and 19.2.21 have a Server-Side Request Forgery (SSRF) vulnerability in the Angular SSR request handling pipeline. The vulnerability exists because Angular’s internal URL reconstruction logic directly trusts and consumes user-controlled HTTP headers specifically the Host and `X-Forwarded-*` family to determine the application's base origin without any validation of the destination domain. Specifically, the framework didn't have checks for the host domain, path and character sanitization, and port validation. This vulnerability manifests in two primary ways: implicit relative URL resolution and explicit manual construction. When successfully exploited, this vulnerability allows for arbitrary internal request steering. This can lead to credential exfiltration, internal network probing, and a confidentiality breach. In order to be vulnerable, the victim application must use Angular SSR (Server-Side Rendering), the application must perform `HttpClient` requests using relative URLs OR manually construct URLs using the unvalidated `Host` / `X-Forwarded-*` headers using the `REQUEST` object, the application server must be reachable by an attacker who can influence these headers without strict validation from a front-facing proxy, and the infrastructure (Cloud, CDN, or Load Balancer) must not sanitize or validate incoming headers. Versions 21.2.0-rc.1, 21.1.5, 20.3.17, and 19.2.21 contain a patch. Some workarounds are available. Avoid using `req.headers` for URL construction. Instead, use trusted variables for base API paths. Those who cannot upgrade immediately should implement a middleware in their `server.ts` to enforce numeric ports and validated hostnames. |
| mchange-commons-java, a library that provides Java utilities, includes code that mirrors early implementations of JNDI functionality, including support for remote `factoryClassLocation` values, by which code can be downloaded and invoked within a running application. If an attacker can provoke an application to read a maliciously crafted `jaxax.naming.Reference` or serialized object, they can provoke the download and execution of malicious code. Implementations of this functionality within the JDK were disabled by default behind a System property that defaults to `false`, `com.sun.jndi.ldap.object.trustURLCodebase`. However, since mchange-commons-java includes an independent implementation of JNDI derefencing, libraries (such as c3p0) that resolve references via that implementation could be provoked to download and execute malicious code even after the JDK was hardened. Mirroring the JDK patch, mchange-commons-java's JNDI functionality is gated by configuration parameters that default to restrictive values starting in version 0.4.0. No known workarounds are available. Versions prior to 0.4.0 should be avoided on application CLASSPATHs. |
| NanaZip is an open source file archive. Starting in version 5.0.1252.0 and prior to versions 6.0.1638.0 and 6.5.1638.0, NanaZip’s `.NET Single File Application` parser has an out-of-bounds read vulnerability in manifest parsing. A crafted bundle can provide a malformed `RelativePathLength` so the parser constructs a `std::string` from memory beyond `HeaderBuffer`, leading to crash and potential in-process memory disclosure. Versions 6.0.1638.0 and 6.5.1638.0 fix the issue. |
| Plane is an an open-source project management tool. Prior to version 1.2.2, a Full Read Server-Side Request Forgery (SSRF) vulnerability has been identified in the "Add Link" feature. This flaw allows an authenticated attacker with general user privileges to send arbitrary GET requests to the internal network and exfiltrate the full response body. By exploiting this vulnerability, an attacker can steal sensitive data from internal services and cloud metadata endpoints. Version 1.2.2 fixes the issue. |
| Plane is an an open-source project management tool. Prior to version 1.2.2, the `ProjectAssetEndpoint.patch()` method in `apps/api/plane/app/views/asset/v2.py` (lines 579–593) performs a global asset lookup using only the asset ID (`pk`) via `FileAsset.objects.get(id=pk)`, without verifying that the asset belongs to the workspace and project specified in the URL path. This allows any authenticated user (including those with the GUEST role) to modify the `attributes` and `is_uploaded` status of assets belonging to any workspace or project in the entire Plane instance by guessing or enumerating asset UUIDs. Version 1.2.2 fixes the issue. |
