Metadata in published files

A document you publish contains more than what it says. File formats keep track of who worked on it, with which software, on which computer and where the file was stored. That data is invisible while reading and entirely visible to whoever looks for it. What sits in there is more than a curiosity.

What is metadata?

Metadata is the data a file keeps about itself, separate from its content. For a text document that means the author, the organisation, the software used and its version, the creation and modification dates and often the full path where the file was stored. For a PDF, the producing software and sometimes the editing history come on top. For a photo it is the camera model, the settings, the timestamp and, on a phone, usually the coordinates.

That information appears automatically and is rarely reviewed deliberately. Whoever publishes a report, a form or a manual thinks about the content; nobody opens the file properties to see what else is in there.

Compare it with a letter on headed paper that also carries, in small print, the name of the typesetter, the address of the print shop and the date of the previous version. For the reader nothing changes. For whoever is mapping an organisation, there is a good deal to work with.

What comes out?

Vulnerable:

An organisation publishes a report on its website. Whoever reads the properties finds:

Title            : Annual report 2025 (draft v4)
Author           : m.walker
Last edited by   : j.vanleeuwen
Organisation     : Example Ltd
Software         : Microsoft Word 2016 (16.0.4266)
Created          : 2025-11-14 09:22
Path             : \\fileserver01\departments\finance\reports\2025\

Seven lines carrying a considerable amount of information. There are two usernames, and they evidently follow the pattern initial-dot-surname, which means the username of every employee can be derived from a name on the company website. There is a server name and a folder structure from the internal network. And there is a software version, which indicates which vulnerabilities may apply to those workstations.

To an attacker this is the material for a targeted attack: valid usernames for a password attempt, an internal path to point at, and knowledge of the software in use for a convincing phishing email.

Safe:

// Cleaning as part of publishing, not as a separate action
import sharp from 'sharp';
import { PDFDocument } from 'pdf-lib';

async function publishImage(source, target) {
  // Regenerating removes all metadata, including location data
  await sharp(source).rotate().withMetadata({ exif: {} }).toFile(target);
}

async function publishPdf(source, target) {
  const pdf = await PDFDocument.load(await fs.promises.readFile(source));
  pdf.setTitle('');
  pdf.setAuthor('');
  pdf.setSubject('');
  pdf.setKeywords([]);
  pdf.setProducer('');
  pdf.setCreator('');
  await fs.promises.writeFile(target, await pdf.save());
}

The intervention sits in the publishing process, and that is deliberate. A manual step saying “remember to wipe the properties” works the first few times and then does not. An automatic operation at publishing applies to every file, including the one someone uploads in a hurry.

What is the impact of metadata in published files?

The severity is usually low to medium. No direct attack is possible and no access is gained; it concerns information that eases the next steps.

Those next steps are concrete, though. Usernames are half of every login attempt, and a derived naming pattern yields hundreds at once. Internal server names and paths are usable in attacks referring to a network location, and they give a picture of the internal structure. Software versions determine which known vulnerabilities are relevant. And with documents edited by several parties, the history reveals who was collaborating.

The exception where it becomes more serious concerns personal data. Location data in photos and names of individuals in documents are data you are responsible for under the GDPR. Publishing a photo revealing where and when it was taken is a processing you probably did not intend.

How do you detect metadata in published files?

A tester gathers an organisation’s published files, reports, forms, manuals, presentations, images, and reads the properties from them. That is largely automatable and nearly always yields results at an organisation with many publications.

Attention goes to recurring patterns. Two usernames say little; twenty usernames all following the same pattern yield a convention by which every employee gets a username. Server names, internal domains and software versions are examined too, along with documents where deleted or redacted text turns out to still be present. AssistSec includes this analysis when mapping your external visibility, because the usernames found are directly usable in the next phase of a test, and therefore also by an attacker.

How do you prevent metadata in published files?

• Remove metadata automatically at publishing, not as a manual step afterwards.
• Regenerate images, so location data and device information disappear.
• Wipe author, organisation, paths and software details from documents and PDF files.
• Remove redacted passages from the source rather than covering them.
• Check that editing history and comments have been removed before you publish.
• Use a neutral author name for publications rather than an employee’s.
• Include the cleaning for files uploaded by users and shown again.
• Periodically review what is already published; existing files do not clean themselves.