ReachMe.io Vulnerability: Saying Hi to CZ on a Budget

Yesterday, while I was still sorting through APT attack materials, Brother Shan (@im23pds) suddenly rushed over to my desk, excited: “Thinking, I found an interesting project that CZ is using heavily — maybe we can say Hi to CZ for zero cost.” We quickly brainstormed several potential vulnerability points:

• Hijacking CZ’s ReachMe account;
• Changing CZ’s ReachMe settings;
• Messaging CZ for free, bypassing the 1 BNB fee to send him a message.

About 10 minutes later, we discovered a vulnerability that allowed sending messages to any user on ReachMe.io at low cost. We immediately contacted the project team with detailed vulnerability verification. The project team quickly fixed the vulnerability and reached back out to us for retesting. Kudos to the ReachMe team for taking security seriously!

Additionally, the SlowMist Security Team was honoured to receive thanks from both CZ and the ReachMe project team.

Discovery Process

ReachMe.io is a paid messaging platform on BNB Chain, designed to connect KOLs (Key Opinion Leaders) with their followers through crypto payments. Users must pay BNB to send private messages to KOLs — KOLs receive 90% of the fee (the platform takes 10%); if the KOL does not reply within 5 days, the user can get a 50% refund.

On 27 March 2025, Binance founder CZ changed his X profile bio to: “DM: https://reachme.io/@cz_binance (fees go to charity)” — essentially saying “DM me on ReachMe, fees go to charity.”

As we could see, the cost to Say Hi to CZ was 1 BNB. So we came up with some approaches and started testing how to bypass the 1 BNB limit and Say Hi to CZ.

After some research with Brother Shan, we discovered that when sending a message to any KOL, ReachMe generates a message summary via the /api/kol/message endpoint, which contains an _id field. This field is passed to the on-chain contract Function: deposit(string _identifier, address _kolAddress) as the _identifier parameter.

The BNB attached when sending a message to a KOL is simply the amount of BNB sent when calling the contract’s Function: deposit. So we constructed a transaction with the _identifier corresponding to our “Hi CZ” message along with CZ’s address, and sent it to the contract with only 0.01 BNB (the minimum is just 0.001 BNB).

In about 10 minutes, we successfully bypassed the 1 BNB rule for messaging CZ — sending him a message for just 0.01 BNB.

Summary

Products that blend centralised and decentralised design often exhibit inconsistencies between on-chain and off-chain security checks. Attackers can exploit this by analysing the interaction flow between on-chain and off-chain components to bypass certain validation layers.

The essence of this vulnerability is a “consistency gap”: the frontend and backend assumed the KOL’s message price was controlled by the application layer and the contract only needed to process transfer records; but the server, when querying on-chain transactions, trusted the contract’s records by default without additionally verifying whether the BNB amount matched the price. This created an exploitable gap between “any amount can be deposited on-chain” and “you must pay the full fee to send a message off-chain.”

The SlowMist Security Team recommends that project teams synchronise necessary security checks across both on-chain and off-chain code wherever possible, to prevent bypass attacks. Additionally, we advise engaging professional security teams for security audits to identify and mitigate potential risks.