漏洞标题
[BUG BOUNTY] [Medium] [TRON] Address validation accepts non-TRON Base58Check addresses
受影响模块
- ME-Hub
- 官方 Phase 1 范围映射：ME Hub（结算层）/ Gravity 模块跨链桥资金安全问题（BSC/TRON 代码仅作 Gravity 参考研究）
- 建议等级：Medium / 中
漏洞描述
该 issue 针对 Meta Earth Bug Bounty Phase 1 的 ME Hub（结算层）范围提交。核心问题、影响面、受影响代码、PoC 与修复建议见下方“原始技术报告”。
复现步骤
- 使用当前 openmetaearth/me-hub 测试网源码或等价本地开发环境。
- 按下方“Proof of Concept / PoC / Minimal reproduction”章节中的测试文件、命令和步骤执行。
- 对比下方记录的 observed failure / observed result 与 expected behavior。
PoC（中危及以上必填）：已在下方原始报告中提供本地 Go 回归测试、执行命令与失败输出；低危条目也尽量保留可复现命令。
环境信息
- 测试范围：ME Network testnet / ME Hub 结算层源码级可复现 PoC。
- Chain ID：mechain_900-1。
- 测试网区块高度：3590762（通过 http://118.175.0.244:26657/status 在 2026-05-28 Asia/Shanghai 查询，仅作为公开测试网环境标识；漏洞复现以本地 PoC 命令为准）。
- Tx Hash：N/A（本地确定性 PoC；如需公共测试网交易，可按复现步骤广播）
- 是否可稳定复现：是，见下方 PoC 命令与 observed output。
- Reporter GitHub：yuzhiyang1。
- MEC Address：me1p8u5377smm8zkfq9dmcg6prwflap0ndj4ht34z。
- Contact：1585004297@qq.com / @y_zhiy。
- 安全边界：未测试主网，未攻击第三方服务，未使用社工方式。
原始技术报告
TRON address validation accepts non-TRON Base58Check addresses
Summary
ValidateTronAddress checks length and Base58Check checksum, but it never verifies that the decoded address starts with TRON's 0x41 network prefix. As a result, non-TRON Base58Check addresses with the same 34-character length, such as a Bitcoin P2PKH address, are accepted as valid TRON bridge addresses.
Reward address: me1p8u5377smm8zkfq9dmcg6prwflap0ndj4ht34z
Impact
Bridge messages that rely on TRON external-address validation can accept addresses from another Base58Check network.
The conversion helpers then drop the first byte:
return tronAddr.Bytes()[1:]
If the first byte is not TRON's 0x41, the system still maps the remaining 20-byte payload into an internal account/hex address. This can cause:
- funds or bridge operations to be routed to an unintended TRON address derived from another chain's address payload;
- malformed or non-executable TRON bridge transactions;
- user-facing validation bypass where an address that is not a TRON address is accepted as a TRON destination or relayer external address.
Affected code
x/tron/types/address.go
ValidateTronAddressExternalAddrToAccAddrExternalAddrToHexAddr
Root cause
Current validation:
tronAddr, err := common.DecodeCheck(address)
if err != nil {
return errors.New("doesn't pass format validation")
}
expectAddress := common.EncodeCheck(tronAddr)
if expectAddress != address {
return fmt.Errorf("mismatch expected: %s, got: %s", expectAddress, address)
}
return nilThis verifies the checksum, but it does not check:
tronAddr[0] == tronaddress.TronBytePrefix // 0x41
Proof of concept
I added this regression test case:
x/tron/types/address_test.go
{
testName: "base58check address with non-tron network prefix",
value: "1BoatSLRHtKNngkdXEeobR76b53LETtpyT",
expectPass: false,
errStr: "wrong tron network prefix",
},Run:
go test ./x/tron/types -run TestValidateTronAddress/base58check -count=1 -v
Observed result:
Error: An error is expected but got nil.
Messages: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT
FAIL github.com/openmetaearth/me-hub/x/tron/types
The test input is a valid Base58Check address, but it is not a TRON address. Current code accepts it.
Recommended fix
After DecodeCheck, explicitly require the TRON network prefix:
if len(tronAddr) != 21 || tronAddr[0] != tronaddress.TronBytePrefix {
return errors.New("wrong tron network prefix")
}Apply the same check before ExternalAddrToAccAddr and ExternalAddrToHexAddr drop the first byte, or call the validated conversion helper from those functions.
Classification
- Severity: Medium
- CWE: CWE-20 (Improper Input Validation)
- Affected module:
x/tron
- Affected bridge fields: TRON destination, fee receiver, token contract, and external relayer address validation paths
漏洞标题
[BUG BOUNTY] [Medium] [TRON] Address validation accepts non-TRON Base58Check addresses
受影响模块
漏洞描述
该 issue 针对 Meta Earth Bug Bounty Phase 1 的 ME Hub（结算层）范围提交。核心问题、影响面、受影响代码、PoC 与修复建议见下方“原始技术报告”。
复现步骤
PoC（中危及以上必填）：已在下方原始报告中提供本地 Go 回归测试、执行命令与失败输出；低危条目也尽量保留可复现命令。
环境信息
原始技术报告
TRON address validation accepts non-TRON Base58Check addresses
Summary
ValidateTronAddresschecks length and Base58Check checksum, but it never verifies that the decoded address starts with TRON's0x41network prefix. As a result, non-TRON Base58Check addresses with the same 34-character length, such as a Bitcoin P2PKH address, are accepted as valid TRON bridge addresses.Reward address:
me1p8u5377smm8zkfq9dmcg6prwflap0ndj4ht34zImpact
Bridge messages that rely on TRON external-address validation can accept addresses from another Base58Check network.
The conversion helpers then drop the first byte:
If the first byte is not TRON's
0x41, the system still maps the remaining 20-byte payload into an internal account/hex address. This can cause:Affected code
x/tron/types/address.goValidateTronAddressExternalAddrToAccAddrExternalAddrToHexAddrRoot cause
Current validation:
This verifies the checksum, but it does not check:
Proof of concept
I added this regression test case:
x/tron/types/address_test.go{ testName: "base58check address with non-tron network prefix", value: "1BoatSLRHtKNngkdXEeobR76b53LETtpyT", expectPass: false, errStr: "wrong tron network prefix", },Run:
go test ./x/tron/types -run TestValidateTronAddress/base58check -count=1 -vObserved result:
The test input is a valid Base58Check address, but it is not a TRON address. Current code accepts it.
Recommended fix
After
DecodeCheck, explicitly require the TRON network prefix:Apply the same check before
ExternalAddrToAccAddrandExternalAddrToHexAddrdrop the first byte, or call the validated conversion helper from those functions.Classification
x/tron