One Compromised Login on a File-Transfer Site Exposed California Student Records Back to 2006

It took one login to reach files going back twenty years, and four months passed before anyone noticed. The California Department of Education and ETS, the testing nonprofit that works with the state, say an unauthorised party used a compromised credential to access an ETS file-transfer site and copy files containing California student information. The access ran at various times between 22 May and 18 September 2026.

The cause of the stolen credential has not been disclosed. What the notice does show is how much can pile up behind a single SFTP account, and that is a lesson any team that exchanges files with contractors can use.

What is confirmed

According to the department's notice and SecurityWeek's report on it, ETS detected unauthorised activity on 25 September, disabled the account involved and took the site offline. The department told superintendents on 2 October, and student notifications began on 16 October, expected to continue into early November. Affected current and former students are being offered two years of free identity protection.

The scope is the three previous school years of California students, plus some former students who left California schools as far back as 2006 without a confirmed transfer to another school. The files can include name, birth date, home address, school, district and grade, state and local student IDs, gender, race or ethnicity, primary language, country of origin and English-learner status. Some records also show disability and Section 504 status, the type of disability, testing accommodations, English-proficiency data, and test registration and results.

The state says the incident did not involve Social Security numbers, passwords, financial or payment information, or parent or guardian data. ETS says it is building a replacement site with stronger safeguards, and reports no evidence so far that the data has been posted publicly. It paused enrolment-data processing and some testing work.

What is not known

How the credential was compromised. Not disclosed. It could be phishing, malware on a machine, reuse of a leaked password or a shared login. No source says which.
How many students are affected. SecurityWeek reports that no victim count has been provided. Another outlet cites more than 5.7 million students, but that is the state's enrolment for the current year, not a confirmed count of victims, so we do not use it.
What controls were in place. The reporting does not say whether the SFTP site had multi-factor authentication, key-based login or address restrictions.
Who did it, and why. No attribution and no extortion has been reported.
Whether the data has been used or sold. ETS reports no evidence of public posting; that is not the same as knowing it has not been shared privately.

Why the two details matter more than the headline

The window. Access ran from 22 May to 18 September, and detection came on 25 September. A login that works for four months from an unfamiliar place, copying many files, should be visible. Whether it was a quiet volume, a trusted-looking source or simply no alert, the notice does not say. For your own sites, the question is whether anyone would be told if an account that normally uploads one file a week suddenly downloaded thousands.

The depth. Records for former students back to 2006 were sitting on a transfer site. File-transfer areas are built for movement, but they tend to become archives because nobody owns deletion. We made the same point after the Pentagon DMDC breach: what is stored determines the damage, not what was shared this week.

What to do with your own SFTP and file-exchange sites

List every transfer account and who owns it. Include contractor and vendor logins, shared logins and ones that belonged to people who have left.
Remove the shared secret. Prefer individual accounts with key-based login over a password shared by a team, restrict each account to the addresses it actually uses, and add a second factor wherever the platform supports one.
Set an expiry on files. Delete transferred files automatically after the job, and ask the recipient to confirm receipt rather than leaving the file for later. A folder with ten years of exports is a breach waiting to be reported.
Send less in each file. Check whether the recipient needs birth dates, addresses or disability information at all, or whether an identifier would do.
Alert on behaviour, not just on failed logins. Download volume, new source locations and activity outside normal hours are the signals that would have shortened a four-month window.
Rotate on suspicion. If a transfer credential might have been exposed, replace it, and review everything that account could read. Treat the whole directory it could reach as exposed.
Deliver the credential carefully. A new SFTP password or key passphrase often travels by email or chat. Send it once, to one person, over a channel that does not keep it.

Where Secretus fits, and where it does not

Secretus covers step 7: a person encrypts a short text secret in the browser, such as an SFTP password or key passphrase, and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.

It is not a file-transfer service and does not replace one. It cannot enforce multi-factor authentication on an SFTP site, delete old files, detect unusual downloads or tell you whether a contractor's login was stolen. Do those with your transfer platform and your logging, and use a one-time link for the moment one person gives another a credential.