NOYA — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for NOYA, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 21
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 21 closed, publicly disclosed NOYA 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 Flash loan attack, Logic error, Oracle manipulation, 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
- Flash loan attack findings disclosed against NOYA
- Logic error findings disclosed against NOYA
- Oracle manipulation findings disclosed against NOYA
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
NOYA: A Vault can steal all funds from another Vault through the Registry's flash loan contract due to insufficient access control in `Connector.sendTokensToTrustedAddress()`
NOYA's `BaseConnector.sendTokensToTrustedAddress()` authorizes any caller whose address equals the Registry's shared `BalancerFlashLoan` contract, without verifying which Vault (or its keeper) initiated the flash loan. Since the flash-loan callback can direct calls to arbitrary destination connectors of other Vaults, the keeper of one Vault can craft a `makeFlashLoan()` call whose callback drains another Vault's connector into the attacker's connector, then repay the flash-loan principal and keep the stolen tokens. The write-up provides a full attack path across two Vaults and a Foundry PoC, and NOYA confirmed the issue and fixed it in two commits.
NOYA: `executeWithdraw` may be blocked if any of the users are blacklisted from the `baseToken`
NOYA's AccountingManager processes the withdrawal queue in a loop, transferring the base token to each queued receiver via safeTransfer. For blocklist-capable base tokens (USDC/USDT), if any receiver is on the token's admin-controlled blacklist (or is address(0), or triggers a 0-amount transfer), the transfer reverts and unwinds the entire loop, stalling withdrawals for every other user in the same group. An attacker can thereby trap other users' funds by having a blacklisted address queued as a receiver. The judge confirmed High severity, grouping this with the blocking deposit/withdrawal queue as a shared root cause, and the sponsor released a fix that skips blacklisted receivers.
NOYA: Incomplete TVL Calculation in `AerodromeConnector::_getPositionTVL` Function
NOYA's AerodromeConnector allows an authorized manager to stake LP tokens into an Aerodrome gauge, which transfers those tokens out of the connector and into the gauge contract. However, the connector's _getPositionTVL function only reads the LP-token balance still held by the connector itself and ignores whatever the connector has staked in the gauge, so the reported TVL for the position understates the vault's true holdings once tokens are staked. The finding was confirmed by the sponsor, who argued for Medium severity, but the judge finalized it as High Risk because the distorted TVL metric flows into share calculation and therefore propagates into shareholder accounting.
NOYA: `NoyaValueOracle.getValue` returns an incorrect price when a multi-token route is used
NOYA's NoyaValueOracle converts prices between token pairs and falls back to multi-hop routes when no direct oracle exists. In the multi-hop path, the internal _getValue loop repeatedly prices against the original `asset` rather than the running `quotingToken`, so each hop is quoted back to the source token instead of chaining through the route. Any configured route longer than one hop therefore either reverts with an unavailable-price error when the intermediate oracles are missing, or returns a mathematically wrong value when they exist (the disclosed example yields 526 instead of 2094). Since NOYA relies on these prices to value positions in its accounting and strategy system, the flaw allows mispriced collateral and distorted share valuations.
NOYA: Base tokens like USDT, USDC having different decimals on different chains can have their TVL updated incorrectly
NOYA aggregates vault TVL across EVM chains using LayerZero, where a peripheral 'normal chain' contract computes a TVL figure and relays it to the root 'base chain' contract, which stores it in a holding position. Because USDC/USDT carry 18 decimals on BSC but only 6 on the Base root chain, the relayed TVL is recorded unscaled, inflating the accounted asset value by roughly 1e12. When AccountingManager.totalAssets() (ERC4626) later loops over holding positions, vault share minting and related operations run against this overstated figure. The sponsor confirmed the finding and shipped a fix that normalizes cross-chain token decimals on the receive path.
NOYA: In Dolomite, when opening a borrow position, the holding position in the Registry will never be updated due to the `removePosition` flag being set to true
NOYA's Dolomite borrow connector sets the registry's removePosition flag to true both when opening and closing a borrow position. Because the registry's circuit-breaker returns type(uint256).max when a remove operation targets a position whose isPositionUsed entry was never initialized, a newly opened borrow is silently dropped and never recorded in the vault's holdingPositions array. Registry-driven strategy logic therefore has no visibility of the live borrow, which can cause missed repayments, forced liquidations, and accumulation of bad debt. The NOYA team confirmed the finding and the judge upgraded it to High, noting both the open and close borrow paths are impacted.
All reports in this group
- NOYA: `_getPositionTVL` of `UNIv3Connector` wrongly assumes ownership of all liquidity of the provided ticks inside `positionManager`Oracle manipulation$0
- NOYA: Value of asset token can be incorrect when usage of ETH/USD Chainlink oracle is neededOracle manipulation$0
- NOYA: Decreasing a position in PendleConnector will remove it even if there's still a stake at PenpieLogic error$0
- NOYA: `PrismaConnector` can mint a position below the desired health factorLogic error$0
- NOYA: Invalid calculation of position TVL in Pendle connectorLogic error$0
- NOYA: Numerous errors when calculating the TVL for the MorphoBlue connectorLogic error$0
- NOYA: `AccountingManager::resetMiddle` will not behave as expectedLogic error$0
- NOYA: SiloConnector `_getPositionTVL` miscalculate the TVL positionLogic error$0
- NOYA: `SNXConnector.sol` TVL calculation is incorrectLogic error$0
- NOYA: `Registry.sol#updateHoldingPosition` remove position logic is incorrect: should use `ownerConnector` instead of `calculatorConnector` when calculating `holdingPositionId`Logic error$0
- NOYA: `BalancerConnector` has incorrect implementation of totalSupply, positionTVL and total TVL will be invalidLogic error$0
- NOYA: Invalid handling of holding positions in `DolomiteConnector::transferBetweenAccounts`Logic error$0
- NOYA: `BalancerConnector::_getPositionTVL` is calculated incorrectlyLogic error$0
- NOYA: `PendleConnector` incorrectly sends the redeemed `PT` tokens to the marketLogic error$0
- NOYA: It is possible to open insolvent position in Silo connector, due to missing check in borrow functionLogic error$0