Kq5Y

An unauthenticated denial of service can occur when an attacker submits multipart form-data containing a part header with a name that is a prototype-inherited property, such as ` proto ` or `constructor`. The internal header parser uses a plain JavaScript object to store headers and expects each value to be an array. When a prototype-inherited property is used, it resolves to a non-array value, triggering a TypeError. Depending on the integration, this results in an error event or a synchronous exception that can terminate the Node.js process.

A denial of service occurs when a multipart/form-data request is sent with a field name that collides with an inherited Object.prototype property, such as ` proto `, `constructor`, or `toString`. This causes the parser to invoke the `.push()` function on the inherited prototype value instead of an array, resulting in a TypeError that triggers an uncaught exception and crashes the process. This issue affects any service that accepts multipart uploads via multiparty.

A Regular Expression Denial of Service (ReDoS) exists in the `LINK TITLE RE` regular expression. An attacker can provide specially crafted Markdown for parsing that triggers catastrophic backtracking, leading to exponential O(2^N) time complexity and significant CPU consumption. This occurs because the regular expression used for parsing link titles contains overlapping alternatives in both double-quoted and single-quoted branches; specifically, a backslash followed by punctuation can be matched as either an escaped sequence or as two ordinary characters. This ambiguity is reachable through normal Markdown parsing of inline links via `parse link()` and `parse link title()`, as well as block link reference definitions via `BlockParser.parse ref link()` and `parse link title()`. A small input, such as a document under 100 bytes containing repeated backslash and exclamation mark sequences without a closing quote, can make applications unresponsive.

mise improperly loads trust-control settings from a local project `.mise.toml` file before performing trust checks. This allows an attacker who can place a malicious `.mise.toml` file in a repository to make it appear trusted and then execute dangerous directives such as `[env] .source`, templates, hooks, or tasks. The vulnerability stems from loading local settings files without initially verifying their trustworthiness. Specifically, the `trusted config paths` setting, when set to '/', allows any absolute path to be considered trusted. This bypasses the intended security measures. A related issue allows local `yes = true` or `ci = true` settings to auto-approve trust prompts in versions 2026.2.18 and later, though the primary exploit vector involves the `trusted config paths` setting. A proof-of-concept demonstrates that setting `trusted config paths = ["/"]` in a `.mise.toml` file allows execution of an attacker-controlled script via `mise hook-env`.

Name of the Vulnerable Software and Affected Versions Vite versions 7.1.0 through 7.3.1 and 8.0.0 through 8.0.4 Description Vite, a frontend tooling framework for JavaScript, allows retrieval of files blocked by `server.fs.deny` (such as .env and *.crt files) with HTTP 200 responses when specific query parameters like ?raw, ?import&raw, or ?import&url&inline are appended to the request. This occurs when the Vite dev server is exposed to the network and sensitive files are both allowed by `server.fs.allow` and denied by `server.fs.deny`. Recommendations Vite versions 7.1.0 through 7.3.1 should be updated to version 7.3.2 or later. Vite versions 8.0.0 through 8.0.4 should be updated to version 8.0.5 or later.

Name of the Vulnerable Software and Affected Versions Tinyauth versions prior to 5.0.5 Description Tinyauth is an authentication and authorization server. The GenericOAuthService, GithubOAuthService, and GoogleOAuthService implementations store PKCE verifiers and access tokens as mutable struct fields on singleton instances shared across concurrent requests. A race condition between `VerifyCode()` and `Userinfo()` allows one user to receive a session with another user's identity when two users initiate OAuth login for the same provider concurrently. The `OAuthBrokerService.GetService()` function returns a single shared instance per provider for every request. The OAuth flow stores intermediate state as struct fields on this singleton. Specifically, the `token` and `verifier` fields are shared mutable fields. In the callback handler, the `VerifyCode()` function stores the token on the singleton, and a subsequent call to `GetUser()` reads the token from the singleton. Between these calls, a concurrent request's `VerifyCode()` can overwrite the `token` field, causing `GetUser()` and `Userinfo()` to fetch the incorrect user's identity claims. This issue also causes a denial-of-service due to PKCE verifier overwrites, leading to failed OAuth logins. Recommendations Update Tinyauth to version 5.0.5 or later.

