What specific vulnerabilities, if any, were discovered in Dominion's hardware, firmware, and software during the 2024 audits?
Executive summary
A series of academic audits and federal advisories in 2024 identified concrete software weaknesses in several Dominion systems—most prominently vulnerabilities that could let a motivated attacker recover per‑ballot mappings or make barcode and tabulation outputs inconsistent with the human‑readable paper record—while the record on firmware and hardware defects is narrower and emphasizes that exploitation generally requires physical access and chain‑of‑custody failures [1] [2] [3]. Authorities and vendors dispute the practical risk: Dominion issued patches and MITRE called many attack scenarios “operationally infeasible,” while CISA noted no evidence of exploitation in real elections and urged routine mitigations and audits [1] [4] [2].
1. Software vulnerabilities identified by academic audits and federal advisories
University of Michigan researcher Alex Halderman’s 2024 work documented software flaws in certain Dominion ballot scanners and tabulators showing attack scenarios that could “un‑shuffle” ballot information and thereby reveal vote‑to‑voter mappings and enable tampering of barcode/tabulation paths, a finding he detailed in a study and court testimony [1]. CISA’s advisory on the ImageCast X enumerated software issues including weaknesses in self‑attestation features for application hashes, audit log exports and application exports—tracked as CVE‑2022‑1739—which could undermine software verification if physical or procedural protections fail [2] [3]. CISA also highlighted the risk that barcodes could be manipulated so that scanners tabulate results inconsistent with the human‑readable portions of ballots, stressing that post‑election audits of human‑readable records are critical to detect such attacks [2].
2. Firmware and hardware: physical access and practical constraints
Across the public reporting, the vulnerabilities that matter most are tied to physical access to machines rather than remote zero‑day firmware exploits; multiple sources state that attacks typically require bypassing physical security to load modified software or tamper with media and barcodes [2] [5]. The Coffee County episode and DEF CON demonstrations were cited as proof that physical access and possession can occur, undermining assumptions that machines are always inaccessible [1] [5]. That said, public summaries do not provide exhaustive low‑level disclosures of firmware defects or hardware root‑cause code patches in the way academic papers sometimes do, so the precise firmware‑level attack vectors remain less documented in the provided reporting [1] [6].
3. Patches, counter‑analyses and disputed feasibility
Dominion responded to Halderman’s report with software updates addressing several of the described software vulnerabilities, and the company and some vendors have emphasized certifications and new hardening steps in later Democracy Suite versions [1] [4]. A Dominion‑funded MITRE assessment argued that the described hacks are “operationally infeasible” when routine election security practices are followed, while CISA affirmed the vulnerabilities but said it had “no evidence that these vulnerabilities have been exploited in any elections,” reflecting a dispute between theoretical exploitability and real‑world risk [4] [2] [7].
4. Where officials deferred fixes and why that matters
Some jurisdictions delayed installing vendor patches until after high‑stakes elections; Georgia publicly opted not to deploy certain updates before the 2024 presidential contest, a decision the state defended by calling the risks unlikely even as court‑unsealed reports urged mitigation [8] [4]. CISA and public‑interest researchers repeatedly cautioned that operational mitigations—strict chain of custody, post‑election audits of human‑readable ballots, and physical controls—are the primary defenses against the documented scenarios, and that failure to implement those mitigations increases practical risk [2] [3].
5. Open questions and limits of public reporting
The public record in these sources establishes specific software weaknesses—hash self‑attestation issues, audit‑log/export weaknesses, barcode/tabulation inconsistencies and the “un‑shuffle” ballot mapping vulnerability—but does not supply comprehensive, independently audited disclosures of every firmware routine or hardware component that might be exploitable; therefore, definitive claims about firmware or hardware backdoors beyond access‑dependent tampering are not supported by these reports [1] [2] [6]. CISA’s repeated caveat that it has “no evidence” of election exploitation remains a factual limit: the vulnerabilities are real and patchable, but demonstrable use in an actual election has not been documented in the cited material [2] [7].