TaxAct

DataBreaches reported on August 17, 2026 that an anonymous source had provided evidence of more than two million records acquired from TaxAct, containing client phone numbers, usernames, and email addresses. Roughly 450,000 of those records had already been leaked.

The source contacted the publication directly. The claim has not been fully independently verified and no threat actor has been publicly attributed as of this writing.

Reported: client phone numbers, usernames, and email addresses. What is absent matters as much as what is present — no returns, no Social Security numbers, no income figures, no bank details.

By the standards of this series that is a mild dataset, and under most state statutes an email address and phone number without a credential may not even trigger notification.

The value is not in the fields. It is in the membership. Everyone in that file is confirmed to have filed a tax return through a specific product.

Tax filing platforms sit on the highest-trust relationship most consumers have with any software. Users hand over their income, their dependents, their employer, and their bank routing details for the refund. That trust transfers to any message that appears to come from the platform.

An attacker holding this list knows exactly which service to impersonate, has a verified phone number for SMS delivery, and knows the precise season when a message about a return or a refund will be plausible. Refund fraud and account takeover during filing season both begin with knowing who filed where — and that is the one thing this dataset establishes conclusively.

Usernames compound it. A username paired with an email is the first half of a credential stuffing attempt against the account holding the actual tax data.

Tax preparation software operates under IRS security requirements, including the safeguards described in Publication 4557, alongside FTC Safeguards Rule obligations and state regulation. The crown jewels — returns, Social Security numbers, income data — are the focus of that entire regulatory apparatus, and on the available evidence they were not taken.

That is a real success, and it points at the blind spot. Protection was concentrated on the return data, which is correct. The account layer — the usernames, contact details, and identity of who holds an account — sits outside the sensitive-data perimeter because it contains no tax information. It is nonetheless the layer that identifies every customer.

The sequence is the finding. The company did not surface this incident. A source did, through a reporter, with a sample. That means the exposure was not detected internally, and it means the first credible account of scope came from outside the organisation.

There is a broader lesson about what makes a dataset sensitive. Every classification model in common use would rate a table of usernames, emails, and phone numbers as low risk, and in isolation that is correct. What raises the risk here is the fact of membership — the list is sensitive because of what it proves about the people on it, not because of what it contains about them.

Customer lists at a tax preparer, a rehabilitation clinic, a bankruptcy firm, and a fertility service are structurally identical and carry entirely different consequences.

The statutory position is genuinely ambiguous, and that ambiguity is itself a problem. Many state breach statutes require a name combined with a specified sensitive element; an email address, username, and phone number may fall short in some jurisdictions and qualify in others where credentials are covered. The FTC Safeguards Rule imposes its own notification requirement for events meeting defined thresholds.

Meanwhile the practical risk is high regardless of what the statute concludes. Two million people are now targets for tax-season fraud whether or not they receive a letter. The gap between what the law compels and what the customers need is where a company's actual posture shows.