Results from the 2025 public intrusion test

For its e-voting solution, SwissPost ran a public intrusion test (PIT) from July 28 to August 24, 2025, on the Swiss Post e-voting infrastructure.

During the PIT the hunters submitted 26 reports:

• 0 reports concern cryptography-related issues in the cryptographic protocol and its specification.
• 0 reports concern source-code issues.
• 16 reports were accepted as informative for their insightful contribution.
• SwissPost and YwH did not accept 10 reports since they did not identify a vulnerability. Triaging reports are a standard process in bug bounty programs and we took decisions together with our partner YesWeHack.

SwissPost paid out €500.- to the bounty hunter who submitted the report #YWH-PGM2323-346.

The report on the results of the public intrusion test is available here. The PIT report summarizes the public intrusion test of the Swiss Post e-voting system, providing an overview of the test setup, participation, and results. Particular attention is given to communication with participants, the findings and reports from the test, and the detailed statistics and security metrics, which illustrate system activity, access patterns, and security performance.

Here, we describe only the informative finding rewarded as best practice. For the other informative findings, see the full report.

YWH-ID	Title	Description	Status	CVSS-severity
#YWH-PGM2323-346	Replay behaviour of invalid authentication attempts	Swiss Post’s authentication protocol requires two elements for successful authentication: Valid credentialID, derived from the 24-character Start Voting Key using the memory-hard Argon2id key derivation function and Valid authenticationChallenge, derived from the timestamp and the extended authentication factor. The hunter observed that replaying a request with a valid credentialId, but an invalid authenticationChallenge blocks the voting card after 5 attempts. To the hunter, this is in contradiction with the system specification’s statement: The stateful lists prevent a voting client from brute forcing the extended authentication factor and enforce one-time use of an authentication challenge as specified in RFC6238 [16]. To the hunter, this could lead to a scenario where an attacker could brute force the credentialId and attempt to block arbitrary voting cards. Identified thanks to ed2.	The fact that a voting card is blocked after 5 authentication attempts with a valid credentialId, but an invalid authentication challenge, is intended system behaviour, even in the case that the attacker replays the invalid authentication request. Brute-forcing the credentialId is computationally infeasible, given the large entropy of the Start Voting Key and the application of the memory-hard Argon2id key derivation function. Our authentication protocol prevents replaying successful authentication attempts (in line with RFC6238), but there is no value in preventing the replay of invalid authentication at-tempts. We will clarify the system specification to better highlight the system’s intended behaviour: The stateful lists prevent a voting client from brute-forcing the extended authentication factor and enforce one-time use of a successful authentication challenge as specified in RFC6238 [16]	informative

Information on confirmed findings in the other scopes of the e-voting community and bug bounty programme can be found here.