Hi all,

I’ve published a technical case study analyzing a design issue in how the Binance API enforces IP whitelisting. This is not about account takeover or fund theft — it’s about a trust-boundary mismatch between the API key and the secondary listenKey used for WebSocket streams.

Summary of the issue

• A listenKey can be created using only the API key (no secret, no signature).
• The API key is protected by IP whitelisting.
• The listenKey is not protected by IP whitelisting.
• Once a listenKey leaks anywhere in the toolchain — debug logs, third-party libraries, bots, browser extensions, supply-chain modules — it can be reused from any IP address.
• This exposes real-time trading activity, balances, open orders, leverage changes, stop levels, liquidation events and more.

This is not a direct account compromise.
It’s market-intelligence leakage, which can be extremely valuable when aggregated across many users or bot frameworks.

Why this matters

Many users rely on IP whitelisting as their final defensive barrier. The listenKey silently bypasses that assumption. This creates a false sense of security and enables unexpected data exposure patterns that users are not aware of.

Disclosure process

I responsibly reported this and waited ~11 months.
The issue was repeatedly categorized as “social engineering,” despite clear architectural implications. Therefore, I have published the analysis openly.

Full case study

🔗 https://technopathy.club/when-ip-whitelisting-isnt-what-it-seems-a-real-world-case-study-from-the-binance-api-816c4312d6d0