es-toolkit@1.33.0 security report

Several functions, such as toPlainObject, mergeWith, and assignIn, manipulate object properties without sufficient protection against prototype pollution. For example, toPlainObject explicitly handles '__proto__' by using Object.defineProperty, but other functions like mergeWith may recursively assign properties and could be exploited to pollute Object.prototype if given malicious input. This can lead to advanced attacks such as privilege escalation or denial of service.

The template function builds a JavaScript function body from user-supplied template strings and executes it via new Function(...). This is a well-known code-injection risk. Although the implementation includes escaping of delimiters and is intended for template rendering, if an application passes untrusted input as the template string or options (e.g. sourceURL, variable, imports), arbitrary code can be executed in the host environment. This pattern is common in utility libraries (e.g. lodash's template), but it is still a dangerous capability and should be flagged when reviewing third-party packages.

The compiled function uses with(obj) { ... } to resolve variable references from the template against the provided object. This can lead to scope pollution and unintended variable access, especially if the object contains properties like __proto__ or constructor, potentially enabling prototype pollution or sandbox escape.

The invoke function resolves a method on an object using a caller-supplied path and applies it with args. If object originates from untrusted input or a prototype-polluted object, an attacker could invoke unintended methods (e.g., __proto__, constructor, or other properties reachable via the path) with attacker-controlled arguments. No sanitization or allowlist restricts which properties can be reached, so this behaves like a generic callable dispatcher. In the context of a utility library this is expected behavior, but it constitutes a dangerous primitive if the object/path is exposed to untrusted sources.

invokeImpl uses get(object, path.slice(0, -1), object) and get(parent, lastKey) to traverse arbitrary property paths. get is typically unfiltered for keys like __proto__, constructor, and prototype, meaning paths such as ['__proto__', 'polluted'] can reach prototype members. Combined with func?.apply(parent, args), this can lead to invoking prototype methods (e.g., constructor.constructor for Function-based code execution) if an attacker controls the path. This is a latent gadget rather than an obvious exploit in isolation.

The final func?.apply(parent, args) executes whatever function is located at the resolved path. If the resolved function is Function, eval, or a similarly powerful constructor obtained via a crafted path, it amounts to dynamic code execution. The code itself does not use eval/new Function, but it exposes a mechanism that can reach such constructs through prototype traversal (constructor.constructor).