Oku's New Order Types Contract — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Oku's New Order Types Contract, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 10
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 10 closed, publicly disclosed Oku's New Order Types Contract reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Reentrancy, Logic error, Oracle manipulation, Access control, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Reentrancy findings disclosed against Oku's New Order Types Contract
- Logic error findings disclosed against Oku's New Order Types Contract
- Oracle manipulation findings disclosed against Oku's New Order Types Contract
- Access control findings disclosed against Oku's New Order Types Contract
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Oku's New Order Types Contract: attacker can drain StopLimit contract funds through Bracket contract because it gives type(uint256).max allowance to bracket contract for input token in performUpkeep function
Oku's StopLimit contract grants the Bracket contract an unlimited (type(uint256).max) ERC-20 allowance for the input token in its performUpkeep/updateApproval path, needed to fund the internal fillStopLimitOrder call. Because Bracket's own performUpkeep accepts an arbitrary target and txData from the order and executes it while holding that inflated allowance, an attacker who opens a readily executable Bracket order can point the external call at the token contract itself and invoke transferFrom from the StopLimit contract to Bracket, using the inherited StopLimit allowance as the transfer source. The resulting tokenOut balance increase passes Bracket's balance checks, and the drained amount is paid out to the attacker's chosen recipient. This lets any attacker drain nearly the entire balance of any token for which StopLimit has granted Bracket the maximum allowance; the protocol team fixed it by reducing the allowance to only the amount required per order.
Oku's New Order Types Contract: stopLimit Id collision with bracket orders due to no validation, opening up an attack to steal funds
Oku's parallel order creation between StopLimit.sol and Bracket.sol can collide on orderId because generateOrderId hashes only block.number and the user address, adding no contract-specific entropy. By creating a Bracket order and a StopLimit order for the same address in the same block, an attacker gets two orders sharing one orderId, then calls cancelOrder twice on it, receiving the larger refund twice and draining user funds. The protocol team confirmed the bug and fixed it by adding a per-source contract address plus a monotonic nonce into the ID generation.
Oku's New Order Types Contract: Malicious User can Poison Bracket.sol with Blacklisted Accounts
Oku's Bracket.sol orderbook lacks validation on the recipient address passed to createOrder, so an attacker can set the recipient to an address blacklisted by the underlying token (e.g. USDC). Because procureTokens pulls from msg.sender rather than the recipient, a non-blacklisted attacker can fund such an order. Once the order executes or is filled, _cancelOrder and adminCancelOrder try to send tokens back to the blacklisted recipient, which reverts with "Blacklistable: account is blacklisted", making the order uncancelable. By repeating this cheaply, an attacker can fill the pendingOrderIds array up to maxPendingOrders and also blow up gas in ArrayMutation.removeFromArray, permanently freezing parts of the orderbook (a protocol-wide DoS). The protocol acknowledged and fixed the issue via a validation check on recipients.
Oku's New Order Types Contract: Incorrect Freshness Logic Validation in PythOracle breaking the entire mechanism for triggering orders
Oku's new order-types contract uses a PythOracle wrapper whose freshness check is inverted: at line 29 it requires price.publishTime to be older than block.timestamp - noOlderThan, so every price is treated as stale no matter how fresh. Because trigger evaluation calls this check during order matching, valid stop-loss and take-profit orders never execute even when the oracle has just published a current price. The reporter demonstrates that a published price 5 seconds old fails a 30-second freshness window. This is a logic-error bug in the oracle integration affecting order availability rather than direct theft, fixed by flipping the comparison to require publishTime >= block.timestamp - noOlderThan.
Oku's New Order Types Contract: `cancelOrder` order can be DOSed due to unbounded loop.
Oku's OracleLess contract maintains a `pendingOrderIds` array that is scanned linearly from index zero by `_cancelOrder` until the target orderId is found. Because an attacker can cheaply append a large number of orders using a worthless token whose transfer always reverts, the array grows so large that legitimate cancels (including the admin's) exceed the block gas limit and become impossible, permanently locking users' funds in pending orders. The submitted Foundry PoC shows that roughly 20,800 spammed orders raise a normal cancel from ~9k gas to ~30M gas while costing the attacker only about $150. The protocol acknowledged the design flaw and merged a fix that allows cancellation via the array index.
Oku's New Order Types Contract: User can brick the `Bracket` contract by inputing malicious `txData`
A user can permanently brick the Bracket (and OracleLess) swap contracts by submitting a crafted txData during performUpkeep that consumes amountIn - 1 of the approved tokens, leaving a 1 wei residual allowance on the target. Because the system uses an outdated OpenZeppelin safeApprove that reverts on any non-zero-to-non-zero approval, every subsequent swap with the same tokenIn and target reverts at the approval step, locking users' funds in the contract. This is a griefing/denial-of-service vector reachable by any caller who can trigger performUpkeep, with no external preconditions. The fix, confirmed by a protocol PR, is to upgrade OpenZeppelin and use forceApprove.
All reports in this group
- Oku's New Order Types Contract: Failure to reset unspent approval to the target address will lead to the wiping of the smart contract balanceAccess control$0
- Oku's New Order Types Contract: Create order can be DOSed as there is no compulsory fee collected during the creation/cancellation of ordersLogic error$0
- Oku's New Order Types Contract: Malicious users can `createOrder` with `0 amount` and make `DOS` for allLogic error$0
- Oku's New Order Types Contract: Insecure calls to `safeTransferFrom` leads to users tokens steal by attackerAccess control$0