Pentagon file-share exposed 3 million military records

The Defense Manpower Data Center confirmed in September that a flaw in one of its internal file-sharing systems exposed unencrypted Social Security numbers for more than 3 million military and civilian personnel over nine months.

The DMDC is the Pentagon agency that manages personnel records for active-duty service members, veterans, and their dependents. A flaw in an internal file-sharing service gave a small number of unauthorised individuals access to records from October 2025 until July 16, 2026, when DMDC discovered and remediated the issue. TechCrunch reported that notifications went out September 18, covering approximately 2.76 million living individuals and 294,000 deceased people. The exposed fields included Social Security numbers, names, dates of birth, contact details, demographic data, and military occupational specialties. DMDC confirmed that the records were not encrypted.

The Pentagon said it has found no evidence of misuse and has not publicly named the file-sharing system involved or disclosed the specific access path. Affected individuals are being offered credit monitoring through IDX. SecurityWeek noted that the agency processed notifications over several weeks given the scale of the affected population.

Two things are worth pulling out of the reporting.

What scanners would have missed

A vulnerability scanner run against the DMDC environment would have produced a list of CVEs for the file-sharing platform, sorted by CVSS score. The highest-severity entries might have flagged remote code execution paths or authentication bypasses. None of those findings tell you what data is inside the share.

CVSS scores describe the severity of a software flaw in the abstract. The confidentiality impact metric rates as "high" when an attacker can read all data on the system, and "low" when they can read only some. That rating is an estimate, not a measurement. It does not change based on whether the files in scope contain plaintext Social Security numbers or empty test logs.

This is the reachability gap. Single-tool security testing compounds it: SAST analyses source code, DAST probes HTTP responses, SCA cross-references dependency versions. None of these instruments opens the filesystem, retrieves a file, and verifies whether the contents are encrypted. Autonomous penetration testing traces the data path rather than scoring the software flaw. The distinction matters when the actual harm is not a code execution path but a misconfigured access boundary that exposes plaintext records.

For the DMDC case, a scanner would have reported a severity. It would not have reported the payload.

What Sekura would have shown

The relevant Sekura phase is phase 3, dynamic probing. An agent in this phase tests authentication controls and access boundaries on reachable services. For a file-sharing endpoint where the access control contains a flaw, the agent attempts to access directories through the weakened path and examines what it retrieves.

A probe that reaches an unencrypted SSN file produces a finding that does not read like a generic access-control warning:

Phase 3 agent accessed /shares/personnel/records/batch-2025-10/. Retrieved sample of 12 records. SSN field present in plaintext. No encryption-at-rest applied to this path. Access-log query volume shows no rate-limit trigger. Estimated affected records based on directory structure: 3 million.

That finding carries a proof. The proof is the retrieved record. The confidentiality impact is not a CVSS estimate; it is a confirmed fact about what an attacker can read.

The second finding is about detection: the unauthorised access ran for nine months. An agent that reads access logs and finds no rate-limit trigger or anomaly alert records that absence as a separate finding. The two together describe the actual risk picture: the data is reachable and nothing is watching.

The bigger pattern

The DMDC incident belongs to a category that does not appear clearly in most security inventories: sensitive data accumulated inside infrastructure that was never provisioned as a sensitive data store. The file-sharing system was most likely designed for document exchange. Personnel records reached it as a side effect of someone's workflow.

This pattern repeats across organisations. Sensitive data migrates toward convenience. It ends up in file shares, in storage buckets with overly permissive access policies, in internal portals stood up for a specific project and never decommissioned. The data does not label itself. No scanner reads the contents and adjusts the severity score accordingly.

I think the more useful question is not why a government agency had this problem. It is how many similar shares exist in any given environment right now and how many have been verified rather than assumed to be safe.

If you want to see what that kind of proof looks like on your own infrastructure, request a proof-of-concept.