Solidity中短地址攻击是否已无法实现？

核心原因：工具链与客户端的输入验证强化 #

短地址漏洞本质是EVM层未验证地址长度，但你遇到的错误来自前端/SDK/节点客户端的前置校验，而非Solidity本身的更新：

• 现代以太坊客户端（如Geth、Nethermind）处理交易时，会先校验地址格式：必须是20字节（40个十六进制字符），不符合的直接拒绝，不会发送到EVM执行。
• 主流开发工具（Hardhat、Truffle、Foundry）及Web3.js/Ethers.js等SDK，在构建交易或ABI编码时，都会强制校验地址合法性，自动拦截短地址输入。

Solidity层面的变化 #

Solidity本身从未针对短地址漏洞做语法层面修复，因为该漏洞不属于合约代码逻辑问题。但后续版本有相关类型校验强化：

• 从Solidity 0.5.0开始，引入更严格的类型检查，address类型变量在编译时会被强制要求符合标准格式，但这只是编译期校验，而非运行时阻止短地址传入（若能绕过客户端校验）。
• 运行时层面，EVM依然允许短地址被传入合约，但现在几乎没有工具会让你绕过前置校验触发该场景。

成功复现短地址漏洞的方法 #

要绕过现有校验，需手动构造不符合标准格式的交易：

1. 直接构造原始交易数据：手动ABI编码函数调用，故意将地址参数截断为小于20字节的长度（比如19字节，后面补零），再通过低级API发送交易（比如用eth_sendRawTransaction直接提交原始签名交易）。
2. 使用旧版本工具：比如早期版本的Web3.js（v0.x系列），这类版本没有强制地址校验；或使用支持关闭地址格式校验的私有链客户端。

注意：短地址漏洞的触发需要接收方合约在处理地址时自动补全缺失字节（通常补零），从而篡改实际指向的地址，比如将19字节的0x1234...补全为0x1234...00，若能绕过前置校验，合约依然会按补全后的地址执行逻辑。

内容的提问来源于stack exchange，提问作者RodrigoR