Due to the implementation of _setDomainSeperator() used in the constructor of EIP712Base using the current chainId, in the case of a hard fork, all signed permits from Polygon can be replayed on the forked chain. Problem comes from the fact that chainId is not dynamically set/not cached when building the typed message hash.
There is always a possibility of a blockchain undergoing a hard fork, as seen previously with Ethereum. In the event of a hard fork, the chainID will change. If a contract continues to use the old chainID in its domainSeparator, the domain separator will become invalid. This could expose valid signatures to replay attacks across both chains. A signature replay attack on the forked chain means that any valid signature on one of the chains can be re-used on the other as long as the account nonce is respected.
Signature replay leading to unexpected results and potential loss of funds.
Manual review.
Consider caching the chainId at the time of deployment and verifying it each time toTypedMessageHash() is called by comparing it to block.chainId. If the cached chainId matches block.chainId, proceed with execution as normal. If they differ, update the cached chainId and rebuild the domainSeparator to ensure signatures remain valid and protected against replay attacks across chains.
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.