CVE-2021-48012 is a high severity (CVSS 8.2) prototype pollution flaw in the fast-toml npm package through version 0.5.4. TOML containing __proto__, constructor or prototype key segments can modify Object.prototype, causing denial of service or authorization bypass. No fixed version is confirmed, so check whether your code parses untrusted TOML.
What's affected
The fast-toml package, all versions through 0.5.4, per the record and VulnCheck. The record says the parse function can be made to modify Object.prototype when it receives TOML table headers such as the proto or constructor.prototype forms, or dotted keys that begin with the proto segment.
I could not confirm a fixed version. The project's repository has an open issue about the problem, and a pull request titled Security Fix for Prototype Pollution, but the pages I fetched do not show a released fix. Check the package's release page and npm for anything newer than 0.5.4 before relying on it.
Whether you are affected in practice depends on whether untrusted TOML ever reaches the parser. A package that only reads your own configuration files carries much less risk.
Package context matters too. The record says the flaw sits in the parse function. A project that imports the package but never calls that function is not exposed through it, and a project that calls it on fixed internal files is only exposed if those files can be changed by someone you do not trust, such as through a build pipeline that accepts outside contributions.
How to check if you're exposed
See whether fast-toml is in your dependency tree, directly or through another package:
npm ls fast-toml
For other package managers, search the lock file:
grep -n "fast-toml" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
If it appears, find the code that calls its parse function and trace where the input comes from. A configuration file shipped with your application is a trusted source. A file uploaded by a user, fetched from a remote location or generated by a third party is not.
The free in-browser dependency scan can list the affected package across a project in one pass.
Also check build tooling. A TOML parser can be pulled in by a bundler, a linter or a test runner rather than by your application. The inventory should include development and CI dependencies, because pollution in a build process can change what gets built.
What to do now
- Find every project that uses fast-toml, including indirect dependencies.
- Trace the parse calls and decide whether untrusted TOML can reach them.
- Check npm and the repository for a release after 0.5.4. If none exists, consider switching to a maintained TOML parser.
- Where you must keep the package, reject input containing proto, constructor or prototype keys before parsing it.
- Freeze the prototype of Object in sensitive processes if your runtime supports it, as defence in depth.
Why it matters
The class is CWE-1321 (Improperly Controlled Modification of Object Prototype Attributes), known as prototype pollution. In JavaScript, nearly every object inherits from Object.prototype. If a parser lets input write to that shared object, it changes behaviour for the whole process: every object suddenly has a property the attacker chose.
The effects depend on the surrounding code. A property that is checked for authorization can flip a decision. A property used in a loop can crash the process. The record names both outcomes, denial of service and authorization bypass.
This is a good case for reachability analysis. Having the package in a lock file is not the same as passing it hostile input. Knowing which of your calls can see untrusted data lets you rank this against other findings. The record does not mark this CVE as CISA KEV and makes no claim of exploitation in the wild.
Try it yourself
Reachability analysis shows whether vulnerable code is actually called with untrusted input. This demo shows how that cuts the list.
Click through it at your own pace, or open it full screen.
Quick check
Is there a fixed version of fast-toml?
I could not confirm one. The record says versions through 0.5.4 are affected. Check npm and the project repository.
Am I affected if I only parse my own config files?
Much less likely. The risk comes from untrusted TOML. Still, review whether input can ever be influenced by users or third parties.
Sources
Last reviewed: 19 October 2026.
