Origami — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Origami, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 3
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 3 closed, publicly disclosed Origami reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Oracle manipulation, Logic error, Flash loan attack, 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
- Oracle manipulation findings disclosed against Origami
- Logic error findings disclosed against Origami
- Flash loan attack findings disclosed against Origami
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Origami: An attacker can bypass the dynamic fees in `lovStEth` vault under certain depeg conditions, and extract value from honest depositors
Origami's lovStEth leveraged staking vault relies on a dynamic-fee guard to deter users from depositing or withdrawing when the wstETH rate deviates from its historic peg. That guard is silently disabled for a range of conditions because the wstETH-to-ETH oracle returns the SPOT value for both the SPOT and HISTORIC price requests: it multiplies the always-current Lido getPooledEthByShares() result by the Chainlink stETH/ETH feed in both cases. As a result, when ETH/stETH sits at peg, the fee-calculated delta collapses to zero even if the stETH/wstETH component is depegged, so a depositor pays only the minimum fee while receiving extra shares. An attacker who backruns a Lido reward fluctuation to deposit at the favorable rate and exits after correction ends up with more wstETH than invested, with the shortfall carried by honest vault users.
Origami: hardcoding aave pool address is a serious aave integration flaw because valid pool addresses can change
OrigamiAaveV3FlashLoanProvider is a permissionless flashloan wrapper over an Aave/Spark flashloan pool. At deployment it reads the pool address from the PoolAddressesProvider and stores it in an immutable variable, permanently caching it. Because that address is immutable, if Aave ever migrates, deprecates, or swaps the pool contract via setPool on the PoolAddressesProvider, the wrapper permanently references a stale pool and its flashloan function stops working with no upgrade path. This is a design/integration-recommendation issue grounded in Aave's own guidance that pool addresses should be queried fresh from the addresses provider on every use. There is no attacker-controlled exploit path and no user funds are at risk in the described scenario; the impact is a hypothetical permanent denial of the wrapper's flashloan capability contingent on future Aave admin action.
Origami: Adversary can block any `exit` due to `preCheck` reached `cap` by using flash-loan
Origami's circuit breaker enforces a rolling daily cap on ovUSDC redemptions via preCheck, which both validates the rolling-period total and writes the exit amount into the active time bucket. Because the breaker cannot distinguish organic user exits from flows an attacker creates in the same transaction, an attacker can flash-loan USDC, mint oUSDC at a frictionless 1:1 (no fee), and redeem all shares in one transaction, instantly exhausting the cap. Once full, every legitimate exit and protocol rebalance reverts with CapBreached until the rolling window rolls over, yielding a repeatable, essentially free denial-of-service against all normal redemptions.