A crafted `.idx` file can cause asymmetric memory consumption, potentially exhausting available memory and resulting in a denial-of-service (DoS) condition. Exploitation requires write access to the local repository's `.git` directory to create or alter existing `.idx` files.

The `go-git` library’s index decoder for Git index format version 4 does not properly validate the path name prefix length before applying it to the previously decoded path name. A specially crafted index file can cause an out-of-bounds slice operation, leading to a runtime panic during index parsing. This issue only affects Git index format version 4. An attacker with the ability to modify or inject a Git index file within a local repository can cause applications using `go-git` to terminate, resulting in a denial-of-service (DoS) condition.

FileRise is a self-hosted web file manager and WebDAV server. The `resumableIdentifier` parameter within the Resumable.js chunked upload handler, specifically the `UploadModel::handleUpload()` function, is directly incorporated into filesystem paths without proper sanitization. An authenticated user possessing upload privileges can leverage this to write files to arbitrary directories on the server, delete directories, and determine the existence of files and directories. The issue is addressed in version 3.10.0.

The `yaml` library is susceptible to a stack overflow when parsing YAML documents. The issue occurs during the node resolution/composition phase, which uses recursive function calls without a depth limit. An attacker providing malicious YAML input, approximately 2–10 KB in size, can trigger a `RangeError: Maximum call stack size exceeded`. This error is not a `YAMLParseError`, potentially leading to unexpected exceptions in applications that only handle YAML-specific errors. The impact can range from request failures to the termination of the Node.js process. Flow sequences, with their minimal byte overhead per nesting level, facilitate deep nesting and exacerbate the problem. The library's `Parser` (CST phase) is not affected, as it employs an iterative, stack-based approach. The affected APIs include `YAML.parse()`, `YAML.parseDocument()`, and `YAML.parseAllDocuments()`.

tinytag version 2.2.0 contains an issue where an attacker who can supply MP3 files for parsing can trigger a non-terminating loop while the library parses an ID3v2 SYLT (synchronized lyrics) frame. In server-side deployments that automatically parse attacker-supplied files, a single 498-byte MP3 can cause the parsing operation to stop making progress and remain busy until the worker or process is terminated. The root cause is that ` parse synced lyrics` assumes ` find string end pos` always returns a position greater than the current offset, which is false when no string terminator is present in the remaining frame content. The vulnerable call path involves `TinyTag.get`, ` load`, ` parse tag`, ` parse id3v2`, ` parse frame`, ` parse synced lyrics`, and ` find string end pos`. The `SYLT` parsing support was introduced in version 2.2.0.

Dasel’s YAML reader is susceptible to excessive CPU and memory consumption when processing YAML data supplied by an attacker. This occurs because the library’s `UnmarshalYAML` implementation recursively resolves YAML alias nodes without any expansion limit, bypassing the built-in alias expansion limit present in go-yaml v4. A relatively small 342-byte payload can trigger this issue, leading to denial of service. The issue resides in the `UnmarshalYAML` function, which handles alias nodes by recursively following `yaml.Node.Alias` pointers without a defined expansion budget. This allows an attacker to create a YAML document with deeply nested aliases, causing unbounded resource growth during parsing. The root cause is that Dasel receives a compact Node tree and then re-expands aliases without a limit, unlike go-yaml v4’s `Unmarshal` function which tracks alias expansion count.

Uncontrolled recursion occurs during the construction of `JustHTML()`, where the `TreeBuilder.finish()` function calls ` populate selectedcontent()`. This process recursively traverses the DOM tree using ` find elements()` and ` find element()` without a depth limit. An attacker providing specially crafted HTML with deeply nested elements can exceed the CPython default recursion limit, triggering a `RecursionError`. This can lead to a denial of service by aborting parsing, failing requests, or terminating the worker process.