CVE Vulnerability Catalog

pnpm prior to versions 10.34.2 and 11.5.3 allows installation of configDependencies declared in pnpm-workspace.yaml before command dispatch. A repository can declare pacquet or @pnpm/pacquet as a config dependency, and pnpm treats this repository-controlled dependency as an install-engine opt-in. During installation, pnpm resolves a platform-specific @pacquet/<platform>-<arch>/pacquet binary from node_modules/.pnpm-config/<packageName> and spawns it as the developer or CI user.

In pnpm prior to versions 10.34.2 and 11.5.3, the generic peer-suffix normalizer incorrectly stripped parenthesized text from git, URL, tarball, file, and other opaque locators. Approval for one source string could authorize a different attacker-controlled source whose locator normalized to the same value.

A vulnerability in pnpm package manager prior to versions 10.34.2 and 11.5.3 expands ${ENV_VAR} placeholders from repository-controlled .npmrc and pnpm-workspace.yaml files into registry request destinations and credentials. A malicious repository can send victim environment secrets to an attacker-selected registry before lifecycle scripts run.

In jq prior to version 1.8.2, on 32-bit systems, the jvp_string_append function may experience integer overflow, leading to a massive buffer overrun.

In pnpm before versions 10.34.0 and 11.4.0, `pnpm install` in non-frozen mode can accept new remote package content after detecting an integrity mismatch with pnpm-lock.yaml. Even though the package is locked with an integrity value and the registry returns different data, pnpm performs a resolution repair, updates the lockfile, and installs the new content, exiting successfully.

In pnpm before versions 10.34.0 and 11.4.0, the tarball extraction worker skips integrity verification when the integrity field is missing from pnpm-lock.yaml. An attacker can remove this field and serve altered package content, allowing installation of modified packages without integrity errors.

pnpm before versions 10.34.0 and 11.4.0 can send user-level unscoped npm authentication credentials to a registry chosen by a repository-local .npmrc file. In the reproduced case, the user's npm config contains a default registry and an unscoped _authToken, while the repository only sets registry= to a different registry URL. During normal pnpm workflows, the user's credentials are bound to the repository-selected registry and sent as an Authorization header.

pnpm before versions 10.34.0 and 11.4.0 allows a transitive dependency alias from registry package metadata to contain path traversal segments. During install, pnpm uses that alias as a filesystem path when linking dependency nodes, enabling an attacker to replace paths in the current project with symlinks to attacker-controlled directories.

A vulnerability in pnpm package manager prior to versions 10.34.0 and 11.4.0 allows an attacker to write or delete arbitrary files on the filesystem during pnpm install. The issue stems from missing path validation in .patch files, enabling the use of ../ sequences to escape the package directory.

A vulnerability in pnpm package manager before versions 10.34.0 and 11.4.0 allows an attacker to inject Git options into the git fetch command via a malicious lockfile. Lack of validation of the commit value in the lockfile enables substitution of the --upload-pack option, which for SSH and local transports can lead to arbitrary command execution.

In jq prior to 1.8.2, using `--rawfile` with an attacker-controlled file can cause a heap out-of-bounds write in builds without assertions. The bug is due to the loop not stopping after a 'String too long' error, leading to operations on an invalid object.

A vulnerability in pnpm package manager prior to versions 10.33.4 and 11.0.7 allows a malicious codeload.github.com server to serve arbitrary tarballs, which pnpm will install regardless of the lockfile. The lockfile does not store hashes for dependencies from this server, enabling package substitution.

The vulnerability in jq (versions prior to 1.8.2) allows a DoS attack via C stack exhaustion when comparing deeply nested arrays with the == operator. The issue stems from missing recursion guards in jvp_array_equal() and jv_equal() functions in src/jv.c.

The vulnerability allows bypassing X.509 trust-chain validation in the wolfSSL_X509_verify_cert() function of wolfSSL compiled with --enable-opensslextra. When the application supplies untrusted intermediate certificates and the chain exceeds the maximum allowed depth (default 100), the validator accepts an attacker-controlled certificate without reaching a trusted anchor.

A flaw in Keycloak Policy Enforcer allows any authenticated user to bypass all authorization policies, including role, scope, and UMA permission checks. By including the configured access-denied page path within a request URL, as a path segment or query parameter, an attacker can gain unauthorized access to protected resources.

A flaw was found in the Keycloak authorization component. An authenticated user with a UMA permission ticket for one resource can bypass per-resource access control for all resources of the same type on the resource server by using a specific permission request prefix. This vulnerability requires PERMISSIVE policy enforcement mode and ownerManagedAccess enabled for typed resources without explicit policies.

A flaw in Keycloak's client registration service allows a remote attacker with a previously issued Registration Access Token (RAT) to re-enable a client disabled by an administrator. The attacker can reset the client secret and potentially regain privileged API access.

A missing authorization check in the Keycloak GroupResource.addChild() endpoint allows an authenticated user with limited admin privileges to reparent any group. With FGAPv2 enabled, an attacker can move a high-privilege group under their control.

A flaw was found in Keycloak allowing a remote attacker with administrative privileges (specifically those with `manage-client` permission or access to client registration endpoints) to bypass client URI validation. The attacker can register a malicious client with a crafted redirect URI using case-insensitive `javascript:` or `data:` schemes, leading to a Cross-Site Scripting (XSS) vulnerability.

A flaw was found in Keycloak where a realm administrator with the 'manage-realm' role can submit an arbitrary filesystem path as a keystore parameter when creating a key provider component. This allows probing of arbitrary filesystem paths to determine which files exist and are readable by the Keycloak process.