Beedle - Oracle free perpetual lending

Summary

The Staking.sol contract collects user deposits of an ERC20 token, staking them for a WETH reward. It uses a global index to track rewards and 2 mappings to track user supplies and claimable rewards. Due to the lack of documentation, leading to the assumption that any ERC20 can be used as a staking token, a flashloan manipulation of the index is possible.

Vulnerability Details

A malicious user can use a combination of a flashloan + their own tokens to choose how much to move the index variable, essentially manipulating his earnings upon a new WETH refill (I will refer to this as an epoch for simplicity).
The attack works by providing a large amount of tokens from the flashloan + a tiny bit of the attackers own tokens.
For simplicity, let's assume the contract has just deployed, initial WETH supply would be 100 and each epoch will add 10, the attacker is the initial depositor for whom the index would be 0. The great inflation of the totalSupply would result in a low first index, setting the attacker's supplyIndex to that low index value. Upon withdrawal of the flashloan, since there's no new epoch, the supplyIndex and index remain unchanged, the user leaves a bit of his own tokens inside the contract to bypass the if (_supplied > 0) check.
What's left to do for the attacker is to backrun a new epoch, deposit a little amount (e.g 1), to not cause a great increase in the totalSupply, upon which the index would greatly increment and he will wield a ton of rewards.

I provide a gist with the written POC, which shows that the initial depositor by front-running + back-running + flashloan, with the assumption of 100 initial WETH and 10 WETH per epoch, can generate 9 WETH of claimable rewards with as little as 12 of his own tokens, almost draining the new epoch.
POC: IndexPOC.sol

Impact

A user is able to greatly increase his own rewards.

Tools Used

Manual Review

Recommendations

The issue arises from the flashloan possibilities of the staking token, which isn't specified anywhere. A proper mitigation would be to implement a commit-reveal when refilling the WETH balance of the contract, so it would be harder to back-run and manipulate the index.