Is the mammoth npm Package Safe? A DOCX Converter Security Review

The mammoth npm package is safe to use once you are on version 1.11.0 or later and you keep external file access disabled, but earlier releases carry a directory traversal flaw (CVE-2025-11849) that lets a malicious .docx file read arbitrary files from the machine doing the conversion. If your service accepts Word documents from users and runs mammoth server-side, this is worth an afternoon of your attention.

Mammoth is one of the most widely used Node libraries for turning .docx documents into clean HTML. It deliberately produces simple markup by mapping Word styles to semantic HTML instead of reproducing every inline style, which is why it shows up in CMS import pipelines, help-desk tools, and document-preview features. That popularity is exactly why its security posture matters: a single conversion endpoint often processes untrusted files from anonymous users.

What the mammoth npm package actually does

At its core, npm mammoth reads the XML inside a .docx container and emits HTML. A .docx file is a ZIP archive of XML parts plus embedded media. Mammoth walks the document body, resolves relationships (the word/_rels/document.xml.rels part), and renders paragraphs, tables, and images.

A minimal server-side conversion looks like this:

const mammoth = require("mammoth");

async function convert(buffer) {
  const result = await mammoth.convertToHtml({ buffer });
  return result.value; // the generated HTML
}

The interesting part for security is how images are resolved. Word can either embed an image inside the archive (an r:embed relationship) or link to an external location (an r:link relationship). That second path is where the trouble started.

CVE-2025-11849: the directory traversal flaw

CVE-2025-11849 is a directory traversal vulnerability that affects mammoth versions from 0.3.25 up to (but not including) 1.11.0. The root cause: when a document contained an image referenced with an r:link attribute instead of r:embed, mammoth did not validate the path or file type before reading it. An attacker who could get your application to convert a crafted .docx could point that external link at a sensitive local file.

Two concrete impacts:

• Arbitrary file read. A link pointing at something like a local config file or key material could have its contents embedded into the generated HTML output.
• Resource exhaustion. Linking to a special device file such as /dev/random or /dev/zero could make the converter block or consume excessive resources, a denial-of-service angle.

The exploit requires user interaction in the sense that the victim application has to process the malicious document, but for any product with an open "upload a Word doc" feature, that condition is trivially met.

Affected and fixed versions

Here is the version picture to keep straight:

• Vulnerable: 0.3.25 through any release before 1.11.0.
• Fixed: 1.11.0 and later.

If you are pinning below 1.11.0 for any reason, treat it as a known-vulnerable dependency and plan the upgrade.

# Check what you resolved
npm ls mammoth

# Upgrade
npm install mammoth@^1.11.0

Run npm ls mammoth rather than trusting package.json alone, because mammoth is frequently pulled in transitively by document-handling libraries. An SCA tool such as Safeguard can flag this kind of transitive exposure across a monorepo, but npm ls is enough for a single project.

Hardening the conversion pipeline

Upgrading closes CVE-2025-11849, but the design lesson is broader: never let a document format reach outside its own archive. Two defensive settings and habits are worth adopting.

First, review any code that sets externalFileAccess: true. If you enabled external file access to support linked images, that is precisely the behavior the vulnerability abused. Remove it unless you genuinely need it, and if you do keep it, sandbox the process. On patched versions the safe default is to leave external file access off:

const result = await mammoth.convertToHtml(
  { buffer },
  { externalFileAccess: false }
);

Second, treat mammoth's output as untrusted HTML. Mammoth produces cleaner markup than raw Word export, but the source document is attacker-controlled, so you should still sanitize the result before rendering it in a browser. A library such as DOMPurify on the server or client removes script vectors and dangerous attributes:

const createDOMPurify = require("dompurify");
const { JSDOM } = require("jsdom");
const DOMPurify = createDOMPurify(new JSDOM("").window);

const safeHtml = DOMPurify.sanitize(result.value);

Running document conversion in isolation

For any service that converts documents from the public internet, put the conversion in a constrained worker. A few practical controls:

• Run the converter in a container or worker process with a read-only filesystem and no network egress, so even a future traversal bug has nothing valuable to read or exfiltrate.
• Enforce a file-size limit and a conversion timeout to cap the DoS surface.
• Drop the process to an unprivileged user that cannot read application secrets or other tenants' data.

None of these depend on mammoth specifically. They apply to any parser that ingests complex, attacker-supplied file formats, which is why the same pattern shows up in guidance for image processors and PDF renderers.

Keeping mammoth patched over time

Document parsers are a recurring source of file-format vulnerabilities because the formats themselves are large and full of legacy features. The maintainable answer is automated dependency monitoring rather than one-time upgrades. Wire an advisory feed or software composition analysis into CI so a new mammoth advisory opens a pull request the same week it lands. Our writeup on software composition analysis covers how transitive advisories propagate through a lockfile, which is the mechanism that usually decides whether you are exposed.

FAQ

Is the mammoth npm package still maintained?

Yes. Mammoth continues to receive releases, and the fix for CVE-2025-11849 shipped in version 1.11.0, which is evidence the maintainer responds to security reports. Track the project's NEWS file for changes.

Which mammoth versions are affected by CVE-2025-11849?

Versions from 0.3.25 up to but not including 1.11.0 are vulnerable to the directory traversal issue. Upgrading to 1.11.0 or later resolves it.

Can I use npm mammoth in the browser instead of the server?

Mammoth has a browser build, and doing conversion client-side sidesteps server file-read risk entirely because there is no server filesystem to traverse. If your use case allows it, browser-side conversion is a reasonable hardening step, though you still sanitize the resulting HTML.

Do I still need to sanitize mammoth's HTML output?

Yes. Mammoth generates cleaner markup than a raw Word export, but the input document is attacker-controlled. Run the output through an HTML sanitizer before displaying it to other users.