← All posts

280,000 people had already voted online before anyone noticed the hole

During a live election with 280,000 votes already cast, two researchers found a flaw the official security review had missed — and the verification system meant to catch it was broken too.

It is March 2015, and somewhere in New South Wales, a voter opens a browser, follows a link, and casts a ballot in a state election. The whole process takes a few minutes. No queue. No polling booth. Just a form, a click, and a confirmation message.

What that voter doesn't know — what no one outside a small research team knows yet — is that the code running beneath their browser is being loaded over a connection with a known security weakness. That a network attacker sitting between the voter and the server could, in principle, have tampered with that code before the page loaded. That the separate telephone verification service the system offered as its integrity check could itself be gamed. And that a prior security review had looked at this system and not found any of this.

By the time researchers J. Alex Halderman and Vanessa Teague went public, roughly 280,000 votes had already been cast.

The system that cleared itself

The iVote system wasn't a rogue experiment or a rushed afterthought. New South Wales had invested in it deliberately, offered it to voters who were blind or print-disabled, remote, or simply preferred the convenience of voting online. It had passed an official pre-election security review. The authorities knew about internet-voting risks — they had reviewed the system for them. They concluded it was ready.

A closed review that clears a system is not the same as that system being secure.

Here is what the official review did not catch, according to the peer-reviewed paper Halderman and Teague published at E-Vote-ID 2015: iVote loaded external JavaScript — code that runs in the voter's browser — from an analytics server over a connection vulnerable to the FREAK and Logjam attacks. These were known, documented TLS weaknesses that had been publicly disclosed. A network-positioned attacker exploiting that weakness could have injected malicious code into the iVote page before it reached the voter, potentially manipulating how a vote was recorded without the voter's knowledge. The attacker would not need to break into the electoral commission's own servers. They would just need to be in the right position on the network.

The researchers also examined iVote's telephone verification service — the feature the system offered as a way for voters to confirm their vote had been recorded correctly. What they found was that the service was itself susceptible to manipulation in a way that could make a tampered vote appear verified. The check was checking against a source that could also be altered.

That's not a safety net. That's the illusion of one.

What "after a prior review cleared it" actually means

Let's be precise about the sequence of events, because the sequence is the whole story.

A security review was conducted before the election. The review did not find the vulnerabilities Halderman and Teague found. The election began. Votes accumulated — eventually reaching roughly 280,000. Then two independent researchers, working from outside the electoral commission and outside its contracted reviewers, analyzed the running system and found serious flaws. They disclosed the issues. A fix was deployed while voting was still underway.

In other words: the official, pre-election review gave a clearance. Two outsiders with no institutional stake in the answer found what the official review missed. The problems were discovered not because the process worked, but because independent researchers decided to look — on their own initiative, during a live election.

"It passed its security review" is a claim about a snapshot. It is not a claim about the system that runs on election day.

This is the certification-snapshot problem. A review is conducted at a point in time, on the code and configuration that exists at that moment, using the test plan and threat model the reviewers brought with them. If the threat model missed a known TLS attack class, those vulnerabilities don't appear in the report. The system changes slightly — a third-party analytics library updates, a configuration parameter shifts — and the review no longer covers what is actually running.

The German Constitutional Court confronted a version of this problem in 2009, when it ruled that electronic voting is only constitutionally legitimate when ordinary citizens can verify each essential step without specialist knowledge. Voters checking a screen after clicking "Submit" and receiving a confirmation message cannot do this. Neither, it turns out, can a pre-election security team that doesn't happen to look at a specific external dependency loaded over TLS.

The verification mechanism that didn't verify

The detail that deserves to sit with you for a moment is the telephone check.

iVote gave voters a way to call in and verify that their vote had been recorded as intended. This is the right instinct. End-to-end verifiability — the ability for a voter to confirm their ballot was captured correctly — is a genuine security requirement, not a marketing feature. Norway, Estonia, and Switzerland have all grappled seriously with how to provide it. The Swiss Post's 2019 system used cryptographic proofs to offer what it called universal verifiability, until independent researchers found a trapdoor in the mixnet that could generate a convincing-looking proof while hiding altered votes.

The impulse to give voters a check on the system is exactly right. The problem comes when that check runs on the same infrastructure as the thing it is checking — or when it can be manipulated by the same attacker who might manipulate the vote itself.

This is not a hypothetical risk. Halderman and Teague documented that iVote's telephone verification was itself susceptible to manipulation that could produce a false confirmation. A voter calling to check their ballot would hear that everything was fine. A voter whose ballot had been altered by a network attacker would also hear that everything was fine. The verification service and the vulnerability lived in the same ecosystem.

A verification mechanism that can be fooled by the same attack as the underlying system verifies nothing. It provides comfort, and comfort is not a security property.

Why "independent" is doing all the work

Here is the uncomfortable truth about the NSW episode: nobody in the official chain caught this.

Not the vendor. Not the electoral commission's own team. Not the contracted security reviewers. It was caught by two academics who were not asked, not paid, and not given special access to a test environment. They analyzed the production system — the one handling real votes from real voters — and found what the official process had not.

Washington, D.C. in 2010 is the closest useful comparison. Before deploying an internet ballot-return system for overseas voters, D.C. ran an open public trial and explicitly invited the public to attack it. A University of Michigan team led by Halderman gained near-complete control of the pilot server in roughly 48 hours, changed ballots that had been cast, and left the fight song playing as evidence of their access. D.C. dropped the system. No real votes were affected. The vulnerabilities were caught because the test was explicitly open — anyone could try, and the team that did try found what closed internal testing had not.

