EDITION_MANAGER_ROLE or EDITION_PUBLISHER_ROLE may spam an Edition with lots of unusable works.
Summary
Due to data invalidation, EDITION_MANAGER_ROLE or EDITION_PUBLISHER_ROLE (restricted roles) may spam an Edition with lots of unusable works. These works may render a very bad UI experience to users.
Vulnerability Detail
Let's assume an Edition has been properly and honestly created. After the Edition matures and roles are given to different users to become the EDITION_PUBLISHER_ROLE or the EDITION_MANAGER_ROLE, there might be a malicious user that may use any of those restricted roles to spam an Edition with multiple works that are unusable by doing one of the following:
Publishing a work with maxSupply equal 0, meaning that any token for that work might not be _issued.
Publishing a work with opensAt property being bigger than closesAt property, since this is not checked when a work is published in an Edition - which is going to make it so that any token won't be _issued.
Even if a solution to these two problems above is found, a work's creator may easily set the opensAt to be bigger (or equal to) than closesAt using the setTimeframe function - where no validation for opensAt>closesAt is made as well.
The problem becomes even bigger if there are no fees to be paid for publishing works.
Impact
There are multiple impacts to this issue. A malicious user with the right role might spam an Edition, making it lose its reputation - and consequently, making the Edition's owner lose credibility. Also, the lack of validation on inputs may impact the protocol's UI, undermining users' trust in the protocol. For clarity, imagine a user that sees an Edition whose works have an end date that is already past, but that is yet to start?
Code Snippet
The bugs are found in the following lines.
No check whatsoever inside the _publish function or before it when:
Add validation on work.maxSupply being at least a minimum threshold
Add validation for work.opensAt being smaller than work.closesAt when publishing in an Edition's creation in TitlesCore, in a work's publishing inside an Edition and inside the setTimeframe function.
caiosapy
medium
EDITION_MANAGER_ROLE or EDITION_PUBLISHER_ROLE may spam an Edition with lots of unusable works.
Summary
Due to data invalidation, EDITION_MANAGER_ROLE or EDITION_PUBLISHER_ROLE (restricted roles) may spam an Edition with lots of unusable works. These works may render a very bad UI experience to users.
Vulnerability Detail
Let's assume an Edition has been properly and honestly created. After the Edition matures and roles are given to different users to become the EDITION_PUBLISHER_ROLE or the EDITION_MANAGER_ROLE, there might be a malicious user that may use any of those restricted roles to spam an Edition with multiple works that are unusable by doing one of the following:
maxSupply
equal 0, meaning that any token for that work might not be_issue
d.opensAt
property being bigger thanclosesAt
property, since this is not checked when a work is published in an Edition - which is going to make it so that any token won't be_issue
d.opensAt
to be bigger (or equal to) thanclosesAt
using thesetTimeframe
function - where no validation foropensAt
>closesAt
is made as well. The problem becomes even bigger if there are no fees to be paid for publishing works.Impact
There are multiple impacts to this issue. A malicious user with the right role might spam an Edition, making it lose its reputation - and consequently, making the Edition's owner lose credibility. Also, the lack of validation on inputs may impact the protocol's UI, undermining users' trust in the protocol. For clarity, imagine a user that sees an Edition whose works have an end date that is already past, but that is yet to start?
Code Snippet
The bugs are found in the following lines.
No check whatsoever inside the
_publish
function or before it when:No validation (besides the sender being the work's creator) on the supposed timestamps in https://github.com/sherlock-audit/2024-04-titles/blob/main/wallflower-contract-v2/src/editions/Edition.sol#L401-L410
No validation for maxSupply is made of
maxSupply
being set as 0 upon publishing to avoid nobody minting tokens for a certain work on an Edition since the_updateSupply
function would revert ifwork.maxSupply
is 0 https://github.com/sherlock-audit/2024-04-titles/blob/main/wallflower-contract-v2/src/editions/Edition.sol#L494-L498Tool used
Manual Review
Recommendation
work.opensAt
being smaller thanwork.closesAt
when publishing in an Edition's creation in TitlesCore, in a work's publishing inside an Edition and inside the setTimeframe function.