The LibShipping::ship() function is public, allowing any user to initiate the distribution process of BEAN across predefined shipment routes. However, if all shipment routes are configured with zero points (for example: for pausing the distribution of resources, emergency brake, strategic planning etc.), indicating no distribution should occur, the function still emits a Shipped event with the total number of Beans intended for distribution (beansToShip). This behavior lead to misinformation among users and external systems monitoring the contract's events, as it falsely suggests that a distribution of BEAN has occurred.
The core of the vulnerability lies in the ship function's logic, specifically in the unconditional emission of the Shipped event at the end of its execution. Despite the function correctly handling the scenario where all shipment routes have zero points (thus not distributing any Beans), it does not differentiate this case when emitting the Shipped event. As a result, the event is emitted with the full amount of BEAN that were supposed to be shipped, even though no actual distribution took place.
Users who monitor the Shipped event to keep track of BEAN distributions might be deceived into thinking that a distribution has taken place when, in reality, no BEAN have been distributed. This misunderstanding becomes particularly problematic considering that the Beanstalk system enables users to delegate actions to others based on specific scenarios through the use of the Tractor. Consequently, the inaccurate emission of events can trigger erroneous delegated actions.
Manual review
Modify the ship function to include a condition for emitting the Shipped event ensuring that the event is only emitted if at least one shipment route results in an actual distribution of BEAN.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.