The NSW case is D.C.'s mirror image. No open public test. A closed review that cleared the system. Vulnerabilities found anyway, by independent researchers, after real votes were already in the system.

The difference between a disaster and a caught defect is often just whether the right outsider happened to look.

That's an uncomfortable sentence, because it means the safety of an election can turn on the initiative of researchers who are not part of the official process and who might easily not have looked. It also means that when they do look and find something, the official response should be "thank you and here is what we changed" — not "our review had already cleared the system."

The review clearing the system is the data point that should worry you, not reassure you. It tells you a closed review did not find what open review later found. The appropriate response is to ask what else the closed review might not have found.

The snapshot problem runs deeper

Every certified voting system in the world was certified at a moment that is now in the past.

The U.S. Election Assistance Commission certifies voting systems against the Voluntary Voting System Guidelines. A GAO report from 2005 found that even the basic infrastructure for that certification program was incomplete, years after the Help America Vote Act had mandated it. Standards get built. Systems get tested against them. Certification is issued.

Then time passes. New attack classes are discovered. Dependencies are updated. Configurations drift. And the certification, which was a snapshot of a system against a standard at a point in time, remains on the wall like a framed photograph of a building that has since been renovated.

The deeper problem is that no certification process can account for attack classes that were not in the threat model when the review was conducted. FREAK and Logjam were publicly known weaknesses when iVote was running. They were in the academic literature. They had names. And they were apparently not in the test plan that cleared the system.

This is not an argument against certification — it is an argument that certification is necessary but not sufficient, and that its sufficiency degrades over time. The honest version of "this system is certified" is: "this system passed a review against a specific standard, conducted by a specific team, using a specific threat model, at a specific point in time. None of those things are guaranteed to remain current."

The fix is not a better snapshot. The fix is continuous, open, independent verifiability — so that the question is not "did it pass review?" but "can you show me the math?"

What "independently checkable" actually requires

The NSW iVote story ends with a fix deployed mid-election and a system that continued operating. The election was not halted. The 280,000 votes already cast were not re-run. There was no mechanism to confirm retrospectively whether any of those votes had been altered before the fix.

This is the hard part of the story that doesn't resolve neatly.

The Estonian i-voting system, which Springall, Finkbeiner, and Halderman's team analyzed in 2014, at least offered partial source code for independent examination. Researchers found serious operational security weaknesses and concluded a well-resourced attacker could alter votes undetectably. Estonia disputed the conclusions. The system continued operating. Dispute and continuation are not the same as resolution.

The Swiss Post's 2019 system went further still — it published its full source code for public scrutiny before deployment in binding elections. Independent researchers found the trapdoor in the shuffle proof. Swiss authorities suspended the system. That's the closest thing to a success story in this space: source published, flaw found, system halted before real votes were affected.

The progression from NSW to Estonia to Switzerland is a progression toward openness. NSW: closed review, flaws found during a live election, no mechanism for voters to verify retrospectively. Estonia: partial openness, independent analysis, disputed conclusions. Switzerland: full publication, cryptographic flaw found before binding use, system suspended.

The direction matters. But notice what Switzerland required to work: not just publication, but cryptographers with the tools and knowledge to spot a subtle trapdoor in a mixnet proof. Vanessa Teague — who worked on both the NSW analysis and the Swiss Post analysis — is one of a small number of people in the world who can read a shuffle proof and notice that something in it is wrong.

"Independently checkable" is not the same as "technically possible for any citizen to check." For cryptographic internet voting, genuine independent verifiability requires active, open engagement from qualified outsiders — and a process that actively solicits it, not one that tolerates it only after researchers decide on their own initiative to look.

Brazil's electoral court runs an official public security test program every election cycle, inviting any qualified citizen to try to break the system and fixing what they find. That is not a perfect model — it tests specific systems in specific configurations at specific points in time, and the problems that did not appear in the test can still exist in the production system. But it is structurally better than a closed review, because it is open, adversarial, and institutionalized rather than occasional and accidental.

What is still not checkable

Here is what neither the official NSW post-election review nor the independent research paper can tell you: whether any of the 280,000 votes cast before the fix was deployed were altered.

Not because of bad faith. Not because anyone is hiding something. But because the system was not designed to allow that question to be answered after the fact. There is no voter-checkable record that was committed before the vote was submitted and that can be compared afterward. There is no cryptographic audit trail that a voter can examine to confirm their ballot was counted as cast. The telephone verification service that might have served that function could itself have been compromised.

This is the gap that no official statement can close. The authorities can say — and did say — that they are not aware of any votes being altered. That is a sincere statement. It is also an unfalsifiable one. "Not aware of" and "did not happen" are separated by the entire width of the question.

The German Constitutional Court's standard is worth repeating here, because it applies with full force: an election is only legitimate when the essential steps from ballot to result can be checked by citizens without specialist knowledge. For an online vote that loads code over a vulnerable connection, the voter cannot check that the code they received was the code the server sent. For a verification service that can itself be manipulated, the voter cannot confirm the confirmation is real. For a system with no retrospective audit trail, the officials who ran it cannot confirm no votes were changed.

The right question is not "did we find any evidence of tampering?" The right question is: "could anyone have found it if tampering had occurred?"

If the answer to the second question is no, the first question provides no assurance at all.

Explore how this gap appears in systems around the world →

Read the two-minute version →

See the full pattern across documented cases →

Sources

See all postsExplore the gaps