Plaintext file shares turn a server flaw into million-record exposure

At a glance

What this is: A Pentagon data breach analysis shows how a file-sharing vulnerability and plaintext storage combined to expose personal data for about 3.05 million people.

Why it matters: It matters because identity and access teams have to govern not only who can reach file shares, but what sensitive data those shares still hold in readable form.

👉 Read Unosecur's analysis of the Pentagon file-share breach and plaintext exposure

Context

The core problem is simple: a file-sharing weakness only became a major identity and privacy incident because sensitive records were left readable on the server. In a mature programme, patching the application and governing the data exposure should be two separate controls, not one assumed outcome.

For IAM, IGA, and NHI teams, the lesson is that server access alone can define the blast radius when regulated data sits in plaintext. Once service accounts, tokens, OAuth grants, or human users can read the share, the identity layer and the data layer become inseparable in practice.

Key questions

Q: What breaks when sensitive data is left on a file share after the business purpose has ended?

A: The access model breaks because every remaining reader inherits whatever content is still present, even if the data is no longer needed. At that point, a future vulnerability or entitlement mistake exposes stale records that should already have been removed or encrypted. Retention and access governance have to move together.

Q: Why does plaintext storage make file-sharing vulnerabilities so much worse?

A: Because the vulnerability does not need to extract or decrypt anything once it reaches the server. If the contents are readable in place, the exploit becomes a direct path to regulated data, and the size of the incident is driven by what the server stored, not just how the flaw was reached.

Q: What are the signs that external file sharing is creating data risk?

A: Look for shared files granted to entire external domains, documents that remain accessible after the engagement ends, and sensitive content such as medical summaries or credentials appearing in collaboration tools. These are strong indicators that sharing has outlived its intended purpose and needs automated revocation.

Q: How should security teams decide between patching a file-share flaw and remediating the data stored on it?

A: Do both, but prioritise the data path first when the share contains regulated information. Patching closes the entry point, while encryption, retention cleanup, and entitlement review reduce the blast radius that the next vulnerability would otherwise inherit.

Technical breakdown

How a file-sharing flaw becomes a data exposure

A file-sharing vulnerability gives an unauthorised user or flawed access path a way into the server. That does not automatically create a breach of this size. The scale appears when the server already contains sensitive records in readable form, because the application flaw then becomes a direct path to plaintext data rather than a limited system error. In other words, the exploit is the entry point, but the storage model defines the impact. If the data had been encrypted at rest with keys outside the share, the same weakness would have had a far smaller payoff.

Practical implication: Treat file-sharing vulnerabilities and data-at-rest exposure as linked controls, not separate tickets.

Why plaintext storage amplifies identity risk

Plaintext storage collapses the distinction between authorised and unauthorised reads once an identity reaches the share. That identity might be a human user, a service account, an API token, or an OAuth grant, but the security outcome is the same: any path with read access can consume the contents directly. This is why identity governance must include resource classification. If the share holds Social Security numbers, personnel records, or other regulated data, the access decision is no longer only about authentication. It is about whether the identity should be able to see that content at all.

Practical implication: Classify the data on every share and align read access to that classification before exposure becomes systemic.

Blast radius is set before the vulnerability is found

The most important technical detail in this case is that the blast radius was pre-baked. Once sensitive files sit on a server for months, the eventual effect of a vulnerability depends on who can read them, whether the share logs those reads, and whether stale access has been removed. This is a governance failure as much as a technical one. The access window may be created by a bug, but the exposure window is created by retention, storage placement, and entitlement sprawl.

Practical implication: Review retention, logging, and standing access on file shares before the next vulnerability exposes them.

Threat narrative

Attacker objective: The objective was to read personal records at scale from a file share that should not have exposed them in plaintext.

1. Entry occurred through a vulnerability in a file-sharing system that allowed unauthorised access to the server.
2. Credential or access abuse was possible because the server stored unencrypted personal data that any successful reader could view directly.
3. Impact followed from the server contents, not just the flaw, because millions of records remained readable for months before discovery and patching.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Plaintext file shares create identity blast radius before any exploit occurs: The breach worked because the server already held regulated records in readable form. Once that happened, the vulnerability only had to open the door; the data model had already expanded the impact surface. The practitioner implication is that file-share governance has to treat stored content as part of the access-control decision.

