ghsa

### Summary On historic but declared as supported Node.js versions (0.12-2.x), pbkdf2 silently disregards Uint8Array input This only affects Node.js <3.0.0, but `pbkdf2` claims to: * Support Node.js [>= 0.12](https://github.com/browserify/pbkdf2/blob/v3.1.2/package.json#L62) (and there seems to be ongoing effort in this repo to maintain that) * Support `Uint8Array` input (input is typechecked against Uint8Array, and the error message includes e.g. "Password must be a string, a Buffer, a typed array or a DataView" ### Details The error is in `toBuffer` method This vulnerability somehow even made it to tests: https://github.com/browserify/pbkdf2/commit/eb9f97a66ed83836bebc4ff563a1588248708501 There, `resultsOld` (where mismatch `results`) are just invalid output generated from empty password/salt instead of the supplied one ### PoC On Node.js/io.js < 3.0.0 ```console > require('pbkdf2').pbkdf2Sync(new Uint8Array([1,2,3]), new Uint8Array([1,3,4]), 1024, 32, 'sha256') <Buffer 21 ...

### Summary This affects both: 1. Unsupported algos (e.g. `sha3-256` / `sha3-512` / `sha512-256`) 2. Supported but non-normalized algos (e.g. `Sha256` / `Sha512` / `SHA1` / `sha-1` / `sha-256` / `sha-512`) All of those work correctly in Node.js, but this polyfill silently returns highly predictable ouput Under Node.js (only with `pbkdf2/browser` import, unlikely) / Bun (`pbkdf2` top-level import is affected), the memory is not zero-filled but is uninitialized, as `Buffer.allocUnsafe` is used Under browsers, it just returns zero-filled buffers (Which is also critical, those are completely unacceptable as kdf output and ruin security) ### Were you affected? The full list of arguments that were **not** affected were literal: * `'md5'` * `'sha1'` * `'sha224'` * `'sha256'` * `'sha384'` * `'sha512'` * `'rmd160'` * `'ripemd160'` Any other arguments, e.g. representation variations of the above ones like `'SHA-1'`/`'sha-256'`/`'SHA512'` or different algos like `'sha3-512'`/`'b...

A vulnerability was found in PySpur-Dev pyspur up to 0.1.18. It has been classified as critical. Affected is the function SingleLLMCallNode of the file backend/pyspur/nodes/llm/single_llm_call.py of the component Jinja2 Template Handler. The manipulation of the argument user_message leads to improper neutralization of special elements used in a template engine. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.

A Server-Side Request Forgery (SSRF) vulnerability exists in the RequestsToolkit component of the langchain-community package (specifically, langchain_community.agent_toolkits.openapi.toolkit.RequestsToolkit) in langchain-ai/langchain version 0.0.27. This vulnerability occurs because the toolkit does not enforce restrictions on requests to remote internet addresses, allowing it to also access local addresses. As a result, an attacker could exploit this flaw to perform port scans, access local services, retrieve instance metadata from cloud environments (e.g., Azure, AWS), and interact with servers on the local network. This issue has been fixed in version 0.0.28.

### Impact The connection limiter is implemented incorrectly. It allows an arbitrary amount of simultaneously incoming connections (TCP, UDP and Unix socket) for the services `letmeind` and `letmeinfwd`. Therefore, the command line option `num-connections` is not effective and does not limit the number of simultaneously incoming connections. `letmeind` is the public network facing daemon (TCP/UDP). `letmeinfwd` is the internal firewall daemon that only listens on local Unix socket. Possible Denial Of Service by resource exhaustion. ### Affected versions All versions `<= 10.2.0` are affected. ### Patches All users shall upgrade to version `10.2.1`. ### Workarounds Untested possible workarounds: - It might be possible to limit the number of active connections to the `letmeind` port (default 5800) via firewall. - The resource consumption of the service might be restricted with a service manager such as systemd. ### Severity: If a (D)DoS is run against the service, *something* is...

Claude Code extensions in VSCode and forks (e.g., Cursor, Windsurf, and VSCodium) and JetBrains IDEs (e.g., IntelliJ, Pycharm, and Android Studio) are vulnerable to unauthorized websocket connections from an attacker when visiting attacker-controlled webpages. Claude Code for VSCode IDE extensions versions 0.2.116 through 1.0.23 are vulnerable. For Jetbrains IDE plugins, Claude Code [beta] versions 0.1.1 through 0.1.8 are vulnerable. In VSCode (and forks), exploitation would allow an attacker to read arbitrary files, see the list of files open in the IDE, get selection and diagnostics events from the IDE, or execute code in limited situations where a user has an open Jupyter Notebook and accepts a malicious prompt. In JetBrains IDEs, an attacker could get selection events, a list of open files, and a list of syntax errors. **Remediation** We released a patch for this issue on June 13th, 2025. Although Claude Code auto-updates when you launch it and auto-updates the extensions, you...

### Impact XSS - Errors in filters from website page change detection watches were not being filtered. ### Patches 0.50.4

### Impact Vert.x 4.5.12 has changed the semantics of the duplication of duplicated context. Duplicated context is an object used to propagate data through a processing (synchronous or asynchronous). Each "transaction" or "processing" runs on its own isolated duplicated context. Initially, duplicating a duplicated context was creating a fresh (empty) new context, meaning that the new duplicated context can be used to managed a separated transaction. In Vert.x 4.5.12, this semantics has changed, and since the content of the parent duplicated context is copied into the new one, potentially leaking data. This CVE is especially for Quarkus as Quarkus extensively uses the Vert.x duplicated context to implement context propagation. With the new semantic data from one transaction can leak to the data from another transaction. From a Vert.x point of view, this new semantic clarifies the behavior. A significant amount of data is stored in the duplicated context, including request scope,...

A vulnerability exists in the NodeRestriction admission controller where nodes can bypass dynamic resource allocation authorization checks. When the DynamicResourceAllocation feature gate is enabled, the controller properly validates resource claim statuses during pod status updates but fails to perform equivalent validation during pod creation. This allows a compromised node to create mirror pods that access unauthorized dynamic resources, potentially leading to privilege escalation.

gateway_proxy_handler in MLflow before 3.1.0 lacks gateway_path validation.