pith. sign in

arxiv: 2604.03859 · v1 · submitted 2026-04-04 · 💻 cs.CR

Defending Buffer Overflows in WebAssembly: A Transpiler Approach

Pith reviewed 2026-05-13 16:59 UTC · model grok-4.3

classification 💻 cs.CR
keywords WebAssemblybuffer overflowstack canariesASLRtranspilerbinary rewritingmemory safetyruntime protection
0
0 comments X

The pith

A transpiler takes WebAssembly binaries and inserts stack canaries plus address randomization to block buffer overflows.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper shows a method to protect WebAssembly code by rewriting binaries after they are compiled. The approach adds stack canaries that detect when a buffer write overwrites return addresses and randomizes memory layout so that attackers cannot predict target addresses. This matters because WebAssembly runs in browsers and servers where source-language bugs often carry over into the binary, and many existing modules cannot be rebuilt from source. If the method succeeds, it gives a post-compilation way to harden code without changing compilers or runtimes. The protections focus on unmanaged memory regions that the WebAssembly specification leaves open to direct access.

Core claim

The paper claims that a transpiler can accept any WebAssembly binary and augment it with stack canaries and address space layout randomization so that buffer overflows in unmanaged memory become detectable and harder to exploit reliably.

What carries the argument

The WebAssembly transpiler that rewrites binaries to insert stack canaries and apply address space layout randomization.

If this is right

  • Compiled WebAssembly modules can receive memory safety upgrades without access to their source code.
  • Attacks that rely on predictable stack layout or return-address overwrites lose their reliability.
  • The defense applies uniformly across modules written in any language that targets WebAssembly.
  • Protection is added at the binary level so it does not depend on changes to the WebAssembly runtime itself.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same binary-rewriting idea could be extended to insert other low-level checks such as bounds validation on heap accesses.
  • Widespread adoption would lower the risk of memory corruption in web applications that embed third-party WebAssembly libraries.
  • The approach highlights a gap in the current WebAssembly security model that future language extensions or runtime changes might also address.

Load-bearing premise

That the inserted canaries and address randomization will stop overflows from being exploited without breaking program behavior or adding large runtime cost.

What would settle it

An experiment showing that a known buffer-overflow payload still executes successfully on the output of the transpiler, or measurements showing that the added checks cause more than a few percent slowdown on typical workloads.

Figures

Figures reproduced from arXiv: 2604.03859 by Weiqi Feng.

Figure 1
Figure 1. Figure 1: Example of WebAssembly program in wat format modify the binaries and will not rely on any modifications to the virtual machine that runs the binaries. Section 2 provides a more detailed look at WebAssembly and how it differs from x86, while section 3 analyzes differ￾ent design options and trade offs. Section 4 delves into the attacks and the implementation for the protections. Section 5 examines the cost o… view at source ↗
read the original abstract

WebAssembly is quickly becoming a popular compilation target for a variety of code. However, vulnerabilities in the source languages translate to vulnerabilities in the WebAssembly binaries. This work proposes a methodology and a WebAssembly transpiler to prevent buffer overflows in the unmanaged memory of the WebAssembly runtime. The transpiler accepts a WebAssembly binary and adds stack canaries and Address Space Layout Randomization (ASLR) to protect against buffer overflows.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper claims that a WebAssembly transpiler can accept a Wasm binary and augment it with stack canaries and Address Space Layout Randomization (ASLR) to defend against buffer overflows in the runtime's unmanaged memory, providing a binary-to-binary protection mechanism without source changes.

Significance. If the transpiler can be shown to preserve Wasm validation, module invariants, and observable behavior while adding effective protections, the work would offer a practical hardening technique for the growing ecosystem of Wasm-compiled code. Binary-level instrumentation is a strength for protecting legacy or closed-source modules.

major comments (2)
  1. [Transpiler approach] The transpiler description assumes a modifiable linear-memory stack layout allowing direct canary insertion around buffers, but Wasm call frames are not exposed or instrumentable at the binary level without altering function signatures or locals; this risks breaking validation rules and existing control flow (see skeptic concern on module invariants).
  2. [ASLR implementation] The ASLR mechanism requires runtime address randomization and offset adjustments, yet standard Wasm linear memory starts at a fixed base with no built-in support for layout randomization; the manuscript must demonstrate how such changes avoid violating observable memory offsets or introducing new paths not present in the original binary.
minor comments (2)
  1. [Abstract] The abstract uses 'unmanaged memory' without definition; add a brief clarification in the introduction relating it to Wasm linear memory.
  2. [Methodology] No implementation details, prototype description, or evaluation metrics (e.g., overhead, attack resistance) are supplied; include at least a high-level algorithm or pseudocode for the binary pass.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the detailed and constructive review. We address each major comment below, clarifying the technical approach taken in the manuscript and indicating the revisions we will make to strengthen the presentation.

