Repository navigation
Responsible disclosure: 8 P0 findings in trader/trading/ and trader/messaging/ (14-day window) #10
Description
Responsible Disclosure — 8 P0 findings in trader/trading/ and trader/messaging/
Hi @9600dev — I'm writing from Bell Operations LLC (a trading-bot audit service, currently in early operation). I audited 9600dev/mmr at commit 07559fb9 as part of our launch process — we pick well-known public repos and run our full review lane before taking paid clients.
This is a responsible-disclosure notice. We found 8 P0-severity bugs across two clusters. We are giving you a 14-day window (until 2026-06-05) before publishing a sanitized writeup. We are not asking for anything — just flagging what we found so you have the chance to patch first.
Cluster A — Order Execution (6 P0s)
| ID | Title | File:Line |
|---|---|---|
| M-01 | BUY debug discount double-applied — 19% realized instead of intended 10% | trader/trading/executioner.py:219-221 |
| M-02 | sanity_check_order is a no-op stub returning True unconditionally |
trader/trading/order_validator.py:29-43 |
| M-03 | MarketOrder defaults outsideRth=True — extended-hours wide-spread fills |
trader/trading/trading_runtime.py:836-837, proposal.py:47 |
| M-04 | STOP_LOSS exit path leaves entry live if SL leg fails to place | trader/trading/trading_runtime.py:1028-1073 |
| M-05 | connected_event double-fires on reconnect → duplicate subscriptions + double reqAllOpenOrders |
trader/trading/trading_runtime.py:529-534 |
| M-06 | No PDT-rule tracking — Reg-T 4-trades-in-5-days violation risk for sub-$25K margin accounts | repo-wide (no implementation) |
Cluster B — IPC Security (2 P0s) — exploitable today on non-loopback Docker deployments
| ID | Title | File:Line |
|---|---|---|
| M-07 | ZMQ RPC dispatch resolves methods via bare getattr with no _is_rpc_method whitelist — any co-resident process can call arbitrary attribute chains on the trader instance |
trader/messaging/clientserver.py:473-475 |
| M-08 | _safe_dill_loads policy defaults OFF (MMR_DILL_STRICT=1 not set) — full RCE via crafted msgpack EXT_OBJECT payload from any process that can reach the ZMQ socket |
trader/messaging/clientserver.py:83-95 |
Immediate recommendations
M-07 and M-08 are the highest urgency — they are exploitable on any deployment that doesn't restrict the ZMQ socket to strict loopback. The M-07 fix is one line:
assert getattr(callable_obj, '_is_rpc_method', False), f"Not an RPC method: {method_name}"For M-08, setting MMR_DILL_STRICT=1 in the environment closes the deserialization vector immediately without a code change.
M-01 and M-02 are the most operationally dangerous for real-money use — a validator that always returns True means no order sanity check fires before submission.
We will publish our full sanitized writeup on or after 2026-06-05. If you patch before then, we'll note it in the published report. Happy to answer questions or share additional detail on any finding.
— Bell Operations LLC (provisional) | trading-bot security audit service
Activity