Skip to content
Log inStart free trial

GHSA-852m-cvvp-9p4w CVE-2026-27204 RUSTSEC-2026-0020

Wasmtime WASI implementations are vulnerable to guest-controlled resource exhaustion

Medium crates.io
Severity
0.0 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.40%
Chance of exploitation in the next 30 days. Higher than 34.62% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-400 Uncontrolled Resource Consumption
CWE-770 Allocation of Resources Without Limits or Throttling
CWE-774 Allocation of File Descriptors or Handles Without Limits or Throttling
CWE-789 Memory Allocation with Excessive Size Value
Fix
24.0.6
Upgrade wasmtime to this version or later

Description

Impact

Wasmtime's implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector where a guest can induce a range of crashing behaviors on the host such as:

  • Allocating arbitrarily large amounts of host memory.
  • Causing an allocation failure on the host, which in Rust defaults to aborting the process.
  • Causing a panic on the host due to over-large allocations being performed.
  • Cause degredation in performance of the host by holding excessive host memory alive.

Wasmtime's security bug policy considers all of these behaviors a security vulnerability. Wasmtime's implementation of WASI has a number of different ways that resource exhaustion could happen, and fixing any one of them is insufficient from solving this vulnerability. A number of individual issues are grouped within this advisory and as a whole represent the known ways that guests can exhaust resources on the host.

An example of guest-controlled resource exhaustion within Wasmtime's implementation of WASI is guests could repeatedly allocate handles to themselves without limit. Some APIs also caused the host to perform a guest-controlled-sized allocation of a buffer on the host for I/O operations. Other APIs could force the host to buffer arbitrary amounts of data for the guest. Finally the guest could hand arbitrarily large allocations from itself to the host which could cause the host to perform an arbitrarily sized copy of memory which in some situations could result in quadratically sized allocations.

Wasmtime's implementations of WASIp1 and WASIp2 are affected by this vulnerability. Any host API modeled with the Component Model (or WIT) which operates on a string or list<T> type is also affected. Not all WIT and WASI APIs are affected by this issue, but that's more of an exception so it's recommended for all embedders to consider themselves affected.

To address this issue a number of mitigations are being applied to limit the behavior of a guest in WASI. All of these mitigations manifest in the form of a limit of some kind applied to various situations, and as such all of these mitigations are backwards-incompatible as they run the risk of breaking preexisting programs. To address this all backports to previous stable releases have these limits tuned to overly-large values. This ensures that preexisting guests do not break while still providing embedders the knobs to prevent this DoS vector as well. The limits added to Wasmtime are:

  • -Smax-resources=N or ResourceTable::set_max_capacity - the maximum number of resources that a guest is allowed to allocate for itself.
  • -Shostcall-fuel=N or Store::set_hostcall_fuel - the maximum amount of data that the guest may copy to the host in a single function call.
  • -Smax-random-size=N or WasiCtxBuilder::max_random_size - the maximum size of the return value of get-random-bytes and get-insecure-random-bytes in the wasi:random implementations.
  • -Smax-http-fields-size=N or WasiHttpCtx::set_max_fields_size - the maximum size of headers for an HTTP request/response.

These settings are equally applicable to both WASIp1 and WASIp2. Wasmtime 41.0.x and prior previously did not limit these settings and the knobs being released are set to very large values by default to avoid any breaking behavior. Embedders will need to proactively tune these knobs as appropriate for their embeddings. The default settings in the unreleased Wasmtime 42.0.0 are 1M for max resources, 128MiB for hostcall fuel, 64MiB for max-random-size, and 32KiB for http fields size. Tuning is not expected for Wasmtime 42.0.0+.

Hosts/embedders affected by this issue are encouraged to audit and double-check their own host APIs they have implemented to see whether they are affected by this issue as well. The -Shostcall-fuel setting is intended to be a relatively coarse fix for many possible issues by limiting the amount of data for all host APIs at once, so many embedders may not need to take further action beyond updating Wasmtime and configuring it appropriately (if not updating to 42.0.0). Embedders should audit to see, however, if the guest is able to force the host to allocate on its behalf and ensure that the allocation is limited or tracked somehow.

Patches

Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 have all been released with the fix for this issue. These versions do not prevent this issue in their default configuration to avoid breaking preexisting behaviors. All versions of Wasmtime have appropriate knobs to prevent this behavior, and Wasmtime 42.0.0-and-later will have these knobs tuned by default to prevent this issue from happening.

Workarounds

There are no known workarounds for this issue without upgrading. Embedders are recommended to upgrade and configure their embeddings as necessary to prevent possibly-malicious guests from triggering this issue.

Resources

Affected versions

crates.io

PackageVulnerableFixed in
wasmtime
< 24.0.6
24.0.6
wasmtime
>= 25.0.0, < 36.0.6
36.0.6
wasmtime
>= 37.0.0, < 40.0.4
40.0.4
wasmtime
>= 0.0.0-0, < 24.0.6
>= 25.0.0, < 36.0.6
>= 37.0.0, < 40.0.4
>= 41.0.0, < 41.0.4
24.0.6
36.0.6
40.0.4
41.0.4

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

wasmtime crates.io → 24.0.6

cargo
cargo update -p wasmtime --precise 24.0.6

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L

Attack vector
Network
Attack complexity
Low
Attack requirements
Present
Privileges required
Low
User interaction
Passive
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
None
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
Low

CVSS 3.1 6.5

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-400: Uncontrolled Resource Consumption

The product does not properly control the allocation and maintenance of a limited resource.

How to prevent it
  • Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
  • Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
  • Implementation: Ensure that all failures in resource allocation place the system into a safe posture.

CWE-770: Allocation of Resources Without Limits or Throttling

The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.

How to prevent it
  • Requirements: Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
  • Architecture and Design: Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.
  • Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • Architecture and Design: For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  • Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.
  • Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
  • Architecture and Design, Implementation: If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery. Ensure that all failures in resource allocation place the system into a safe posture.
  • Operation, Architecture and Design: Use quotas or other resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

CWE-774: Allocation of File Descriptors or Handles Without Limits or Throttling

The product allocates file descriptors or handles on behalf of an actor without imposing any restrictions on how many descriptors can be allocated, in violation of the intended security policy for that actor.

How to prevent it
  • Operation, Architecture and Design: Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

CWE-789: Memory Allocation with Excessive Size Value

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

How to prevent it
  • Implementation, Architecture and Design: Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
  • Operation: Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

References

Advisories

Packages

Other links

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
RUSTSEC-2026-0424
Unchecked memory usage in transferring borrowed resources between components
Not rated yet Also affects wasmtime
RUSTSEC-2026-0423
Cross-engine type confusion with host-created struct-types-with-supertypes
Not rated yet Also affects wasmtime
RUSTSEC-2026-0422
Typed functions with `i31` or `nullref` arguments may panic due to insufficient type-check
Low Also affects wasmtime
RUSTSEC-2026-0379
Wasmtime: Cranelift backend on aarch64 can jump to incorrect target on large Wasm `br_table` instruction
Critical Also affects wasmtime
GHSA-9pvw-hwfg-92h5
Wasmtime: Panic lowering a host-created component model stream into a guest that expects a different payload type
Medium Also affects wasmtime
GHSA-897f-g5gm-fmxm
Wasmtime: Bit-packing in Cranelift compiler causes silent overflow and miscompilation
Critical Also affects wasmtime
RUSTSEC-2026-0364
Exception tags can cause host data structures to be unaligned
Not rated yet Also affects wasmtime
RUSTSEC-2026-0363
Component-model handle tables are capped only per instance and charged to no limit
Medium Also affects wasmtime
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor