# reqID_pendingAutomationOrder stores the index of the trade, which could point to a different trade since the request was created Low/Info · Three Sigma · RWA perpetuals DEX · 19th February, 2024 Finding 3S-OS-L06 of the Ostium security review. - Protocol: https://www.ostium.com/ - Report: /reports/ostium - Source: https://cdn.sanity.io/files/qoqld077/production/a95b9c69e0f65d1d6b0e649f0d62a362358ca8ce.pdf --- ### Description reqID_pendingAutomationOrder store the trader, pairIndex and index. index points to the trade in OstiumTradingStorage::openTrades, but the trade itself may have changed since the OstiumPriceUpKeep automation was requested. A possible scenario is, for example, triggering a take profit, then closing the trade immediately and creating a new trade on index 0 before the first callback was triggered. Note: this is also true for open limit orders, it should also check if the a.orderId matches the corresponding limit order. The easiest way to fix this is adding a orderId field to OpenLimitOrder which is filled when OstiumTrading::executeAutomationOrder() [requests](https://github.com/0xOstium/smart-contracts-threeSigma/blob/audit-feedback/src/OstiumTrading.sol#L470) a price. ### Recommendation To avoid this problem, [OstiumTradingCallbacks::executeAutomationCloseOrderCallback()](https://github.com/0xOstium/smart-contracts-threeSigma/blob/audit-feedback/src/OstiumTradingCallbacks.sol#L319) and [OstiumTradingCallbacks::closeTradeMarketCallback()](https://github.com/0xOstium/smart-contracts-threeSigma/blob/audit-feedback/src/OstiumTradingCallbacks.sol#L191) should validate a.orderId against [OstiumTradingStorage::openTradesInfo.tradeId](https://github.com/0xOstium/smart-contracts-threeSigma/blob/audit-feedback/src/OstiumTradingStorage.sol#L39). ### Status Acknowledged --- Related findings: - [`createCommonProjectIDAndDeploymentRequest()` hardcodes request id index to 0, leading to lost requests for users](https://0xsimao.com/findings/crestal-network-common-project-hardcodes-index): Crestal Network