For disputes involving electronic voting, the central question is not simply whether a vulnerability exists. It is whether the available evidence can establish that the vulnerability was exploitable in the relevant environment, actually exploited during an election, and capable of changing a declared result.
Those are different propositions. Treating them as interchangeable weakens both technical analysis and litigation strategy.
For Brazil’s 2026 elections, a defensible assessment should follow the evidence lifecycle: source-code inspection and security testing, applicable cryptographic controls, deployment, voting, generation of the Registro Digital do Voto (RDV) and Boletim de Urna (BU), transmission, tabulation, audit activity and preservation of relevant records.
The supplied research supports a careful conclusion. Brazil’s electronic voting ecosystem produces artifacts that may support forensic assessment, and public security testing has identified vulnerabilities in controlled conditions. But a vulnerability demonstrated in a test environment is not, by itself, evidence that it was used in a live election or altered an election outcome.
The evidentiary question has several layers
A technical allegation should be separated into at least four questions:
- Was there a vulnerability?
- Could it be exploited under the relevant technical and operational conditions?
- Is there evidence that it was actually exploited in the election under investigation?
- Did the alleged exploitation affect a result, and was the effect material to the declared outcome?
The first question may be addressed through source-code review, security testing, technical specifications or published research. The second requires analysis of access, privileges, keys, media, deployment procedures and other preconditions. The third and fourth require progressively stronger linkage between the alleged mechanism, relevant records and the claimed effect. Preserved provenance and custody records are particularly important for strong attribution or outcome-impact conclusions, although incomplete records may still support limited, qualified findings.
“Exploitable in a laboratory” is not equivalent to “exploited in the field.” “Capable of affecting integrity” is not equivalent to “changed the election outcome.”
The Brazilian voting system provides an audit surface
The TSE-managed electoral ecosystem produces artifacts relevant to forensic examination. Two important examples are the Boletim de Urna, or BU, and the Registro Digital do Voto, or RDV.
The BU is a printed report produced at the polling place and contains information that can be used to examine vote totals recorded for that section. Multiple copies and QR-code-based publication form part of the available audit surface. The RDV is a digital vote-record file associated with the voting machine. The supplied TSE guidance and open-data materials indicate that certain BU information and RDV-related information may be available for public analysis. The form and scope of that public information must be identified precisely in each review: a public dataset, derived file or published extract should not be treated as equivalent to an original device-held RDV artifact.
Other potentially relevant evidence includes:
- system and application logs;
- installation and security-subsystem records;
- boot and device records, where available;
- physical seals and storage media;
- published hashes, certificates and signatures from applicable compilation or sealing processes;
- chain-of-custody documentation; and
- transmission and tabulation records.
The value of these materials depends on provenance, preservation, completeness and the ability to reconcile one artifact with another. A BU that cannot be connected to a particular polling section, a digital file without documented provenance, or a hash comparison performed against an unverified image may provide context without establishing the asserted proposition.
From source code to sealed software
The applicable specifications and procedural materials may describe control points such as development, source-code inspection, compilation, digital signing, system sealing, media production, physical storage and deployment. The supplied UE2022 security specification is a reference describing requirements and intended controls; it does not, by itself, establish that a particular 2026 ceremony occurred as described or that every deployed device complied with it.
For a specific election and device, the relevant ceremony, deployment and custody records—if available—would be needed to establish what was actually performed. Those records may include published hashes, certificates or signatures, media-sealing records and distribution documentation.
Forensic examination should ask whether recovered software or media can be compared with the applicable signed and sealed reference. The comparison may involve:
- identifying the applicable 2026 specification and implementation version;
- obtaining the relevant ceremony-published hashes and public-key or certificate material;
- acquiring the relevant binary, firmware or storage image under documented forensic controls;
- calculating the relevant digest using the applicable algorithm;
- validating a digital signature against the relevant certificate or public key; and
- documenting any discrepancy, including the artifact, calculation method and acquisition history.
A discrepancy would require further analysis. It could indicate alteration, an operational or procedural difference, an extraction problem, a version mismatch or another explanation. It should not automatically be described as proof of malicious tampering.
Similarly, an apparent match may support integrity of the compared artifact, but it does not by itself establish that all operational procedures were followed or that no other stage of the lifecycle was compromised. The conclusion must remain tied to the artifact and comparison actually performed.
Cryptography is a verification baseline, not a conclusion
The supplied UE2022 security specifications identify cryptographic requirements and permitted algorithm families, including specified signature and hash functions and requirements concerning cryptographic-module boundaries and key-management procedures. Before using that document as the operative baseline for a 2026 review, the applicable 2026 version, implementation and deployment records must be confirmed.
Relevant questions may include:
- Which algorithms and controls were specified for the applicable system version, and which were implemented?
- Are the relevant keys, certificates and hashes available for verification?
- Does the recovered software or media produce the expected digest?
- Can the signature be validated against the relevant certificate or public key?
- Are key-storage or cryptographic-module records available?
- Were TPM or HSM records generated and preserved, and are they relevant to the proposition under examination?
- Can the chronology of signing, sealing, deployment and use be established?
These questions do not turn a cryptographic mismatch into a complete narrative. The investigator must establish what was compared, how it was acquired, whether the reference material is authentic and whether the result is consistent with the alleged mechanism of alteration.
A specification can establish what should be implemented or verified. It cannot, without examination of relevant production evidence, establish that every deployed instance complied with it.
What public security testing demonstrates
The TSE conducts Public Security Tests, known as Testes Públicos de Segurança or TPS, in which approved researchers can inspect aspects of the system and submit attack plans. TSE materials document testing activity and remedial actions.
Academic and practitioner research, including work by Aranha and subsequent teams, has described vulnerabilities demonstrated in TPS or laboratory settings. The reported issues include weaknesses involving key protection and management, random-number generation and unsigned components. Under the conditions described in the research, certain attacks could undermine ballot secrecy or software integrity.
These findings show that particular technical weaknesses were demonstrated under specified conditions. They may identify areas for focused examination in a production-evidence review. They do not establish that the same preconditions existed in field deployment.
Test environments may provide access, media, knowledge or conditions that are not present in the field. Testing rules, disclosure restrictions, non-disclosure obligations and partial publication may also limit independent reproduction of every technical detail. The appropriate conclusion is bounded: a vulnerability was demonstrated under the reported test or laboratory conditions. Whether its preconditions existed in a live election must be assessed against objective evidence, including custody records, device artifacts, logs, software provenance and access information.
Transmission, tabulation and reconciliation
After voting closes, the voting machine generates BUs and transmits relevant result information to the electoral results infrastructure. BU materials, RDV-related materials and published result datasets may create opportunities for cross-checking at the polling-section level, but the public form of each dataset must be distinguished from the original device-held artifact.
Where the necessary records are preserved, a reconciliation may compare:
- the original BU or a high-resolution image of it;
- the RDV file and the media from which it was obtained;
- corresponding TSE-published BU or RDV-related information;
- the per-section totals used in aggregation; and
- relevant device, transmission and custody records.
The purpose is to locate and characterize any inconsistency, not to assume that every inconsistency proves manipulation. If a difference is identified, the next question is where it could have entered the lifecycle: during generation, storage, extraction, transmission or aggregation.
The evidentiary strength of the result depends on the records available, their provenance and the extent to which integrity and custody can be assessed. In the public materials reviewed for this article, certain low-level device records, including TPM or HSM records where such records were generated, were not shown to be consistently available. Their absence may limit particular conclusions; such records are not categorically necessary for every form of analysis.
Exploitable, exploited and outcome-affecting are not synonyms
A useful classification is:
Vulnerability or exploitability
Published TPS and academic material supports the proposition that certain weaknesses were exploitable under test or laboratory conditions. This is a technical finding about a vulnerability and its demonstrated attack path.
Proven live exploitation
The supplied research pack did not identify a publicly documented, forensically preserved case connecting a TPS-discovered or academically disclosed vulnerability to use in a live national Brazilian election. That bounded research finding is not an exhaustive claim that no other material exists. A claim that a vulnerability was used would require evidence connecting the exploit to the deployed system and event.
Potential to affect election integrity
If a vulnerability were present in field conditions and its necessary preconditions were satisfied, it might create a pathway capable of affecting one or more voting sections. That is a technical inference requiring case-specific analysis of access, keys, media, deployment, scale and other conditions.
Demonstrated effect on the declared outcome
An outcome-impact conclusion would require connecting the alleged alteration to affected voting records and assessing its effect on aggregation and the declared result. The strength of that conclusion would depend on the available technical artifacts, provenance, custody evidence and analysis of scale and materiality. Incomplete records may permit only a qualified or limited conclusion.
A defensible investigation sequence
For litigators and investigations professionals, the sequence of work matters. A technically credible review should begin with preservation rather than a conclusion about causation.
1. Preserve the relevant evidence
Secure physical BU copies or images, RDV files or related extracts, relevant storage media, device images, available logs, published hashes, certificates, seals and custody records. Record acquisition circumstances, identifiers, timestamps and handling history.
2. Establish provenance
Determine whether each artifact can be associated with the relevant voting section, machine, media and procedural event. Identify missing records and distinguish reconstructed or secondary material from original evidence.
3. Confirm the applicable baseline
Identify the applicable 2026 system version, specifications, implementation records and relevant ceremony materials. Treat UE2022 as a supplied reference unless the records establish that it is the operative baseline for the system under examination.
4. Verify signatures and hashes
Where the applicable references are available, recalculate digests using the relevant algorithm and validate signatures against the relevant keys or certificates. Document tools, versions, inputs, outputs and uncertainty.
5. Compare software and source where possible
Compare extracted binaries or media with applicable published references. Where the necessary materials exist, assess compilation provenance and reproducibility. If relevant vendor-supplied sources or build metadata are unavailable, record that limitation rather than silently resolving it. Any historical audit material should be treated within its documented period and scope and should not be assumed to establish a current 2026 limitation.
6. Reconcile electoral artifacts
Compare BU counts, RDV-related data and published per-section results. Trace any discrepancy to the earliest point at which it can be established, using device, transmission and custody records where available.
7. Test the alleged attack path
For any alleged vulnerability, identify the required preconditions—such as access to media, privileged access, key material, unsigned components or deployment access—and compare them with the documented custody and operational environment.
8. Separate findings from hypotheses
Classify each conclusion as a fact, data point, inference, hypothesis, recommendation or unresolved gap. This prevents a technically plausible attack path from being presented as a demonstrated historical event.
Limits that should remain visible
The supplied research identifies several material limitations.
First, the reviewed research pack and supplied sources did not identify a publicly documented, forensically preserved case connecting a TPS-disclosed or academic-disclosed vulnerability to alteration of the outcome of a national Brazilian election. This is a bounded research finding, not proof that no undisclosed or separately documented event could have occurred.
Second, the supplied materials indicate that some low-level sources and device artifacts may not be publicly available. A historical audit source hosted on Scribd describes limitations concerning vendor-supplied components and reproducible-build analysis in the context it examined. That historical material should not be treated as evidence of a current 2026 limitation without specific supporting records.
Third, TPS and source-inspection rules, non-disclosure obligations and scoring frameworks may restrict public disclosure of complete exploit details. This can reduce independent reproduction and third-party validation.
These limitations define the boundary between what the supplied material supports and what would require further evidence.
A disciplined conclusion for 2026 investigations
Brazil’s electronic voting system produces artifacts that may support end-to-end forensic assessment. The TSE conducts public security testing, and independent researchers have documented vulnerabilities exploitable in controlled conditions. Specifications, applicable ceremony records, BUs, RDV-related materials, logs, transmission records and custody documentation may provide verification points, subject to confirmation of their provenance, scope and availability.
A demonstrated vulnerability is not proof of live exploitation. Live exploitation is not proof of altered totals. Altered totals are not, without aggregation and materiality analysis, proof of a changed election outcome.
For a litigation or investigation team, the practical priority is to preserve and reconcile the records that can distinguish those propositions. A defensible assessment identifies what the artifacts establish, what they suggest, what remains hypothetical and which missing records prevent a stronger conclusion.
If you are assessing an allegation concerning Brazil’s electronic voting system, the appropriate next step is a structured evidence-preservation and artifact-reconciliation review before drawing conclusions about exploitation or outcome impact.
Sources
- TPU — Teste Público de Segurança dos Sistemas Eleitorais — Tribunal Superior Eleitoral.
- Você sabe o que é Boletim de Urna (BU)? O Glossário explica — Tribunal Superior Eleitoral.
- Votação segura: RDV and BU information — Tribunal Superior Eleitoral.
- Compêndio — Teste Público de Segurança dos Sistemas Eleitorais 2023 — Tribunal Superior Eleitoral / Biblioteca Digital.
- Anexo IV — Especificações Técnicas — Segurança (UE2022) — Tribunal Superior Eleitoral.
- Software Vulnerabilities in the Brazilian Voting Machine — Aranha et al., USENIX / University of Brasília authors.
- The Return of Software Vulnerabilities in the Brazilian Voting Machine — academic publication.
- TSE Open Data — Boletim de Urna datasets — Tribunal Superior Eleitoral, Dados Abertos.
- Relatório de Auditoria and PSDB 2014 review — published audit materials.
