pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can persist package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml. Before the patch, direct pnpm execution trusted an already resolved packageManagerDependencies entry when the committed env lockfile contained matching pnpm and @pnpm/exe versions. A malicious repository could therefore commit package-manager lockfile package records and snapshots that bypassed fresh package-manager resolution, then cause pnpm to install and execute bytes selected by that committed lockfile state during automatic version switching. This vulnerability is fixed in 10.34.2 and 11.5.3.

CubeCart is an ecommerce software solution. Prior to 6.7.2, CubeCart 6.6.x – 6.7.1 builds CC_STORE_URL directly from the Host request header at bootstrap, with no allowlist. The constant is embedded verbatim into transactional email links, most critically the password-reset link in User::passwordRequest() (and the admin equivalent in Admin::passwordRequest()). An unauthenticated attacker who knows a target email can POST /index.php?_a=recover with Host: evil.com; CubeCart writes a fresh verify token (valid 3,600 s) and emails the victim a link http://evil.com/index.php?_a=recovery&validate=<TOKEN>. The token is valid against the legitimate store — capturing the victim's click on evil.com yields full account takeover, or store takeover when an admin email is targeted. This vulnerability is fixed in 6.7.2.

In Eclipse Theia versions 0.3.9 through 0.15.0, one of the default pre-packaged Theia extensions is "Mini-Browser", published as "@theia/mini-browser" on npmjs.com. This extension, for its own needs, exposes a HTTP endpoint that allows to read the content of files on the host's filesystem, given their path, without restrictions on the requester's origin. This design is vulnerable to being exploited remotely through a DNS rebinding attack or a drive-by download of a carefully crafted exploit.

A cache poisoning vulnerability has been found in the Pingora HTTP proxy framework’s default cache key construction. The issue occurs because the default HTTP cache key implementation generates cache keys using only the URI path, excluding critical factors such as the host header (authority). Operators relying on the default are vulnerable to cache poisoning, and cross-origin responses may be improperly served to users. Impact This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for: * Cross-tenant data leakage: In multi-tenant deployments, poison the cache so that users from one tenant receive cached responses from another tenant * Cache poisoning attacks: Serve malicious content to legitimate users by poisoning shared cache entries Cloudflare's CDN infrastructure was not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default. Mitigation: We strongly recommend Pingora users to upgrade to Pingora v0.8.0 or higher, which removes the insecure default cache key implementation. Users must now explicitly implement their own callback that includes appropriate factors such as Host header, origin server HTTP scheme, and other attributes their cache should vary on. Pingora users on previous versions may also remove any of their default CacheKey usage and implement their own that should at minimum include the host header / authority and upstream peer’s HTTP scheme.

In ORY Fosite (the security first OAuth2 & OpenID Connect framework for Go) before version 0.31.0, when using "private_key_jwt" authentication the uniqueness of the `jti` value is not checked. When using client authentication method "private_key_jwt", OpenId specification says the following about assertion `jti`: "A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties". Hydra does not seem to check the uniqueness of this `jti` value. This problem is fixed in version 0.31.0.

PuTTY through 0.75 proceeds with establishing an SSH session even if it has never sent a substantive authentication response. This makes it easier for an attacker-controlled SSH server to present a later spoofed authentication prompt (that the attacker can use to capture credential data, and use that data for purposes that are undesired by the client user).