The contract has a potential edge case where users could claim more beans than intended if the beansPerFertilizer (bpf) value decreases between transactions.
The issue is in __update function, which calculates beans based on the difference between the current bpf and the last recorded bpf for each fertilizer ID. If the global bpf decreases, users could potentially claim beans multiple times for the same bpf range.
User claims again, but lastBpf is still 800, so no beans are claimed
bpf increases to 850
User claims (850 - 800) * 100 = 5,000 beans
In this scenario, the user has claimed for the 800-850 range twice.
Mitigation steps
Consider implementing a mechanism to track the highest bpf claimed for each fertilizer ID, rather than just the last bpf. This could be done by modifying the _balances struct:
While the situation you describe is possible in theory, in practice the value of bpf never decreases. The Fertilizer contract assumes the security and correctness of implementation in the Beanstalk contract, which is the only address that is allowed to call the __update function.
Thus, we are closing this report and no reward will be issued.