Summary

Do note that signatures are being used incase an organizer wants to sign someone to help them with a tx, now do note the current way this would work is that

The organizer can use meta transaction to send signature to someone else to deploy proxy or distribute prizes to winners.

Vulnerability Detail

See summary, additionally do note that even if someone is trusted, current signature verification does not include what chain the meta data has been signed to.

Now note that SparkN is to be deployed on different chains i.e in a case where an organizer signs for a deployment to be made on a different chain and someone else replays this on another chain this would be valid, now note that, the CodeFox team already specified that funds would only get transferred after the creation of a contest, i.e the organizer sends funds to the contract later on after the deployment of the contract.

Additionally as I understand it from the SparkN's contest onboarding video the teams have hinted that the meta transactions are implemented to help non-tech savvy users, what this means is that when this deployment gets replayed on another chain, the not really tech savvy organizer might not even find out, and that means they won't send the funds for that specific deployment on that chain or even be aware to inform CodeFox/SparkN, effectively affecting their reputation, as contestants in the future would easily see that organizer has once set up a contest without providing the funds for the contest

Impact

I believe impact is High, since this is easily possible and could easily affect non-tech savvy users reputation, since one bad would completely render all the good things they've done not reputable enough

Tool used

Manual Audit

Recommendation

Signatures generally should include the chain that they are meant for this should be the case for SparkN

Additional Note

The below has been attached from the security considerations of the EIP712 that's being inherited

Replay attacks
This standard is only about signing messages and verifying signatures. In many practical applications, signed messages are used to authorize an action, for example an exchange of tokens. It is very important that implementers make sure the application behaves correctly when it sees the same signed message twice. For example, the repeated message should be rejected or the authorized action should be idempotent. How this is implemented is specific to the application and out of scope for this standard.