Standing access is the hidden multiplier in server-side exposure: The question is not only who can authenticate, but which identities can read the share without a second gate. Service accounts, API tokens, OAuth grants, and forgotten human entitlements all widen the blast radius when content is plaintext. The practitioner implication is to govern access to the data, not just the system.

Retention is an access control by another name: A file left on a share after its business purpose has ended remains reachable by every identity that still has read access. That makes retention policy a security control, not an admin hygiene task. The practitioner implication is to remove data whose purpose has expired before a future vulnerability finds it.

Unencrypted file-share storage is a governance assumption failure, not a patching gap: The programme assumed that fixing the vulnerability would be enough, but the server still held readable records until someone discovered them. That assumption fails whenever sensitive files outlive the business process that created them. The practitioner implication is to reclassify storage placement as a core IAM and privacy decision.

Plaintext exposure turns every reader into a potential incident path: When sensitive records are not encrypted at the file level, the trust boundary moves from the file-share service to the identity that can read it. That is why breach review has to include entitlement review, not only vulnerability remediation. The practitioner implication is to connect access discovery, data discovery, and logging in one control loop.

What this signals

Plaintext storage is the control gap that keeps turning routine server bugs into privacy incidents: If the files are readable on the share, then the vulnerability only needs to create access, not exfiltrate content through a more complex path. That means file-share programmes should be judged on the sensitivity of what they still store, not only on patch cadence.

Access governance for file shares must include service identities, not just employees: In environments like this, the identities that matter most are often the ones nobody reviews during a normal access recertification cycle. When service accounts and token-based access can read regulated files, the share inherits machine-to-human exposure patterns that conventional reviews miss.

For practitioners

• Inventory every file-sharing server List each file-share and file-transfer server, what regulated data it stores, and whether that data is still needed. Separate business-purpose storage from legacy copies so the share itself is not the default archive.
• Encrypt sensitive files outside the share Apply file-level encryption with keys held outside the file-sharing service so server access alone does not reveal readable content. This reduces the value of a server-side vulnerability even when a read path exists.
• Map every readable identity Document every human and non-human identity that can read each share, including service accounts, API tokens, and OAuth grants. Remove standing access that no current process needs and validate the list after application changes.
• Log and alert on unusual reads Capture file-read events and alert when an identity reads sensitive files it has never touched before or reads far above its baseline. Use those alerts to triage whether the pattern matches data discovery or misuse.
• Review retention after transfer completion Set retention so files are removed once the transfer or business purpose is complete, then verify the cleanup jobs still run. A stale share is still a live exposure surface.

Key takeaways

• The breach shows how a file-share vulnerability becomes much more serious when regulated records are left in plaintext on the same server.
• The reported exposure affected about 3.05 million people, which demonstrates how storage design can define breach scale before any attacker action is confirmed.
• The limiting control is not only patching the application. File-level encryption, retention cleanup, and entitlement review are what shrink the blast radius.

Key terms

• File-share blast radius: The amount of data, identities, or business impact that a compromise of a shared file system can expose. In identity governance terms, the blast radius is determined by both who can reach the share and whether the contents are still readable in place.
• Plaintext Storage: Plaintext storage means saving passwords in readable form without cryptographic protection. It is the weakest storage model because anyone who reaches the data can read the secret directly. In security and privacy programs, plaintext password storage creates immediate breach exposure and should be avoided because it gives attackers and insiders the simplest possible path to misuse.
• Standing read access: Persistent entitlement to read data without a just-in-time approval gate. In file-share environments, standing read access is especially risky because stale service accounts, tokens, or users can continue to consume sensitive files long after the business need has ended.
• Retention as a security control: The practice of removing data when its business purpose ends so that old information does not remain available for future compromise. For identity programmes, retention is part of access reduction because data that no longer exists cannot be read.

What's in the full analysis

Unosecur's full article covers the operational detail this post intentionally leaves for the source:

• The breach timeline, including when the vulnerability likely began and when DMDC discovered and patched it
• The reported record counts and the categories of personal data exposed in the Pentagon incident
• The exact security questions Unosecur says teams should ask about file-sharing servers and identity reach
• The identity visibility angle showing how human and non-human access paths affect read exposure

👉 Unosecur's full post covers the timeline, exposed data fields, and identity visibility questions in more detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.