T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- funding_arbitrage.py:197
- Finding
- Undocumented Live Leveraged Trading Capability in a Monitoring Skill<![CDATA[ ## Vulnerability Details **File Location**: `funding_arbitrage.py:197-230` and `funding_arbitrage.py:356-367` **Vulnerability Type**: Undeclared privileged financial operations **Risk Level**: High ### Vulnerable Code The implementation can change account leverage and submit live market orders: ```python self._request('POST', '/fapi/v1/leverage', { 'symbol': symbol, 'leverage': self.PARAMS['leverage'] }, signed=True) order_side = 'BUY' if side == 'LONG' else 'SELL' params = { 'symbol': symbol, 'side': order_side, 'type': 'MARKET', 'quantity': quantity, 'positionSide': 'BOTH' } result = self._request('POST', '/fapi/v1/order', params, signed=True) ``` Direct execution of the module activates the rebalancing strategy: ```python def main(): trader = FundingRateArbitrage() trader.rebalance() if __name__ == '__main__': main() ``` ### Technical Analysis The package documentation and MCP tool manifest describe account monitoring functions that read balances, positions, and funding income. However, `funding_arbitrage.py` also contains executable trading functionality that: 1. Selects futures symbols based on funding rates. 2. Sets futures leverage to 10×. 3. Submits signed market orders to open long and short positions. 4. Submits reduce-only market orders to close positions. 5. Automatically invokes the strategy when the module is executed directly. These operations require substantially greater privileges than a monitoring-only skill. A Binance API credential configured with futures trading permission can therefore be used to modify the account and expose funds to leveraged market risk. The normal MCP server code does not invoke `rebalance()` or the order methods. Exploitation consequently requires direct execution of `funding_arbitrage.py`, or another local component importing the class and invoking those methods. Nevertheless, the sensitive capability is shipped in the monitoring package and is directly ...[truncated 1499 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove `open_position`, `close_position`, `rebalance`, and the direct strategy entry point from the monitoring package. 2. Separate monitoring and trading into independently distributed components with distinct names, manifests, and documentation. 3. Require users of the monitoring skill to create a Binance API key with read-only permissions and no futures trading or withdrawal privileges. 4. Add an explicit runtime check that rejects credentials or configurations intended for trading where the Binance API supports such validation. 5. If trading is an intended feature, require explicit opt-in configuration and interactive confirmation before every order. 6. Implement strict controls for maximum order value, aggregate exposure, leverage, supported symbols, and acceptable price deviation. 7. Add a dry-run mode enabled by default, with production trading requiring a clearly named setting such as `ENABLE_LIVE_TRADING=true`. 8. Update all documentation and manifests to disclose every account-modifying operation and the exact API permissions required. 9. Add automated tests verifying that the monitoring server cannot invoke any account-mutating Binance endpoint. ]]>