Key points
- BinaryMuse toml-node versions prior to 5.0.1 contain a prototype pollution vulnerability rated CVSS 8.8.
- The flaw allows attacker-controlled properties to be written to Object.prototype via the toml.parse() function.
- A fix is available in version 5.0.1, which resolves the issue by correcting key path handling logic.
The toml-node library for Node.js and browsers contains a high-severity prototype pollution vulnerability affecting versions prior to 5.0.1. Security researchers have assigned the flaw CVE-2026-114142 with a CVSS score of 8.8, indicating significant risk to applications using the parser.
What happened
The vulnerability exists within the quoteDottedString() function located in lib/compiler.js of the toml-node package. This function generates identical bookkeeping strings for distinct quoted key paths, which allows the addTableArray() method to inadvertently clear the guard for another key. This collision enables the assign() path to traverse through an unowned Date value without applying the required owned-container check. Consequently, the code can reach the prototype chain and write attacker-controlled properties directly to Object.prototype.
Why it matters
Objects created elsewhere in the running process can inherit these injected properties from the polluted prototype. According to the NVD record, this weakness is classified under CWE-1321, which relates to improper handling of special elements in a data stream. Because the flaw allows arbitrary property injection into the global prototype, it can compromise the integrity of data structures throughout the application. Any object that relies on clean prototype chains may behave unexpectedly or leak data due to these inherited properties.
What happens next
- Identify all Node.js projects that depend on the toml-node library.
- Check the current installed version against the vulnerable range of versions prior to 5.0.1.
- Update the package to version 5.0.1 or later to apply the security fix.
- Verify that the update resolves the prototype pollution risk in your specific environment.
Patch priority
Teams usually begin by identifying which services directly parse untrusted TOML input using this library. Systems that accept user-supplied configuration files or data streams should be updated first, as they face the highest exposure. Before rolling out the fix, validate the update in a staging environment to ensure compatibility with existing parsing logic. Back up current configurations and codebases before applying changes. If immediate patching is not feasible, restrict input sources to trusted origins only. Monitor logs for unexpected property assignments or prototype chain anomalies that might indicate exploitation attempts.
What to do and how to stay safe: toml-node
- Audit your dependency tree to find any indirect references to toml-node versions below 5.0.1.
- Implement strict input validation for all TOML data processed by your applications.
- Monitor application logs for unusual property inheritance or unexpected object behaviour.
- Once the vendor provides an update, test it thoroughly before deploying to production systems.
Step-by-step guide: Patch Management: Definition, Purpose and Operational Reality
General security guidance from the AppSec Scoop newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which versions of toml-node are affected by CVE-2026-114142?
All versions of toml-node prior to 5.0.1 are affected by this prototype pollution vulnerability.
Is there a fix available for this vulnerability?
Yes, the issue is fixed in version 5.0.1 of the toml-node library.
What is the severity rating of CVE-2026-114142?
The vulnerability has a CVSS score of 8.8, which is classified as high severity.
