es-toolkit npm package: is it safe?

The template function constructs and executes arbitrary JavaScript via new Function(...). While this is a standard lodash-compatible template feature, it permits code injection if untrusted templates are processed. This is a known risk surface for prototype pollution or RCE in downstream applications.

The code explicitly guards against __proto__ in isUnsafeProperty and get/unset/mergeWithDeep/updateWith. However, several paths (e.g., set, zipObject, fromPairs, assignValue, pick, keyBy, groupBy, mapKeys, toPlainObject partially) assign arbitrary string keys without consistent __proto__ filtering. updateWith skips unsafe keys but still allows constructor/prototype traversal in nested arrays. This could enable prototype pollution in some call paths if user-controlled keys are used.

The template compilation embeds user template code inside a with(obj) { ... } block, which is a legacy, unsafe construct that can leak/observe the entire scope object and is disallowed in strict mode. Combined with new Function, this increases injection and sandbox-escape risk.

The clone function invokes constructors derived from the cloned object: new Ctor(...) for typed arrays and boxed primitives, new obj.constructor(obj.valueOf()) for boolean/number/string objects, and new Ctor(typedArray.buffer, ...). If clone() is called on an attacker-controlled object (e.g. from JSON parsed data or a malicious package), this can execute arbitrary constructor code and is a known gadget pattern for prototype-pollution-to-RCE chains.

copyPrototype() sets the target object's prototype to the source object's prototype using Object.setPrototypeOf. When cloning untrusted objects, this can propagate a polluted or attacker-controlled prototype (e.g. a modified Object.prototype) to the cloned object, potentially leading to prototype pollution downstream. Additionally, copyOwnProperties uses for...in and conditionally copies properties, and copySymbolProperties copies enumerable symbols; these patterns can carry over malicious properties from untrusted sources.

The function uses isUnsafeProperty to skip dangerous keys like __proto__, constructor, and prototype. However, if isUnsafeProperty is incomplete or bypassable (e.g., via encoded keys or alternative prototype pollution vectors), this could lead to prototype pollution. The code itself attempts to prevent this, but the security depends entirely on the correctness of the imported isUnsafeProperty implementation.

The function dynamically assigns properties to objects based on user-provided paths via assignValue. While it attempts to block unsafe properties, this pattern is commonly associated with prototype pollution vulnerabilities if the guard is insufficient.

The template function uses new Function(...) to compile and execute a string constructed from user-supplied template content. This is inherent to the template engine design (similar to lodash.template) but creates a potential code injection risk if the template string or options are controlled by untrusted input. The constructed source includes user-supplied evaluate blocks, interpolated expressions, and with(obj) scoping.

The template function compiles and executes arbitrary JavaScript code at runtime using new Function(). The evaluate delimiters (<% %>) allow embedding and executing arbitrary JavaScript expressions, which is an inherent security risk if template sources are untrusted. This is a common pattern in template engines (like lodash.template) but can lead to RCE when user-controlled input reaches the template string or options.

The imports option allows passing arbitrary values that are injected as parameters into the dynamically constructed function. If an attacker can control options.imports, they can influence the execution environment of the compiled template.