Threats Tagged 'crates-io'

A vulnerability in rust-wasmtime prior to versions 24.0.11, 36.0.12, 45.0.3, and 46.0.1 allows a WASI guest with read-only source file capability to overwrite host files exposed as read-only. This occurs due to improper permission checks during hard-link creation and renaming, where directory permissions are checked but not matching file permissions on source and destination preopens. The issue is fixed in the specified versions.

lopdf versions prior to 0.42.0 contain a stack overflow vulnerability in the PDF parser due to unbounded recursion when processing deeply nested PDF arrays or dictionaries. A crafted PDF with around 10,000 levels of nested arrays in the Catalog can cause the parser to exhaust the call stack and abort the process with SIGABRT, resulting in a denial of service. This vulnerability does not cause a panic that can be caught, making it effective for crashing services that parse untrusted PDFs. The issue is fixed in lopdf version 0.42.0 by enforcing a maximum object-nesting depth.

Bulletin ID: 2026-042-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 06/10/2026 11:15 AM PDT Description: s2n-quic is a Rust implementation of the QUIC protocol. We identified CVE-2026-10740, an issue of unbounded memory allocation in the CRYPTO frame reassembler in s2n-quic before 1.82.0. An unauthenticated user can attempt to exhaust server memory on an s2n-quic endpoint by sending crafted CRYPTO frames with high offsets. The buffer used for processing CRYPTO frames does not enforce a maximum size. In the worst case, a single 1200-byte packet can cause approximately 9.4 MB of allocation. By repeatedly sending such packets, the resulting memory pressure could cause denial of service. No valid handshake is required. Impacted versions: < v1.82.0 Please refer to the article below for the most up-to-date and complete information related to this AWS Security Bulletin.

## Summary Untrusted local .mise.toml [settings] can set the shell interpreter args (unix/windows default_inline / default_file shell_args), yielding arbitrary command execution, because those command-interpreter settings were not added to the global_only denylist the CVE-2026-55448 fix relies on. Code execution from an untrusted repository with no trust prompt for the malicious file, on par with the patched CVE. Confirmed at HEAD 7160170206782fdd3ef287c8302369e32152fb71. ## The defect CVE-2026-55448 and CVE-2026-35533 fixed the fact that a local project [settings] table is harvested by the settings preloader independent of the trust store (an untrusted .mise.toml sets settings without the user ever trusting it). The remediation is a per-field global_only denylist: settings marked global_only are stripped from non-global config. The maintainers marked the command-execution fields they knew about (the three forge credential_command values) but did not mark the four shell-interpreter-args settings, which are also command-execution settings because they choose the interpreter for every command mise spawns. The global_only denylist and the gap. In settings.toml, the three credential_command sinks are global_only (forgejo.credential_command around line 775, github.credential_command around 828, gitlab.credential_command around 990). The four shell-args settings do not carry global_only: - unix_default_file_shell_args (settings.toml around 2920) - unix_default_inline_shell_args (around 2926) - windows_default_file_shell_args (around 3004) - windows_default_inline_shell_args (around 3010) The strip logic only removes global_only keys. src/config/settings.rs strip_local_only_settings (line 409) filters by meta.global_only (line 416: `filter_map(|(key, meta)| meta.global_only.then_some(*key))`), so any field not marked global_only survives from a local untrusted config. The settings preload loads every config path including the local project file (all_settings_files, line 778), and in default (non-safe) mode there is no trust check (safe_mode defaults false, line 1141). The sink. src/config/settings.rs default_inline_shell (line 1032) reads self.unix_default_inline_shell_args (line 1040), and default_file_shell reads unix_default_file_shell_args. Settings::get returns the merged global-plus-local value minus global_only, so the untrusted project value overrides the built-in default (sh -c -o errexit). Injection semantics. The real command is appended after the attacker's args, so PAYLOAD runs and the real command is demoted to $0: - tera inline exec builtin: src/tera.rs (tera1_exec around 1358, and around 1470) builds shell[1..] + [command] with program = shell[0]. An attacker unix_default_inline_shell_args = "sh -c 'PAYLOAD'" yields sh -c 'PAYLOAD' <command>. - postinstall runner: src/backend/mod.rs around 2405 calls cmd_body_args(shell_args, body); src/cmd.rs cmd_body_args (non-Windows, around 520) returns program flags... body, the same demotion. - task execution: src/task/task_executor.rs (around 916, 939, 993) uses task.shell()?.unwrap_or(default_inline_shell()/default_file_shell()), so a trusted task with no explicit shell (the common case) runs through the attacker's interpreter. - hooks: src/hooks.rs (around 540, 603) also fall back to default_inline_shell(). ## Attacker model and reachability An untrusted repository the developer clones and cd's into. The attacker's .mise.toml sits in the working directory or any ancestor and is never trusted by the victim; its [settings] table is harvested by the preloader independent of the trust store, exactly as the two prior CVEs established. The executed command can come from a trusted or global source; only the interpreter is attacker-controlled. Any of these, run while the untrusted .mise.toml is in an ancestor directory, fires it: mise run <task> for a task defined in the global config or a trusted parent repo (inline run, no explicit shell); mise install of any tool with a postinstall directive; any tera template that calls exec(...) in the victim's own trusted or global config; a directory-enter hook from any trusted config in scope. Proof of concept. In an untrusted repo, .mise.toml: ```toml [settings] unix_default_inline_shell_args = "sh -c 'id > /tmp/mise_pwned'" ``` The victim cd's in (does not trust the file) and later runs any global or trusted-parent task with no explicit shell, or mise install of a tool with a postinstall, or a config that renders {{ exec(...) }}. mise builds `sh -c 'id > /tmp/mise_pwned' <realcommand>`, so the payload runs. ## Verification Source-verified at HEAD: the four shell-args settings lack global_only while the credential_command sinks have it, strip_local_only_settings removes only global_only keys, default_inline_shell reads the setting, and the exec/postinstall/task paths append the real command after the attacker args. The load path is the same one two shipped CVEs already proved reachable. I did not run mise

