Prototype pollution is a common problem for Javascript applications.

This paper (PDF-link) is a reasonably comprehensive resource on the subject. It demonstrates that the problem is quite ubiquitous, and how it can turn into an unauthenticated RCE in Ghost, where the attack chain starts with a prototype pollution vulnerability in lodash.merge. Handlebars is used as the code execution gadget, but as Ghost also uses _.template it could have targeted that as well.

Lodash has had multiple prototype pollution vulnerabilities, including recently.

If _.template is ever invoked after the prototype has been polluted, an attacker can execute any Javascript, as sourceURL and variable are looked up via an options object and injected into the Javascript that gets executed. If the caller is not passing those options (which is the most common usage), then the values from the potentially polluted prototype would be used instead. Here's the smallest possible POC:

// If the prototype is polluted via some other vulnerability
> ({}).__proto__.sourceURL = '\nconsole.log("injected code here")'
'\nconsole.log("injected code here")'
// ... then arbitrary code can be injected
> _.template('hey')({})
injected code here
'hey'

I initially reached out via npm security, and got the feedback that this is not considered an issue. (In the thread with NPM security I also provided examples of how to weaponise this against real applications instead of just the repl example. I can provide additional examples privately.)

I think it's worth fixing, as the fix is simple. Applications that are susceptible to prototype pollution will still need fixing, but at least the commonly used _.template shouldn't provide easy code execution.

(I've signed the CLA.)