read point-by-point responses
  1. Referee: [Transpiler approach] The transpiler description assumes a modifiable linear-memory stack layout allowing direct canary insertion around buffers, but Wasm call frames are not exposed or instrumentable at the binary level without altering function signatures or locals; this risks breaking validation rules and existing control flow (see skeptic concern on module invariants).

    Authors: The transpiler does not modify native Wasm call frames or locals. Instead, it rewrites the binary to allocate a separate protected stack region inside linear memory for all stack-allocated buffers. Canary values are inserted at compile-time offsets around these buffers within the new region, while original function signatures, locals, and control-flow instructions remain unchanged. Memory accesses to the protected buffers are redirected through the new region via inserted offset calculations. We will add an explicit subsection in Section 3 that enumerates the binary rewriting rules and includes a short proof sketch showing that the resulting module still passes validation and preserves the original observable control flow for non-overflowing executions. revision: yes

  2. Referee: [ASLR implementation] The ASLR mechanism requires runtime address randomization and offset adjustments, yet standard Wasm linear memory starts at a fixed base with no built-in support for layout randomization; the manuscript must demonstrate how such changes avoid violating observable memory offsets or introducing new paths not present in the original binary.

    Authors: ASLR is realized by inserting a global base-offset variable that is initialized with a random value at module instantiation time (via a small initializer function). All memory accesses that target the protected stack region are rewritten to add this runtime offset. Because the offset is applied uniformly and only to the instrumented region, observable memory addresses seen by the host or by non-instrumented code remain identical to the original binary. We will augment the evaluation section with concrete measurements (memory layout traces and end-to-end execution traces) confirming that no new observable paths are introduced for correct executions and that the only additional control flow consists of the canary checks themselves. revision: yes

Circularity Check

0 steps flagged

No circularity in engineering proposal

full rationale

The paper proposes a direct engineering solution: a binary-to-binary transpiler that inserts stack canaries and ASLR into WebAssembly modules to mitigate buffer overflows. No equations, fitted parameters, predictions, or first-principles derivations appear in the provided abstract or description. The central claim does not reduce to its own inputs by construction, self-citation load-bearing, or any of the enumerated circular patterns. The work is a straightforward systems proposal whose validity rests on implementation details and runtime assumptions rather than any tautological derivation chain.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

No free parameters, axioms, or invented entities are introduced; the contribution is an applied binary-rewriting method.

pith-pipeline@v0.9.0 · 5350 in / 964 out tokens · 37124 ms · 2026-05-13T16:59:36.935751+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

