The Metadata Nobody Reads: How a Government Portal Leaked Internal Usernames Across 15,000…

A large public-sector document portal was serving every PDF and DOCX exactly as its authors had saved them — metadata intact. Buried in that metadata were internal staff account names, internal workstation identifiers, local filesystem paths containing usernames, and internal template GUIDs.

The documents themselves are public by design. The bug was never about their content. It was about the envelope: the files carried internal infrastructure naming alongside them, in a form that could be harvested at scale with no authentication and no interaction.

I've redacted the target to target.com throughout. The findings below are from a responsible-disclosure process; the target has acknowledged the report.

What Metadata Is

Metadata is data about data. In documents such as PDFs and DOCX files, it can include the author's name, company, creation details, software used, internal template identifiers, and even local filesystem paths.

It's often invisible when you open a document, but the information is still embedded in the file. If it's not properly sanitized before publication, metadata can expose internal usernames, workstation naming conventions, and other infrastructure details that were never intended to be public.

Why This Class of Bug Matters.

Most people think of leaked credentials, exposed S3 buckets, or SQL injection when they hear "information disclosure." Document metadata rarely makes the list — and that's exactly why it's interesting.

A single PDF author field is low-severity on its own. But a document estate is not a single PDF. It's a corpus, and a corpus with a predictable URL structure and a published sitemap is an enumerable one. When the leak is systematic, the value isn't in any one document — it's in the aggregate: a directory of account names, a map of workstation naming conventions, a set of internal template identifiers. That's reconnaissance material, and it was sitting behind nothing more than a curl.

How I Found It.

I didn't start with a document. I started with the sitemap as usual.

The first step was just visiting the target's published sitemap. Like most large sites, it exposed a sitemap index — in this case, 44 sub-sitemaps — and from there, every document URL on the estate was enumerable without authentication. That's the moment the bug went from "a PDF has a name in it" to "the estate is a directory."

Once I had the URL list, the rest was mechanical. Fetch a file, read its metadata, repeat. No interaction, no rate-limit drama, no cleverness required — just a curl and a metadata reader, run across a list of URLs that the site had helpfully published for me.

That's the part I want to underline: the vulnerability wasn't discovered by poking at an application. It was discovered by reading a sitemap.

What the Metadata Contained.

I'm not going to reproduce the full inventory here — the report has it, and the specifics belong in a disclosure thread rather than a blog post. But the categories are worth naming, because each one tells you something different about how the files got there.

The simplest case was the PDF author field holding an internal staff account name — the kind of short alphanumeric identifier an organization issues to its employees. On its own, low-severity; across a corpus, a directory.

More interesting was the subset where the author field held the account name plus an internal workstation identifier, in the form NAME@W######. That suffix exposed the target's workstation naming scheme — which is more useful for reconnaissance than a bare username, because it tells you how machines are named and numbered internally.

Then there were the files whose XMP metadata carried local filesystem paths from the author's machine — C:/Users/<name>/... on Windows, /Users/<name>/... on macOS. On one document, the XMP path was actually the dc:title, meaning the file's displayed title was a local temporary path rather than a title. That's the tell that nobody looked at what was shipping.

The DOCX files were a separate story: all of them carried Company = <redacted> <country name>and a set of distinct internal .dotx template GUIDs. I checked for tracked changes, comments, and recoverable deleted text and found none — the templates were clean apart from their metadata. That's worth saying explicitly, because "DOCX metadata leak" often implies worse things than what was actually here.

And finally, a category I recorded for completeness but which I'd argue is the weakest in the report: PDF author fields holding staff personal names. Names of employees acting in a professional capacity are not, in most readings, personal data requiring protection. I mention it because it was in the data, not because I think it's the story.

Establishing Scale.

The distinguishing feature of this estate is that the leak is bulk-harvestable. The site publishes a sitemap; from there every document URL is enumerable; metadata can be extracted from thousands of files in minutes with no authentication and no interaction.

Sitemap index .......... 44 sub-sitemaps
Total URLs ............. 80,000+
PDFs ................... 15,000+
DOCX ................... 700+

Sitemap index .......... 44 sub-sitemaps
Total URLs ............. 80,000+
PDFs ................... 15,000+
DOCX ................... 700+

That's the difference between "a PDF has a name in it" and "the estate is a directory." The former is a nuisance. The latter is a reconnaissance surface.

Root Cause.

Nothing exotic. Documents were published as the authors saved them — no metadata stripping step in the publishing pipeline, no sanitization on ingest, no template hygiene enforced at source. The metadata that leaked was written by the authoring applications (Word, Acrobat, scanners, template macros) years before the files reached the web server, and nothing in between touched it.

The fix is equally unexotic, and it's worth naming because it's the part most organizations skip:

1. Strip on ingest. Run every published file through exiftool -all= (or equivalent) before it lands in the DAM.
2. Don't trust the authoring app to leave it alone. dc:title being a temp path is the tell that nobody looked.
3. Publish a sanitized copy, keep the original. Metadata is useful internally; it doesn't need to be public.

Takeaways.

1. Metadata is content. If it ships in the file, it's published. Treat /Author, XMP packets, docProps/, and template GUIDs as part of your public surface.
2. Start with the sitemap. Before you audit an application, enumerate what it already tells the world it has. A sitemap is a map; read it.
3. Scale changes severity. A single leaked username is trivia. Fifteen thousand files with predictable URLs and a public sitemap is an enumerable directory. Severity is a function of both, not either.
4. exiftool -all= file is a one-liner. The gap between "leaking" and "not leaking" here is a single step in a pipeline that nobody had added.

The documents were always meant to be public. The account names, workstation IDs, and local paths were not. That gap — between the file and its envelope — is where this bug lived, quietly, for years.

Reward and Payout.

The report was accepted as a Medium-severity information disclosure vulnerability, and I received a 250 CHF bounty.

While the documents were intentionally public, the internal metadata they carried was not. This finding was a good reminder that information disclosure isn't always about accessing restricted files; sometimes, it's about what publicly available files reveal behind the scenes.

I hope you enjoyed this write-up and learned something from my experience. Until next time, keep learning, test responsibly, and stay blessed. 🙏🌾 https://x.com/ethical_h4ck3r_