Entrar
Binance fixed the IP whitelist gap — but the disclosure process is still broken
I recently re-tested an old Binance API finding I had reported through Bugcrowd.
The original issue was about Binance API IP whitelisting and derived listenKey stream credentials.
At the time, a listenKey could be created from a whitelisted IP and then used from a non-whitelisted IP to consume private user data streams.
That did not allow trading, withdrawals, or account takeover.
But it did allow real-time access to sensitive private stream data such as balances, orders, executions, positions, timing, and strategy behavior.
The core security argument was:
A derived credential should not be more portable than the credential that created it.
The report was rejected as “Social Engineering” / “Not Applicable”.
I disagreed, because the relevant threat model was not “convince the user to send a token”.
The realistic threat model was supply-chain compromise: malicious code running inside a trusted bot server, CI job, dependency, IDE workspace, or trading environment where API keys already exist.
I re-tested the behavior on May 5, 2026.
Result:
The old behavior appears to be gone.
Spot and Margin no longer use the old listenKey model. Futures still uses listenKey, but now appears to enforce the API key IP whitelist correctly. From a whitelisted IP the calls worked; from non-whitelisted Mullvad exits they failed with the expected IP restriction error.
That is good for users.
But it raises an uncomfortable disclosure-process question:
If a finding is “not applicable” enough to reject, not acknowledge, and not reward — but technical enough to later fix — what should a healthy disclosure process do?
Full technical write-up, timeline, re-test setup, and raw outputs:
I am mainly interested in the process question here:
When a rejected report later disappears from production, should the program re-open it, acknowledge it, partially reward it, or leave it closed unless the researcher can prove direct causality?
[link] [comments]
