Blog
Security30 Sep 2026

The files were not encrypted.

A file-sharing system at the Pentagon's personnel data center held Social Security numbers for 2.76 million living people in readable files, and unauthorized users had access for about nine months. What the breach says about where sensitive files sit between transfers.

On 18 September, the Defense Manpower Data Center (DMDC), the U.S. Department of Defense agency that keeps personnel records, began mailing breach notification letters. One was posted to a Reddit forum for Air Force members, and Military Times reported on 24 September that two defense officials had confirmed it was authentic. According to the letter, a "small number of unauthorized users" had accessed a server in a DMDC file-sharing system that held unencrypted files containing personally identifiable information. The access ran from October 2025 until 16 July 2026, when the vulnerability was found and patched.

What was in the files

Each affected record included a Social Security number plus at least one other item: a name, date of birth, contact details, sex, race or military job information. Military Times first cited sources estimating around four million people. A defense official later gave ABC News the official count: 2.76 million living people and 294,000 who have died. The official's statement described "unauthorized access of personally identifiable information by a small number of unauthorized users between October 2025 and July 2026."

The Pentagon says it has found no evidence that the data has been misused, and it is offering a year of credit monitoring through IDX. It has not said who the users were, how they got in, or what the vulnerability was. DMDC is the central repository for more than 60 million records covering service members, civilian employees, contractors, retirees, veterans and family members.

A file share becomes an archive

The detail that matters for anyone handling sensitive files is the system type. File-sharing servers exist to move documents between people and offices. In practice, the files stay after the exchange is finished. Exports, spreadsheets and reports pile up on shares that were set up for convenience and then stop getting attention, and each one is a readable copy of data that is also protected, presumably more carefully, in the system it came from.

The records of 294,000 deceased people show how long that retention can run. Whatever the reason their Social Security numbers were on a file-sharing server, the files were still there, and still readable, when the unauthorized users reached them.

Nine months of undetected access

The access window was roughly nine months, and the notification letters went out about two months after discovery. Detection and response matter, but they come after the fact. In this case what the users could read had already been decided, earlier, when the files were stored unencrypted.

Encryption at rest on the underlying disks, if the server had it, would not have changed the outcome. A user who reaches the file share through the application reads what the application serves, and the application decrypts on request. The protection that would have mattered is encryption of the files themselves, with keys held somewhere the file server never sees.

A readable copy protected only by the server hosting it is exactly as private as that server.

Encrypt before the file reaches the server

The general fix is to encrypt each file on the sender's device before it is uploaded, with keys that never leave the endpoints. The server then stores ciphertext and routes it; it cannot open anything, so neither can someone who compromises it or borrows its access. This does not remove every risk. Metadata such as file sizes and upload times remains visible, and an attacker on an endpoint can still read what that endpoint can read. It does shrink the target from "everything on the share" to "whatever sits on the devices of the people who were meant to see it."

Retention also gets easier to reason about. A leftover ciphertext on a server is much less dangerous than a leftover spreadsheet, and records that must be kept for years can go to storage that is offline rather than to a share that stays reachable.

Where SpaceBox fits

SpaceBox Lite follows that model for sending files. Each file is encrypted on the sender's device using post-quantum ML-KEM-768 (NIST FIPS 203) key exchange and AES-256-GCM; keys stay on the device and our servers hold ciphertext only. Senders need no account and give us no personal data. Post-quantum key exchange is available in other products too; what matters for a breach like this one is that the server holding the files has no key to use. Lite is free, and during the beta it is not available to residents of the EU or EEA.

For records that have to be retained, the SpaceBox family also includes an on-premises hardware vault: an air-gapped, append-only appliance where access needs approval from several people. It is designed for the archive that should not be sitting on a network share at all. See Why SpaceBox for how the pieces compare.

Send files the server cannot readEncrypted on your device, post-quantum, ciphertext only on our servers. Start free.

Keep reading

All articles →