For its e-voting solution, SwissPost ran a public intrusion test (PIT) from July 06 to July 24, 2026, on the Swiss Post e-voting infrastructure. In 2026, Swiss Post ran the PIT in a hybrid format. This hybrid format combines an open test (standard PIT) with a controlled, extended test (PIT+). Both test tracks were operated in parallel on the same infrastructure. During the public intrusion test (PIT and PIT+) the hunters submitted 85 reports: * 0 reports concern cryptography-related issues in the cryptographic protocol and its specification. * 6 reports concern source-code issues. * 46 reports were accepted as _informative_ for their insightful contribution. * SwissPost and YwH did not accept 33 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. In total, SwissPost paid out €38'400.- rewards to the hunters who submitted the reports. The **report on the results of the public intrusion test** is available [here](https://gitlab.com/swisspost-evoting/e-voting/e-voting-documentation/-/blob/master/Reports/PublicIntrusionTest/PIT_FinalReport_SwissPost_2026_EN.pdf?ref_type=heads). 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. Information on confirmed findings in the other scopes of the e-voting community and bug bounty programme can be found [here](https://gitlab.com/swisspost-evoting/e-voting/e-voting-documentation/-/work_items/79). ## Findings affecting the availability of the voting server <table> <tr> <th align="center">YWH-ID</th> <th>Title</th> <th>Description</th> <th>Status</th> <th align="center">CVSS-severity</th> </tr> <tr> <td align="center">#YWH-PGM2323-1597</td> <td>Cache Poisoning in Encryption Group Handling Causes Voting Server Availability Impact</td> <td> The report identifies an availability issue in the voting server. <br><br>Requests to the sendVote and con-firmVote endpoints can cause new encryption group fixedbase table caches to be instantiated before authenti-cation is completed. By submitting requests with different valid encryption groups, an attacker can consume significant memory and potentially cause the voting server to run out of memory and restart. <br><br>Following a restart, an attacker can further poison the cache by submitting an encryption group with the expected modulus p but a different generator g, before the legitimate election group has been loaded. Since the cache is keyed only by p, subsequent requests using the legitimate encryption group are rejected because the cached parameters do not match. The issue can therefore prevent legitimate voting operations on an affected voting server instance until the cache is cleared or the instance is restarted. <br><br>The finding affected the availability of the voting server but did not impact vote integrity, vote secrecy or cryptographic correctness. The 5168 requests with status code 412 “Precondition Failed” are mostly attributable to the finding #YWH-PGM2323-1597. <br><br> Identified thanks to `Hanno Kolvenbach` (hko-solutions). </td> <td>The issue has been fixed in the production environment. Release 1.6.1 prevents bogus instantiations of fixed-base tables in the voting server and correctly keys the encryption group cache. </td> <td align="center">High</td> </tr> <tr> <tr> <tr> <td align="center">#YWH-PGM2323-1732</td> <td>Send-Vote Context ID confusion allows targeted voting process disruption in the voting server</td> <td> The report identified a missing context validation in the voting server's sendVote endpoint. An authenticated voter could submit a valid sendVote request using their own voting card while specifying the verificationCardId of another voting card in the nested encrypted vote payload. This could cause the voting server to create work-flow state associated with the targeted voting card and prevent the targeted voter from submitting their vote through the e-voting system. The issue requires a valid voting card and knowledge of the target voting card's identifier. The practical impact is limited, as the affected voter can still cast their vote through a conventional voting channel if no definitive electronic vote has been registered. <br><br> Identified thanks to [13th](https://uid13.com/). </td> <td> The issue has been fixed in the production environment. Release 1.6.1 implements the necessary context vali-dation in the affected sendVote endpoint. </td> <td align="center">Medium</td> </tr> <tr> <tr> </table> ## Findings specific to the PIT+ <table> <tr> <th align="center">YWH-ID</th> <th>Title</th> <th>Description</th> <th>Status</th> <th align="center">CVSS-severity</th> </tr> <tr> <td align="center">#YWH-PGM44388-3</td> <td>Path Normalization Bypass of Voting Card Manager Access Restrictions in PIT+</td> <td> A researcher identified a path normalization issue in the PIT+ access layer that allowed blacklistbased re-strictions protecting the Voting Card Manager API to be bypassed. By using alternative path representations that were interpreted differently by the reverse proxy and the backend application, requests could reach end-points that were intended to remain inaccessible in the PIT+ environment. Through this bypass, a user with access to the PIT+ environment could invoke administrative Voting Card Man-ager API endpoints that were not meant to be exposed. The ethical hacker demonstrated access to functions allowing the retrieval of election event information, voting card status data, and voter participation records. The report also identified administrative operations that could potentially affect the availability of voting cards. The issue was limited to the PIT+ environment and relied on bypassing a blacklist rule in the access layer. The Vot-ing Card Manager endpoints are designed to be protected by access layer controls, and the reported finding showed that the PIT+ blacklist implementation did not adequately handle certain path normalization variants. </td> <td>The blacklist implementation in PIT+ was strengthened to prevent path normalization bypasses. In addi-tion, the architectural approach of relying on access layer protection for these endpoints is being reassessed and additional application layer authentication controls are being evaluated as a defense-in-depth measure. <br><br> </td> <td align="center">Low</td> </tr> <tr> <tr> <tr> <td align="center">#YWH-PGM44388-7</td> <td>Unauthorized Modification of Voter Portal Configuration in PIT+</td> <td> A hunter reported that the voter portal configuration endpoint in the PIT+ environment could be modified without the transport layer authentication normally protecting this functionality. The hunter also identified that a web application firewall rule blocking configuration updates with a standard JSON content type could be by-passed by submitting the same payload using an alternative content type accepted by the backend applica-tion. Using this approach, the hunter successfully modified the voter portal configuration associated with an election event and verified that the changes were persisted. The demonstrated modifications included changing the extended authentication factor displayed in the voter portal or modification of the texts and parameters affect-ing the design and behaviour of the voter portal. The original configuration was restored after testing. While the issue is not exploitable outside the PIT+ environment and the impact is limited to the voter portal configuration, a successful attack could introduce inconsistencies between the expected and displayed authen-tication parameters, potentially affecting voters attempting to authenticate. Identified thanks to `Yousif Elamin`. </td> <td>The PIT+ environment intentionally disables the strong transport layer authentication used during normal operation to provide additional testing opportunities. As a defense-in-depth improvement, the voting server will be enhanced to ensure that voter portal configuration changes are only possible during the configuration phase or under explicitly authorized exceptional circumstances. This improvement is planned for a future release. <br><br> </td> <td align="center">Low</td> </tr> <tr> <tr> <tr> <td align="center">#YWH-PGM44388-9</td> <td>Access to Encrypted Control Component Code Shares in PIT+</td> <td> A hunter reported that configuration download endpoints of the voting server were directly accessible in the PIT+ environment and could be used to retrieve encrypted control component code-share payloads and asso-ciated chunk information. The hunter demonstrated access to endpoints used by the Secure Data Manager (SDM) during the configura-tion phase of an election event and successfully downloaded encrypted code-share data for an active PIT elec-tion event. These endpoints are normally protected by strong transport layer authentication based on mutual TLS (mTLS), ensuring that only an authorized SDM instance can access the data. The issue was only reproducible in the PIT+ environment, where this transport layer authentication is inten-tionally disabled to provide additional testing opportunities. Although the downloaded information consisted of encrypted configuration data and no disclosure of sensitive information or cryptographic secrets was demon-strated, the report showed that configurationrelated data could be accessed outside of its intended workflow under the reduced PIT+ security conditions. Identified thanks to [13th](https://uid13.com/). </td> <td>The issue is limited to the PIT+ environment and does not expose unencrypted sensitive information. To further strengthen the system's defense-in-depth mechanisms, the voting server will be enhanced to prevent the download of control component code shares once the configuration phase of an election event has been completed, even if transport-layer protections are bypassed. This improvement is planned for a future release. <br><br> </td> <td align="center">Low</td> </tr> <tr> <tr> <tr> <td align="center">#YWH-PGM44388-23</td> <td>Apache Server Status Information Disclosure in PIT+</td> <td> A hunter reported that the Apache server status endpoint (/post-sys-status) was accessible in the PIT+ envi-ronment and disclosed operational information about the reverse proxy. By accessing the endpoint, the hunter was able to view Apache server-status information, including worker activity and request metadata. This infor-mation is intended for operational monitoring and troubleshooting purposes and can provide additional in-sight into the internal state of the web infrastructure. The issue was limited to the PIT+ environment, where the endpoint was reachable by users participating in the public intrusion test. The same endpoint was not accessible in the standard PIT environment. While no direct compromise of the voting system was demonstrated, the exposed information could provide reconnaissance value to an attacker by revealing details about the web server's activity and configuration. Identified thanks to [13th](https://uid13.com/). </td> <td>Access to the /post-sys-status endpoint will be restricted to internal IP addresses to prevent exposure of operational monitoring information in the PIT+ environment. This change reduces the amount of infrastructure information available to external users and strengthens the overall security posture of the platform. <br><br> </td> <td align="center">Low</td> </tr> <tr> <tr> </table>