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.