Praxis proxy versions prior to 0.5.2 are vulnerable to a denial-of-service condition caused by improper handling of HTTP/2 header compression (HPACK). An attacker can send crafted HTTP/2 requests that trigger excessive memory allocation on the server, leading to high memory usage and potential service disruption. This issue is due to missing default HTTP/2 options that limit resource consumption. A patch is available that sets appropriate HTTP/2 options to mitigate the memory exhaustion.

A vulnerability in xxhash-rust version prior to 0.8.16 allows a safe API to accept a custom secret that is shorter than the internal minimum length. This leads to undefined behavior due to construction of invalid fixed-width references when running in release mode, as the length check is only enforced by debug assertions. The issue does not require unsafe code from the caller and can cause memory safety violations under certain conditions.

### Impact Wasmtime's implementation of bulk-data-transfer WebAssembly instructions, such as `memory.copy`, contains a vulnerability when a preemption via epochs or fuel is combined with altering the store's state or cancelling a computation. To prevent these operations from taking too long Wasmtime injects fuel/epoch checks during these operations, but this enables embedders, and possible WebAssembly, to witness intermediate state in the middle of the operation. Examples of this include: * When a non-nullable WebAssembly table is grown the new elements initially start as null and are filled in as part of a loop with preemption checks. If this computation is then cancelled this left the table in a grown-but-uninitialized state where subsequent usage via WebAssembly could possibly segfault. Loads from this table are assumed to not be null due to its type, but the runtime implementation was exposed through this cancellation at a preemption point. * Embedders could mutate the store during an epoch callback, such as growing a WebAssembly linear memory. During a bulk `memory.copy` operation, however, the pointers being copied to/from weren't recomputed between preemption points. This meant that if the linear memory moved its base address it could be possible to have a preemption, the embedder manually grows memory, and then on resumption the copy operation uses invalid pointers. * Embedders could execute a GC during epoch callbacks. GC operations such as `array.copy`, like `memory.copy` above, maintained raw pointers internally in the operation which were not updated after the preemption point. This could lead to corruption of the GC heap. All of these situations are examples of embedder-driven mutations of the `Store` or embedder-induced resumption of a `Store` after a computation was cancelled. These operations expose the internal state of these WebAssembly operations which is semantically incorrect and additionally can cause segfaults for example. Exposing these bugs, however, requires explicit patterns to be present in the embedding itself such as using `Store::epoch_deadline_callback` and mutating wasm options. Another example is to cancel one invocation (possibly in a `table.grow`) and then execute more wasm afterwards within the same store. Embeddings not using `Store::epoch_deadline_callback` or executing code after timeouts/fuel are not affected by this issue. ### Patches This issue is fixed in Wasmtime 46.0.2 and 47.0.3. In these versions Wasmtime reverts back to Wasmtime 45-and-earlier behavior for these operations to check fuel once before the operation and then not during the operation. This means that a very large `memory.copy` does not have preemption points in the middle of the operation any more, for example. ### Workarounds Embedders using `Store::epoch_deadline_callback` are safe if they only access the `T` in `Store<T>`. Embedders that do not continue using a store after a timeout or epoch deadline are also unaffected. Embedders which explicitly mutate the store in an epoch callback, or resume wasm after trapping have no workaround however. The embedding needs to be updated to account for this issue.

The rmcp OAuth client in the modelcontextprotocol rust-sdk accepts a server-controlled resource_metadata URL from the WWW-Authenticate header and fetches it without validating origin or blocking internal network addresses. This allows an attacker-controlled or compromised MCP server to induce the client to make HTTP requests to internal or cloud metadata endpoints, potentially exposing sensitive internal resources. The vulnerability is classified as SSRF with medium severity, depending on the network context of the embedding application. A patch is available to enforce same-origin checks and block private network addresses.

RMCP is an official Rust SDK for the Model Context Protocol. Prior to 2.0.0, the rmcp crate's OAuth implementation in crates/rmcp/src/transport/auth.rs omits the RFC 9728 resource field from ResourceServerMetadata and allows discover_oauth_server_via_resource_metadata to use protected-resource metadata without confirming that the returned resource identifier exactly matches the configured MCP server. A malicious MCP server can publish metadata for a different legitimate MCP resource and its authorization server, causing a victim who connects and completes the authorization flow to obtain a legitimate access token that the client subsequently sends to the malicious server. The attacker can capture the token and impersonate the victim against the legitimate MCP resource within the token's granted scopes. This issue is fixed in version 2.0.0.

RMCP is an official Rust SDK for the Model Context Protocol. Prior to 2.0.0, the rmcp crate's stateful Streamable HTTP server in crates/rmcp/src/transport/streamable_http_server/tower.rs allows an unauthenticated client to send a well-formed JSON-RPC POST that is not an initialization request, or an initialization request with a mismatched protocol header, causing StreamableHttpService::handle_post to call LocalSessionManager.create_session before validating the message. An early validation failure returns without removing the inserted LocalSessionHandle from LocalSessionManager.sessions, permanently retaining session and channel state for the server process lifetime. Repeated requests can grow the shared session table without bound, degrade legitimate-client latency through lock contention, exhaust memory, and terminate the server. This issue is fixed in version 2.0.0.