CVE-2026-97151 in mammoth.js
Summary
by MITRE • 09/24/2026
mammoth (aka mammoth.js) before 1.12.2 is vulnerable to prototype pollution when reading the styles defined in a document. Converting a crafted .docx file allows an attacker to add arbitrary properties to Object.prototype. In 1.11.0 through 1.12.1, applications that convert further documents in the same process and return the converted HTML can also disclose the contents of local server files (to the party supplying the documents) by setting externalFileAccess to true.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in mammoth.js prior to version 1.12.2 represents a critical security flaw rooted in improper handling of object properties during the parsing of Microsoft Word document styles. This issue manifests as prototype pollution, a technique where an attacker manipulates JavaScript objects by injecting or modifying properties on Object.prototype. When mammoth processes a specially crafted .docx file containing maliciously constructed style definitions, it fails to adequately sanitize input before assigning values to internal object structures. Because the library recursively merges configuration and style data without strict validation of property keys, an adversary can inject specific keys that resolve directly to the global prototype chain. This allows for the persistent modification of base JavaScript objects across the entire application runtime environment, potentially altering behavior in unpredictable ways or facilitating further exploitation vectors such as denial-of-service attacks through memory exhaustion or logic bypasses depending on how downstream code interacts with polluted prototypes.
In versions ranging from 1.11.0 to 1.12.1, this vulnerability is compounded by a secondary risk involving external file access capabilities. If the application utilizing mammoth.js has enabled the externalFileAccess option set to true, typically intended for resolving relative image paths or embedded resources within documents, an attacker can exploit the prototype pollution mechanism to influence how these references are resolved. By manipulating internal state through polluted prototypes, it becomes possible to redirect resource lookups toward local server file systems rather than strictly confined document assets. This misconfiguration allows a remote party supplying the malicious .docx file to read arbitrary files from the host system where the conversion process is executed. The disclosed contents could include sensitive configuration files, source code, or other confidential data residing on the same filesystem as the application, leading to significant information disclosure and potential compromise of server integrity.
From an industry standards perspective, this vulnerability aligns with CWE-1325, which covers Incorrect Check for Unusual or Exceptional Conditions in prototype pollution scenarios, and more broadly CWE-915 regarding Improper Modification of Objects with Affecting Other Components via Prototype Pollution. The exploitation technique maps directly to MITRE ATT&CK tactic Tactic TA0004: Privilege Escalation under the specific technique of Impair Defenses or potentially Initial Access if used in conjunction with other vectors, though primarily it falls under Impact categories related to Data Exfiltration and Denial of Service. The ability to read local files via external resource resolution also touches upon CWE-284 Improper Access Control, as the application fails to restrict file system access based on the origin or trust level of the input data.
Mitigation strategies must prioritize immediate upgrading to version 1.12.2 or later, where these prototype pollution vectors have been addressed through stricter validation and isolation of object merging operations. For environments that cannot immediately upgrade, it is imperative to disable external file access by ensuring externalFileAccess remains false unless absolutely necessary for legitimate functionality. Additionally, implementing input sanitization at the application layer before passing data to mammoth.js can provide a defense-in-depth measure. Developers should also consider using libraries or utilities that enforce strict object property checks and avoid direct assignment of untrusted keys to objects. Regular security audits focusing on third-party library usage patterns are essential to identify similar risks in other components that handle complex document formats or dynamic configuration merging.