How Misconfigured SQLite Databases Compromise Voting Machine Integrity

TLDR: Researchers at DEF CON 2025 demonstrated that Dominion ICX voting machines rely on insecurely configured SQLite databases that lack cryptographic integrity checks. By modifying these databases, an attacker can alter ballot content, remove candidates, and manipulate party affiliations without triggering any system alerts. This research highlights a critical failure in OWASP A05:2021-Security Misconfiguration and OWASP A02:2021-Cryptographic Failures within critical infrastructure.

Voting machines are often treated as black boxes, shielded by proprietary software and vendor claims of "air-gapped" security. The reality, as shown by the latest research on the Dominion ICX platform, is far more fragile. When critical infrastructure relies on standard, off-the-shelf software components without implementing robust integrity verification, the entire chain of trust collapses. This isn't a theoretical exploit requiring nation-state resources; it is a direct result of failing to secure the data layer that drives the user interface and the final vote tally.

The Mechanics of the Database Manipulation

The core of the vulnerability lies in how the ICX machine processes its configuration and ballot data. The system uses SQLite databases to store election definitions, which include candidate names, party affiliations, and ballot questions. During the research, it was discovered that these database files are not cryptographically signed or verified by the application layer.

Because the system lacks integrity checks, an attacker with physical access to the machine—or access to the removable media used to load election configurations—can modify the database directly. The researchers demonstrated that by simply opening the SQLite file and editing the relevant tables, they could change the party affiliation of a candidate or remove a candidate from the ballot entirely.

The attack flow is straightforward:

1. Extract the election configuration database from the machine or the loading media.
2. Use a standard SQLite browser to locate the ChoiceLocalized or similar tables.
3. Modify the Text or Party fields to reflect the desired fraudulent state.
4. Save the database and reload it into the machine.

When the machine boots, it reads the modified database and displays the altered information to the voter. Because the application trusts the database implicitly, the voter sees a ballot that has been tampered with, and the machine records the vote based on the manipulated configuration.

Why This Matters for Pentesters

For those of us performing physical security assessments or red team engagements on critical systems, this finding serves as a reminder that the "application" is often just a thin wrapper around a database. If you can reach the data, you own the logic.

In a typical engagement, you might look for ways to bypass authentication or escalate privileges within the software. This research suggests that you should instead look for the data ingestion points. If a system uses a database to drive its UI, ask yourself:

• Is the database file encrypted at rest?
• Is there a checksum or digital signature verifying the file before the application loads it?
• Can I modify the database schema or content without breaking the application's ability to run?

If the answer to these questions is no, you have found a path to full system compromise that bypasses all software-level access controls. The impact here is absolute: you are not just gaining access to the system; you are changing the fundamental truth that the system reports.

The Defensive Reality

Defending against this type of attack requires moving away from the assumption that the environment is secure. The vendor must implement cryptographic signing for all configuration files. If the application does not verify the signature of the database before loading it, it should refuse to boot.

Furthermore, the use of technician cards or other physical access tokens should be tied to a hardware security module (HSM) that validates the integrity of the entire boot chain. Relying on "security through obscurity" or the physical difficulty of accessing a machine is not a strategy; it is a liability.

For those responsible for these systems, the takeaway is clear: integrity is not an optional feature. If your system reads data from an external source, you must treat that data as untrusted until it is cryptographically verified. Anything less is an open invitation for manipulation. As we move toward more complex, software-defined infrastructure, the ability to verify the state of our systems is the only thing standing between a functional process and a compromised one. Keep digging into the data layers of the systems you test, because that is where the most significant vulnerabilities are hiding.