ReachMe 漏洞怎么绕过的？付 0.01 BNB 就能发 1 BNB 的私信

免费的交易所推荐：

• 欧易交易所 >>>进入官网<<< >>>官方下载<<<
• 币安交易所 >>>进入官网<<< >>>官方下载<<<

ReachMe 漏洞复盘：为什么 0.01 BNB 就能绕过 1 BNB 的私信限制？

事情是怎么开始的：CZ 用 ReachMe，安全人员发现了问题

在一次安全调研中，研究人员发现了一个非常典型的 Web3 安全问题。当时，币安创始人 CZ 正在频繁使用一个叫 ReachMe 的付费聊天平台，用户要给他发私信，需要支付 1 BNB。这个“高门槛”听起来很安全，但研究人员很快就意识到，它可能只是摆了个样子。

具体来说，他们反复在想几个问题：

• 有没有可能直接控制 CZ 的 ReachMe 账号？
• 能不能篡改 CZ 在平台上的设置？
• 最关键的是，有没有办法绕过“最低 1 BNB”的限制，用更少的钱直接发消息？

仅仅花了 10 分钟快速验证后，结果就出来了：ReachMe.io 确实存在一个漏洞。用户可以用远低于标价（比如 0.01 BNB）的成本，给任何目标发送私信。发现问题后，他们立刻告诉项目方，而 ReachMe 团队也很快修复并邀请他们重新测试，整个响应速度还算不错。

顺便一提，慢雾安全团队也因此得到了 CZ 和 ReachMe 项目方的感谢。

产品是怎么运作的：ReachMe 的付费聊天模式

ReachMe.io 是一个基于 BNB Chain 的付费聊天平台。简单理解，它就是一个连接网红（KOL）和粉丝的聊天工具，只不过有个硬性规定：粉丝要发消息，必须得先付一些加密货币。

当时设计是这样的：用户给 KOL 发一条私信需要支付 BNB，其中 KOL 拿 90%，平台抽 10%。如果 KOL 过了 5 天还一直没回复，用户可以申请退回 50% 的费用。

2025 年 3 月 27 日，CZ 甚至还把他在 X 平台上的简介改成了“DM: https://reachme.io/@cz_binance (fees go to charity)”，意思是通过 ReachMe 发的私信费用会捐给慈善机构。

页面上写得很清楚：给 CZ 发一条消息要 1 BNB。但研究人员一开始就在问一个核心问题：这个 1 BNB 的门槛，是仅仅在页面上写着，还是已经在智能合约里真正锁死了？

漏洞到底怎么操作的：付 0.01 BNB 就发出原本要 1 BNB 的消息

研究人员深入分析后发现，用户要给某个 KOL 发送消息时，会经过一个接口：/api/kol/message。这个接口会生成一条“消息摘要”，里面有个叫 _id 的字段。然后系统会调用智能合约的 deposit(string _identifier, address _kolAddress) 函数，这个 _id 就当作参数传进去。

与此同时，用户发送时附带多少 BNB，实际上就是调用合约时附带的 BNB 数量。问题就在这：消息的唯一标识和支付的金额虽然放在同一个交易里，但系统没有真正去检查“你付了这么多钱，是不是符合要求”。

于是，研究人员构造了一个巧妙操作：他们只在合约里提交了“Hi CZ”这条消息对应的 _identifier 和 CZ 的地址，附带的 BNB 就只有 0.01 BNB。文章还提到，理论上最低甚至可以减到 0.001 BNB。

问题本质：价格限制只是“看起来有”，链上完全没有校验

这个漏洞的设计逻辑其实并不复杂，但很典型。当时 ReachMe 的实现里，KOL 预设的消息价格（比如 1 BNB）并没有被写入智能合约，链上根本不会检查“你实际付了多少”。所以，用户完全可以：修改前端代码、篡改网络响应包、或者干脆直接和智能合约交互，绕过页面上显示的价格。

换句话说，页面上写着“发消息需要 1 BNB”，但合约本身并没有说“你付了不到 1 BNB 就不让你发”，那这条规则本质上就只是一个展示信息，而不是真正不可绕过的执行约束。

更严重的是，服务端在从链上抓取交易记录时，也没有去核对“消息标价是多少”和“实际支付了多少”是否一致。这样一来，核心限制实际上全留在前端展示和链下流程，完全没能在链上形成闭环。

正是因为这个原因，研究人员只花了 10 分钟，就绕着弯子把“向 CZ 发消息要 1 BNB”的规则给绕过去了，最后只用了 0.01 BNB 就完成了发送。

风险到底有多大：不止是价格被绕过，安全问题更严重

对于付费私信工具这类产品来说，核心卖点就是“用钱筛选信息、减少骚扰、提高效率”。如果价格校验没有真正落在链上，那整个机制就形同虚设，付费门槛也失去了约束力。

不仅如此，文章中提到了一个更危险的场景：攻击者可以利用“低成本发消息”的能力，向高影响力目标投递钓鱼链接或诱导内容。考虑到 CZ 的高关注度，研究人员没有继续往这个方向深入测试，但思路已经很清楚了。

对于普通用户来说，这个案例给我们一个重要提醒：在 Web3 产品、区块链社交应用或链上支付场景里，页面上写的规则，不等于已经在链上被执行了。前端展示、服务端逻辑、智能合约，它们是完全不同的控制层，只要其中一个层面校验缺失，就有可能被利用。

所以，不论是用资产工具、和智能合约交互，还是看陌生地址发来的消息，都要记得多留一个心眼：这份“规则”到底是谁在执行？它真的能约束所有人吗？

设计上的教训：Web3 付费社交产品的安全短板怎么补

这类同时依赖中心化服务和链上合约的产品，最容易出现的风险就是“链上校验”和“链下校验”不一致。对于付费聊天、付费社交、KOL 互动和链上消息系统来说，关键约束——价格、身份、权限、退款条件——理论上都应该在链上和链下保持一致。

从 ReachMe 这个案例来看，如果项目方只依赖前端或服务端做限制，没有把关键检查写进合约，那攻击者很容易通过分析交互流程找到绕过的路径。相对更稳妥的做法是：链上和链下同步校验、关键参数强绑定、服务端补充核验，以及后续进行审计和复测。

总结：这起事件是典型的 Web3 安全案例，值得所有用户看一下

整体来说，这篇案例讨论的是“如何用远低于原价的金额绕过私家消息的价格限制”。它把事件背景、产品机制、漏洞发现过程、问题成因和潜在风险都梳理得比较清楚。对于关心区块链安全、Web3 产品设计、链上交互逻辑的新手来说，这是一个很好的学习素材：很多时候，页面上的“限制”并不代表实际上的“保护”。

需要再次强调：本文内容仅用于安全研究和案例分析，不构成任何投资建议或操作建议。对于 Web3 用户来说，在使用类似产品时，除了关注功能体验，也要留一份心：它的安全机制真的落实在代码层面了吗？对可疑信息和低门槛的“优惠”保持基本警惕，总是错不了的。