Cross-site request forgery is a risk to SecurePoll for reasons described in that link. However, the signal could be caused by benign issues like token timeouts, and this leads to confusion for scrutineers (see the recent task T426370, but it has certainly come up before).
I would recommend implementing a check for CSRF and just rejecting the vote immediately, asking the user to re-submit. This assumes CSRF is flagged immediately on submission of the vote and I'm not sure if that is the case.
See also work done in the recent past on this and other SecurePoll issues: T392341: CVE-2025-53483, CVE-2025-53484, CVE-2025-53485: SecurePoll is vulnerable to XSS, CSRF, and lack of authorisation