[chaliy]

What changed

wasmtime =48.0.6 → =48.0.7, across the exact workspace pin and all three
lockfiles that resolve wasmtime independently: Cargo.lock,
crates/bashkit/fuzz/Cargo.lock, examples/hyperlight/host/Cargo.lock.

cargo vet needs no new exemptions — the bytecodealliance import, which is
wasmtime's own maintainers' audit set, already covers the 48.0.7 crates, so only
imports.lock refreshes.

Why

Two advisories against wasmtime 48.0.6 were published 2026-10-19:

Advisory	Severity	Issue
RUSTSEC-2026-0379	9.9 critical	Cranelift backend on aarch64 can jump to an incorrect target on a large Wasm br_table
RUSTSEC-2026-0378	5.7 medium	Panic lowering a host-created component-model stream into a guest expecting a different payload type

cargo audit scans every lockfile in the tree regardless of the diff, so from
the moment the advisory database picked these up this reddens the Audit job on
every PR and on main — it first surfaced on an unrelated rustyline bump.
It is not a flake; a re-run does not clear it.

48.0.7 is the in-line remedy, which is what makes this a patch rather than a
project. The advisories' other fixed ranges are >=49.0.4 and a 36.x
backport; 48.x is the newest line supporting the pinned rustc 1.95, so 49.x
would drag in a toolchain bump and 36.x would be a major downgrade. This is also
why wasmtime sits in dependabot's ignore list — the 49.x bump it would propose
is the one that cannot land, while this patch can.

The exact pin is deliberate (.cwasm artifacts only load into an identical
wasmtime version), so the pin and every lockfile move together in one commit.

Before / After

Before — Audit on examples/hyperlight/host/Cargo.lock:

Crate:     wasmtime
Version:   48.0.6
error: 2 vulnerabilities found!
Title:     Cranelift backend on aarch64 can jump to incorrect target on large Wasm `br_table` instruction
ID:        RUSTSEC-2026-0379
Severity:  9.9 (critical)
Solution:  Upgrade to >=36.0.19, <37.0.0 OR >=48.0.7, <49.0.0 OR >=49.0.4

After — same scan, clean:

$ cargo audit --file examples/hyperlight/host/Cargo.lock
    Scanning examples/hyperlight/host/Cargo.lock for vulnerabilities (118 crate dependencies)
    (no vulnerabilities)

$ cargo audit --file Cargo.lock
    Scanning Cargo.lock for vulnerabilities (687 crate dependencies)
warning: 1 allowed warning found          # pre-existing atomic-polyfill RUSTSEC-2023-0089, allowlisted

crates/bashkit/fuzz/Cargo.lock and examples/hyperlight/Cargo.lock also scan
clean.

The risk specific to this pin is that the cpython feature embeds a .cwasm
precompiled by build.rs, and the pin comment states such artifacts "only load
into the identical wasmtime version". A patch bump should be fine because
build.rs recompiles — but that was worth proving rather than assuming, so CI's
own cpython command was run against 48.0.7:

$ cargo test -p bashkit --features cpython,http_client --lib --test integration -- cpython
test result: ok. 138 passed; 0 failed; 0 ignored; 0 measured; 1847 filtered out

That includes the whole cpython_security_tests suite — sandbox containment,
VFS confinement, timeouts, recursion and output caps all still hold.

$ cargo vet --locked
Vetting Succeeded (98 fully audited, 83 partially audited, 495 exempted)

Risk

• Low for the change, high for not making it.
• A patch bump within the pinned 48.x line; no toolchain change, no API change,
  no bashkit source touched.
• The precompiled-artifact pin was the one real hazard and is covered by the
  138-test cpython run above.
• Worth noting the critical advisory is a Cranelift aarch64 codegen bug.
  bashkit's runtime wasmtime build sets default-features = false with Pulley
  and no Cranelift, so the primary runtime path was less exposed than the raw
  severity suggests — but examples/hyperlight/host does enable cranelift,
  and it is an example runner executing untrusted guest modules in CI, which is
  exactly the surface that entry in .github/dependabot.yml was added to watch.

Checklist

• Tests added or updated — existing cpython suite (138 tests incl. security)
  exercised against the new version; a dependency bump adds no new code
  surface to test
• Backward compatibility considered — patch bump, no public API change

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	16f59a9	Commit Preview URL Branch Preview URL	Oct 20 2026, 11:40 AM