Possible Prototype Pollution

[yoshino-s]

I have found a possible prototype pollution vuln in this package.
With speficific input attckers can define properties on prototype, which will lead to prototype pollution.

Also I have made a tiny fix to prevent acccess prototype, which may fix this vuln.

418sec#1

Should we accept the pr or write some alert to users to do not use untrusted input?

[silentmatt]

Thanks for finding and fixing this! I had it create a pull request (#252) and I'll make sure it gets merged and released soon.

[yoshino-s]

Thanks a lot.

[yoshino-s]

By the way, should we submit it to github security advisory and npm advisory, which will automatically alert downstream package and app? And, can we apply for an CVE ID for the vuln, which can help me a lot?
Thanks a lot.

[yoshino-s]

any progress here?

[motherthestate]

Any reason why this issue is still open?

[willstott101]

Despite a fix being merged there's been no release yet :(

It would be great if we could cut a 2.0.3 release

[FAIZ117]

For the record: upstream master's merged fix (6c475a1) covers bare variable names only, and pays a regex per variable read per evaluation. The fork expr-eval-nextgen bans these names at parse time in all three positions (variable, member, parameter — e.g. a.constructor and f(__proto__) are rejected too, which the master fix doesn't cover), plus a scope-object gate for CVE-2025-12735. Parse-time rejection also means zero per-evaluation cost.