Stream: git-wasmtime

Topic: wasmtime / issue #12593 RUSTSEC-2026-0009: Denial of Serv...

Wasmtime GitHub notifications bot (Feb 14 2026 at 00:17):

github-actions[bot] opened issue #12593:

Denial of Service via Stack Exhaustion

Details
Package	time
Version	0.3.36
URL	https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
Date	2026-02-05
Patched versions	>=0.3.47
Unaffected versions	<0.3.6

Impact

When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
service attack via stack exhaustion is possible. The attack relies on formally deprecated and
rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
non-malicious input will never encounter this scenario.

Patches

A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
rather than exhausting the stack.

Workarounds

Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
the stack consumed would be at most a factor of the length of the input.

See advisory page for additional details.

Wasmtime GitHub notifications bot (Feb 14 2026 at 02:03):

alexcrichton commented on issue #12593:

The reverse dependency tree for time in our workspace is:

time v0.3.36
└── zip v0.6.6
    └── tch v0.17.0
        └── wasmtime-wasi-nn v43.0.0 (/home/alex/code/wasmtime/crates/wasi-nn)
            ├── wasmtime-bench-api v43.0.0 (/home/alex/code/wasmtime/crates/bench-api)
            └── wasmtime-cli v43.0.0 (/home/alex/code/wasmtime)
    [build-dependencies]
    └── torch-sys v0.17.0
        └── tch v0.17.0 (*)

This is only used transitively through the zip crate, which is itself only used through tch, which is itself only used for wasi-nn. Attempting to update time yeilds the following vets:

Vetting Failed!

4 unvetted dependencies:
  deranged:0.5.6 missing ["safe-to-deploy"]
  num-conv:0.2.0 missing ["safe-to-deploy"]
  time:0.3.47 missing ["safe-to-deploy"]
  time-core:0.1.8 missing ["safe-to-deploy"]

recommended audits for safe-to-deploy:
    Command                               Publisher  Used By  Audit Size
    cargo vet diff num-conv 0.1.0 0.2.0   jhpratt    time     3 files changed, 13 insertions(+), 129 deletions(-)
    cargo vet diff time-core 0.1.4 0.1.8  jhpratt    time     5 files changed, 231 insertions(+), 81 deletions(-)
    cargo vet diff deranged 0.4.0 0.5.6   jhpratt    time     5 files changed, 691 insertions(+), 293 deletions(-)
    cargo vet diff time 0.3.41 0.3.47     jhpratt    zip      152 files changed, 26635 insertions(+), 2822 deletions(-)

estimated audit backlog: 30895 lines

Use |cargo vet certify| to record the audits.

I'm not personally particularly keen on the 30kloc diff in time here myself...

Wasmtime GitHub notifications bot (Feb 14 2026 at 02:03):

alexcrichton edited a comment on issue #12593:

The reverse dependency tree for time in our workspace is:

time v0.3.36
└── zip v0.6.6
    └── tch v0.17.0
        └── wasmtime-wasi-nn v43.0.0 (/home/alex/code/wasmtime/crates/wasi-nn)
            ├── wasmtime-bench-api v43.0.0 (/home/alex/code/wasmtime/crates/bench-api)
            └── wasmtime-cli v43.0.0 (/home/alex/code/wasmtime)
    [build-dependencies]
    └── torch-sys v0.17.0
        └── tch v0.17.0 (*)

This is only used transitively through the zip crate, which is itself only used through tch, which is itself only used for wasi-nn. Attempting to update time yields the following vets:

Vetting Failed!

4 unvetted dependencies:
  deranged:0.5.6 missing ["safe-to-deploy"]
  num-conv:0.2.0 missing ["safe-to-deploy"]
  time:0.3.47 missing ["safe-to-deploy"]
  time-core:0.1.8 missing ["safe-to-deploy"]

recommended audits for safe-to-deploy:
    Command                               Publisher  Used By  Audit Size
    cargo vet diff num-conv 0.1.0 0.2.0   jhpratt    time     3 files changed, 13 insertions(+), 129 deletions(-)
    cargo vet diff time-core 0.1.4 0.1.8  jhpratt    time     5 files changed, 231 insertions(+), 81 deletions(-)
    cargo vet diff deranged 0.4.0 0.5.6   jhpratt    time     5 files changed, 691 insertions(+), 293 deletions(-)
    cargo vet diff time 0.3.41 0.3.47     jhpratt    zip      152 files changed, 26635 insertions(+), 2822 deletions(-)

estimated audit backlog: 30895 lines

Use |cargo vet certify| to record the audits.

I'm not personally particularly keen on the 30kloc diff in time here myself...

Wasmtime GitHub notifications bot (Feb 14 2026 at 02:31):

cfallin commented on issue #12593:

That's pretty unfortunate that the fixed version of time includes 26635 LoC of new code in addition to the security fix. (That's across several point-releases of course, but is still the path we have to take to get it.)

My quick read of zip's usage of time is that it doesn't seem to do RFC822 parsing -- zip files use MS-DOS timestamps per here. Given that, I'm comfortable calling this issue inapplicable, though of course anyone doing an automated RustSec scan of their deps will still see this.

Tally this as part of the cost of vetting discipline I guess (alongside the benefits as they may be).

Wasmtime GitHub notifications bot (Feb 14 2026 at 20:41):

alexcrichton closed issue #12593:

Denial of Service via Stack Exhaustion

Details
Package	time
Version	0.3.36
URL	https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
Date	2026-02-05
Patched versions	>=0.3.47
Unaffected versions	<0.3.6

Impact

When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
service attack via stack exhaustion is possible. The attack relies on formally deprecated and
rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
non-malicious input will never encounter this scenario.

Patches

A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
rather than exhausting the stack.

Workarounds

Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
the stack consumed would be at most a factor of the length of the input.

See advisory page for additional details.

Wasmtime GitHub notifications bot (Feb 14 2026 at 20:41):

alexcrichton commented on issue #12593:

Oh good catch yeah. In that case I think it's fine for us to close this on our end. Our own lock file isn't automatically inherited by other crates anyway and we're not preventing other crates from updating to a fixed version here. In essence this pinned dependency only affects us, and it looks like the usage isn't vulnerable here.

Now we also have no way of tracking this in the future in the sense that there's nothing stopping some other dependency from starting to use the time crate and start using this vulnerable surface area. In essence we're just sort of trusting ourselves to not do that...

Last updated: Feb 24 2026 at 04:36 UTC