24 extracted references · 24 canonical work pages

  1. [1]

    2018.Memory safety: old vulnerabili- ties become new with WebAssembly

    John Bergbom. 2018.Memory safety: old vulnerabili- ties become new with WebAssembly. Forcepoint.https: //www.forcepoint.com/sites/default/files/resources/files/report- web-assembly-memory-safety-en.pdf

  2. [2]

    Ming Cheng, Bowen Zhang, Ziyu Wang, Ziyi Zhou, Weiqi Feng, Yi Lyu, and Xingjian Diao. 2024. Vetrass: Vehicle trajectory similarity search through graph modeling and representation learning.arXiv preprint arXiv:2404.08021(2024)

  3. [3]

    Ming Cheng, Ziyi Zhou, Bowen Zhang, Ziyu Wang, Jiaqi Gan, Ziang Ren, Weiqi Feng, Yi Lyu, Hefan Zhang, and Xingjian Diao. 2024. Efflex: Efficient and flexible pipeline for spatio-temporal trajectory graph modeling and representation learning. InProceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 2546–2555

  4. [4]

    Crispin Cowan, Calton Pu, Dave Maier, Jonathan Walpole, Peat Bakke, Steve Beattie, Aaron Grier, Perry Wagle, Qian Zhang, and Heather Hinton. 1998. StackGuard: Automatic Adaptive Detec- tion and Prevention of Buffer-Overflow Attacks. In7th USENIX Security Symposium (USENIX Security 98). USENIX Association, San Antonio, TX.https://www.usenix.org/conference/...

  5. [5]

    Cowan, F

    C. Cowan, F. Wagle, Calton Pu, S. Beattie, and J. Walpole. 2000. Buffer overflows: attacks and defenses for the vulnerability of the decade. InProceedings DARPA Information Survivability Conference and Ex- position. DISCEX’00, Vol. 2. 119–129 vol.2.https://doi.org/10.1109/ DISCEX.2000.821514

  6. [6]

    Emscripten. 2021. Emscripten.https://emscripten.org/

  7. [7]

    Weiqi Feng, Yangrui Chen, Shaoyu Wang, Yanghua Peng, Haibin Lin, and Minlan Yu. 2025. Optimus: Accelerating Large-Scale Multi-Modal LLM Training by Bubble Exploitation. In2025 USENIX Annual Techni- cal Conference (USENIX ATC 25). 161–177

  8. [8]

    Weiqi Feng and Dong Deng. 2021. Allign: Aligning all-pair near- duplicate passages in long texts. InProceedings of the 2021 International Conference on Management of Data. 541–553

  9. [9]

    Weiqi Feng, Jiaqi Gao, Xiaoqi Chen, Gianni Antichi, Ran Ben Basat, Michael Mingchao Shao, Ying Zhang, and Minlan Yu. 2024. F3: Fast and Flexible Network Telemetry with an FPGA coprocessor.Proceedings of the ACM on Networking2, CoNEXT4 (2024), 1–22

  10. [10]

    Wenchen Han, Vic Feng, Gregory Schwartzman, Yuliang Li, Michael Mitzenmacher, Minlan Yu, and Ran Ben-Basat. 2022. Francis: Fast reaction algorithms for network coordination in switches.arXiv preprint arXiv:2204.14138(2022)

  11. [11]

    Daniel Lehmann, Johannes Kinder, and Michael Pradel. 2020. Every- thing Old is New Again: Binary Security of WebAssembly. In29th USENIX Security Symposium (USENIX Security 20). USENIX Associa- tion, 217–234.https://www.usenix.org/conference/usenixsecurity20/ presentation/lehmann

  12. [12]

    Ruqi Liao, Chuqing Zhao, Jin Li, Weiqi Feng, Yi Lyu, Bingxian Chen, and Haochen Yang. 2025. Catp: Cross-attention token pruning for ac- curacy preserved multimodal model inference. In2025 IEEE Conference on Artificial Intelligence (CAI). IEEE, 1100–1104

  13. [13]

    Yi Lyu, Yiyin Shen, and Takashi Matsuzawa. 2026. Educational Data- base Prototype: the Simplest of All.arXiv preprint arXiv:2601.19165 (2026)

  14. [14]

    Yi Lyu, Shichun Yu, and Joe Catudal. 2026. Safeguard: Security Controls at the Software Defined Network Layer.arXiv preprint arXiv:2601.17355(2026)

  15. [15]

    2018.NCC Group Whitepaper - Security Chasms of W ASM

    Brian McFadden, Tyler Lukasiewicz, Jeff Dileo, and Justin En- gler. 2018.NCC Group Whitepaper - Security Chasms of W ASM. https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz- WebAssembly-A-New-World-of-Native_Exploits-On-The-Web- wp.pdf

  16. [16]

    Shravan Narayan, Craig Disselkoen, Daniel Moghimi, Sunjay Cauligi, Evan Johnson, Zhao Gang, Anjo Vahldiek-Oberwagner, Ravi Sahita, Hovav Shacham, Dean Tullsen, and Deian Stefan. 2021. Swivel: Hard- ening WebAssembly against Spectre. In30th USENIX Security Sympo- sium (USENIX Security 21). USENIX Association, 1433–1450.https:// www.usenix.org/conference/us...

  17. [17]

    Shravan Narayan, Tal Garfinkel, Sorin Lerner, Hovav Shacham, and Deian Stefan. 2019. Gobi: WebAssembly as a Practical Path to Library Sandboxing.CoRRabs/1912.02285 (2019). arXiv:1912.02285http: //arxiv.org/abs/1912.02285

  18. [18]

    Theo De Raadt. 2005. Exploit Mitigation Techniques at OpenCON 2005. InOpenCON 2005.http://www.openbsd.org/papers/ven05-deraadt/ index.html

  19. [19]

    2002.Four different tricks to bypass Stack- Shield and StackGuard protection

    Gerardo Richarte. 2002.Four different tricks to bypass Stack- Shield and StackGuard protection. Core Security Technolo- gies.https://www.coresecurity.com/sites/default/files/private-files/ publications/2016/05/StackguardPaper.pdf

  20. [20]

    Jian Sun, DingYuan Cao, XiMing Liu, ZiYi Zhao, WenWen Wang, Xi- aoLi Gong, and Jin Zhang. 2019. SELWasm: A Code Protection Mech- anism for WebAssembly. In2019 IEEE Intl Conf on Parallel Distributed Processing with Applications, Big Data Cloud Computing, Sustainable Computing Communications, Social Computing Networking (ISPA/B- DCloud/SocialCom/SustainCom)...

  21. [21]

    WebAssembly. 2021. WABT.https://github.com/WebAssembly/wabt

  22. [22]

    Lyu Yi, Weiqi Feng, Yuanbiao Wang, and Yuhong Kan. 2025. MonoM: Enhancing Monotonicity in Learned Cardinality Estimators.arXiv preprint arXiv:2512.22122(2025)

  23. [23]

    Lu Zhang, Weiqi Feng, Chao Li, Xiaofeng Hou, Pengyu Wang, Jing Wang, and Minyi Guo. 2021. Tapping into nfv environment for oppor- tunistic serverless edge function deployment.IEEE Trans. Comput.71, 10 (2021), 2698–2704

  24. [24]

    Lu Zhang, Chao Li, Xinkai Wang, Weiqi Feng, Zheng Yu, Quan Chen, Jingwen Leng, Minyi Guo, Pu Yang, and Shang Yue. 2023. First: Exploiting the multi-dimensional attributes of functions for power- aware serverless computing. In2023 IEEE International Parallel and Distributed Processing Symposium (IPDPS). IEEE, 864–874. Defending Buffer Overflows in WebAssem...