Most recent entries from osv_rustsec

RUSTSEC-2026-0318 — Sending custom to-device messages may panics

2026-10-01T20:25:27+00:00

Affected: crates.io: matrix-sdk-crypto

Using the `IdentityBasedStrategy` setting when calling `Device::encrypt_event_raw` or `OlmMachine::encrypt_content_for_devices` may cause a panic if the recipient does not have cross-signing keys.

RUSTSEC-2026-0305 — Use-after-free when XML includes have duplicated entities

2026-10-01T19:14:05+00:00

Affected: crates.io: librsvg

Librsvg uses libxml2, a C library, to parse XML. When librsvg parses an SVG document which has a nested Xinclude, an XML entity declaration with a duplicate name as an existing one can cause a use-after-free error.

While libxml2 is expanding an internal entity, a recursive XInclude can parse another document that declares an entity with the same name. Both parses use the same `XmlState` entity map on the librsvg side. `entity_insert()` replaces the first entry, whose `Drop` implementation calls `xmlFreeNode()`. The outer `xmlCtxtParseEntity()` then keeps using the freed 144-byte `xmlEntity`.

The included parse should not free an entity that the outer parser is still using.

The fix is in commit 8a1b0cd319e9af2d1e9cf878081dd77f227a0504, where librsvg will no longer free xmlEntity pointers that libxml2 is still using.

RUSTSEC-2026-0317 — A 512-byte workbook can provoke a multi-gigabyte allocation and abort the process

2026-10-01T07:31:41+00:00

Affected: crates.io: sheets-diff

Affected versions passed caller-supplied bytes to `calamine`'s `Xlsx::new` without first checking that they were a ZIP archive. `Xlsx::new` tests for password protection on its first line, which parses the input as an OLE/CFB container, and a sector-count field read from the file's own header reaches `Vec::with_capacity` without being checked against the file's actual length. A 512-byte input can therefore request several gigabytes; 9,261,285,372 bytes was measured.

**The oversized allocation is always attempted. Whether it aborts depends on what the allocator can satisfy.** On a large host with overcommit the reservation is granted untouched and the call returns an ordinary "not an xlsx file" error, which looks like a malformed file being correctly rejected. Under a memory limit the same bytes give `memory allocation of N bytes failed` and the process aborts, which is not a `Result` a caller can handle. Containers with a memory limit, small hosts and CI runners are where this lands, so testing on a development machine can wrongly suggest the crate is unaffected.

Every entry point reaches it, not only `compare_bytes`: the path- and reader-based APIs funnel through the same internal open. Neither `Limits::default()` nor `Limits::hardened()` prevents it, because `max_input_bytes` bounds the length of the input while the allocation's size comes from a field inside it.

Fixed in 3.2.0, which declines input that does not begin with the ZIP magic before the parser sees it, remov…

RUSTSEC-2026-0213 — XSS in ammonia via SVG `animate` and `set` animation tags

2026-09-30T07:15:39+00:00

Affected: crates.io: ammonia

The following SVG will produce a link with a javascript scheme. If the user clicks this link, they will run it.

```xml ```

Ammonia did not apply attribute filters based on `attributeName`, so the contents of the `to`, `from`, and `values` tags were not sanitized as URLs.

Applications that do not explicitly allow either of these tags should not be affected, since neither are allowed by default.

---

**Discovered by:** [Younghun Ko (@koyokr)](https://github.com/koyokr)

RUSTSEC-2026-0316 — Dynamic record lifting can allocate beyond the hostcall fuel limit

2026-09-29T07:32:15+00:00

Affected: crates.io: wasmtime

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jqpg-j7w6-42pr For more information see the GitHub-hosted security advisory.

RUSTSEC-2026-0315 — `call_ref` and exception `catch` can drop some fuel accounting, leading to exponential fuel amplification

2026-09-29T07:32:15+00:00

Affected: crates.io: wasmtime

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-m63x-6p34-q65x For more information see the GitHub-hosted security advisory.

RUSTSEC-2026-0314 — Guest can panic host through filesystem datetime overflow

2026-09-29T07:32:15+00:00

Affected: crates.io: wasmtime-wasi

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-j2g9-4prp-pf6h For more information see the GitHub-hosted security advisory.

RUSTSEC-2026-0313 — Outgoing HTTP body write allows guest-driven host memory exhaustion

2026-09-29T07:32:15+00:00

Affected: crates.io: wasmtime-wasi-http

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-c9gc-w9vx-w86p For more information see the GitHub-hosted security advisory.

RUSTSEC-2026-0312 — Excluded iPAddress name constraints with an all-zero mask are not applied

2026-09-28T09:30:11+00:00

Affected: crates.io: x509-validator

An `excluded_subtrees` iPAddress name constraint with an all-zero mask (`0.0.0.0/0` or `::/0`) does not restrict iPAddress SANs in certificates issued beneath it. The mask check treated an all-zero mask as matching nothing, when a `/0` prefix matches every address of its family, so the exclusion was silently ignored.

CA/Browser Forum Baseline Requirements §7.1.2.5.2 require exactly these exclusions on every technically constrained sub-CA that may not issue for IP addresses. As a result, anyone holding (or having compromised) the key of such a sub-CA can issue a certificate for an arbitrary IP address, and `Validator` with `RFC5280Policy` and `ServerIdentityPolicy` accepts it for that address. A `permitted_subtrees` dNSName entry on the same issuer does not prevent this, because iPAddress SANs are a different name form.

All users of `Validator` with `RFC5280Policy` are affected when a chain can contain a name-constrained issuer with an all-zero iPAddress exclusion.

The issue is fixed in x509-validator 0.3.1 (commit [da661f8](https://github.com/namecare/x509-validator/commit/da661f8ecee820e05d089a76ecb654ff52a2c987)). Users should upgrade to 0.3.1 or later.

RUSTSEC-2026-0311 — Stack overflow on deeply nested LaTeX input

2026-09-28T08:34:35+00:00

Affected: crates.io: latex-rust

The parser and layout engine in affected versions of `latex-rust` recurse once per level of nesting with no limit. Deeply nested input, such as `\frac{1}{…}`, braces, `\sqrt{…}`, `\left(`, or superscripts nested hundreds or thousands of levels deep, exhausts the call stack.

A stack overflow in Rust aborts the process. It is not a panic, so it cannot be caught with `catch_unwind`. A program that renders LaTeX from untrusted input can therefore be terminated by a short string. With a release build on an 8 MiB stack, 700 nested `\frac{1}{…}` (about 7 KB of input) abort version 1.0.4, and 10,000 nested braces (about 20 KB) abort it as well. The threshold is lower on smaller stacks and in debug builds; on a 2 MiB thread in a debug build, about 35 nested fractions are enough.

```rust let mut src = String::from("1"); for _ in 0..700 { src = format!("\\frac{{1}}{{{src}}}"); } let _ = latex_rust::parse(&src); // stack overflow, process aborts ```

The fixed versions count nesting depth in the parser and in `layout` and refuse input that nests more than 32 levels. `parse`, `parse_with_colors`, and the `latex_to_*` functions return `ParseError::Malformed("input nests deeper than 32 levels")`, and `layout` returns `Error::Unsupported { what: "tree nests deeper than 32 levels" }` for a tree built by hand. The count is of parser recursion levels, and a braced argument costs two, so the limit admits 15 nested `\frac`, `\sqrt`, or `x^{…}`, and 31 nested groups, `\left…\right` pairs, o…