zod npm package: is it safe?

This file is a side-effect-only module that, upon import, mutates core.globalConfig.postProcessor and monkey-patches inst._zod.run on every schema constructed afterward. It runs top-level code at import time, modifying global behavior of the zod library. While documented and intentional, this kind of global monkey-patching in a package can surprise consumers and alter runtime semantics (e.g., silently replacing the parser with a compiled version).

The postProcessor wraps and replaces inst._zod.run with a shim that conditionally swaps in compiled execution paths. If compilation fails, it silently falls back to the original runtime. This is not malicious per se, but the pattern of globally intercepting schema execution could be abused in a supply-chain compromise to alter validation results (e.g., skipping checks) if the underlying compile module were tampered with.

The 'seal-cjs-exports' IIFE converts getters to fixed values and calls Object.freeze(exports), preventing downstream modification of the module's exports. This is defensive/anti-tampering and not malicious, but it does make the module harder to patch or audit at runtime.

The module installs a global postProcessor that invokes compile() on schemas. The code explicitly references JIT compilation and guards against new Function via the jitless config, indicating that the compiler generates functions dynamically. While the guard mitigates CSP bypass, this module still triggers dynamic code generation at parse time for any schema constructed after import, which is a significant attack surface if the compiler has flaws.

The postProcessor replaces inst._zod.run on schema instances with a shim, and stores __originalRun on the function object. This is a form of runtime monkey-patching that modifies shared library behavior. While the code comments explain the rationale, it can cause subtle interactions (e.g., double-wrapping, recursion guard via compiling flag) that may be exploitable or cause unexpected behavior in downstream consumers.

User-supplied JSON Schema pattern and patternProperties values are passed directly to new RegExp(...) without validation or escaping. While not malicious itself, this could expose consumers to ReDoS or catastrophic backtracking if untrusted schemas are converted. It is a normal part of implementing JSON Schema semantics, not a security backdoor.

The code explicitly uses assignProp to write __proto__ keys as own properties instead of through the inherited setter, and guards Object.entries/keys usage. This is defensive, not malicious.

JSON.parse(JSON.stringify(schema)) is used to normalize input, which is a deliberate defense against cyclic structures, getters, and Proxies. No dynamic evaluation is involved.

The compiler reflects over arbitrary user-supplied schemas and callbacks, hoisting user functions (def.fn, def.transform, def.catchValue, def.getter, check._zod.check, tx) into generated closures and invoking them. Errors thrown by these callbacks are intentionally propagated (throwAsync, transform helpers). This matches documented behavior but means any executable code attached to a schema will run during validation.

Uses Symbol.for("zod.compile.invalid") and Symbol.for("zod.compile.fallback") in the global symbol registry. Benign in itself, but registers globally reachable sentinels that other code could in principle collide with.

The allowsEval cached function probes for dynamic code execution capability via new Function(""), but this is a feature-detection pattern (checking if CSP/jitless environments permit eval), not an execution of external or untrusted input. The result is discarded and the construction is wrapped in try/catch. This is a common pattern in libraries that want to conditionally optimize code paths based on environment capabilities.

The code uses an IIFE that calls Object.getOwnPropertyDescriptor and Object.defineProperty to freeze exports; however this is a common pattern for module sealing, not obfuscated malicious code execution.

The file contains an immediately-invoked function expression (IIFE) that runs at import time, iterating over all exported properties, invoking their getters, and redefining them as non-configurable frozen values before calling Object.freeze(exports). While this pattern is used by some libraries to enforce immutable CommonJS exports, it executes arbitrary getter logic at module load and permanently mutates the module exports object. This can interfere with consumers and is an unusual pattern that warrants review, though it does not appear to exfiltrate data or execute external code.

The code calls desc.get() for every exported property whose descriptor defines a getter. If any re-exported module defines side-effecting getters, this would trigger those effects at import time. In this specific file the re-exported modules (errors, parseUtil, typeAliases, util, types, ZodError) are part of the Zod library and appear benign, but the mechanism itself is a potential vector for unexpected top-level execution.

The file executes code at import time, including a prototype manipulation initializer and an IIFE that seals/freezes the module exports. This is standard module initialization behavior, not a malicious install-time hook.

The initializer lazily installs non-enumerable getter/setter methods on the prototype of ZodError instances. It explicitly guards against touching Object.prototype and Error.prototype via a WeakSet to avoid prototype pollution. This is a deliberate design choice, not an attack pattern.

The 'seal-cjs-exports' IIFE at the bottom freezes the exports object and converts getter properties into non-writable, non-configurable values. This is a defensive measure used by some bundlers (e.g. esbuild-style or tsup output for Zod) to ensure CommonJS interop consistency. It does not execute external code, access the filesystem, or perform network activity. Behavior is deterministic and limited to the module's own exports object.

The file freezes its exports and replaces getters with static values to prevent later tampering. This is a legitimate hardening pattern used by Zod, not a malicious behavior.

Object.defineProperty on 'default', __createBinding, __setModuleDefault helpers mutate module exports. Standard TS/CommonJS interop, but the pattern combined with dynamic getter invocation in the sealing IIFE could be leveraged to force-evaluate attacker-injected getters if the package is compromised at publish time.

RegExp objects are dynamically constructed from def.includes, def.prefix, def.suffix in $ZodCheckIncludes, $ZodCheckStartsWith, $ZodCheckEndsWith. Values are passed through util.escapeRegex first, which mitigates ReDoS injection, but the pattern still takes runtime input into RegExp construction. This is legitimate validation logic for zod, not malicious.

The file executes an IIFE ('seal-cjs-exports') at module load time that enumerates all exports, invokes their getters, and freezes the exports object. Getters can run arbitrary code; while here they resolve to defined constructors, this pattern (firing property getters on import and freezing the module namespace) is unusual for a plain library module and can force evaluation of lazily-initialized code paths at import.

The file implements Zod validation checks (min/max length, size, numeric bounds, regex/format checks, property validation, etc.) using constructor helpers. It imports only internal modules (core, regexes, util). No network, filesystem, process, environment, or dynamic code execution APIs are used. The eval-like comment in $ZodCheckProperty is a legitimate regex anchor comment, not dynamic code execution. No obfuscated payloads, credential harvesting, exfiltration, mining, or backdoor patterns are present.

installCompiledUserMethods replaces parse and safeParse on the returned schema clone, and withParser replaces _zod.run. This is documented compiler behavior for schema objects only, not globals, and it captures originalRun/originalParse fallbacks. It is not a global monkey-patch, but it does mutate exported API surface and should be confirmed to not affect unrelated objects.

Generated code reads input properties once and calls .trim(), .toLowerCase(), .includes(), instanceof, %, etc. Object getters on untrusted input are invoked during fast-path validation (cached once per key, but still executed). This matches runtime parser behavior, though it means the compiled fast path is not safe for hostile objects with side-effecting getters unless the runtime parser has the same property.

The code explicitly guards against __proto__ keys in object shapes, records, and catchall loops (obj["__proto__"] prototype setter concerns). These guards appear defensive and correctness-oriented, but repeated handling of __proto__ and Object.getOwnPropertyNames/getOwnPropertySymbols walks indicates the compiler accepts attacker-influenced key names and must be audited to ensure the guards cannot be bypassed to cause prototype pollution in generated outputs.

Multiple generated sections call user callbacks directly: refinements (def.fn), superRefine checks (check._zod.check), transforms, overwrite transforms, catch values, lazy getters, string-format predicates, and discriminated-union literals. These are expected schema-author-owned functions, but they are hoisted into generated source and invoked at parse time. The helpers generateTransformCheck, generatePipeCheck, and generateCustomRefineCheck spoof payload/addIssue and deliberately do not catch throws, allowing arbitrary exceptions from user code to propagate.

The file does not import or reference any network APIs, environment variables, credential files, child_process, shell commands, filesystem manipulation, or crypto wallet logic. No obfuscation or encoded payloads were found.

newError temporarily sets Error.stackTraceLimit = 0 and restores it. It handles failures, but it still mutates a shared global object at parse time. If the restore is interrupted (e.g., a getter/setter trap on Error, or concurrent async code), the global stack trace limit can be left in an altered state for the entire process. This is a global side-effect rather than a security compromise, but it is a cross-cutting mutation of a shared builtin.

At module import time the code runs (_a = globalThis).__zod_globalConfig ?? (_a.__zod_globalConfig = {}), unconditionally creating a global property on the host environment. Importing the package therefore mutates the global object, which is a side effect that can interact with other libraries or be used as a coordination channel by other packages.

The code wraps schema parse functions at runtime and manipulates prototype-like properties, but does not use eval, Function constructor, or any dynamic code execution from external input. The wrapping is internal to the Zod memoization logic.

The file contains an IIFE at the bottom that seals and freezes exports at import time. This executes on module load but performs only local property descriptor inspection and freezing of its own exports; no network, filesystem, or process access.

The code assigns a global registry to globalThis.__zod_globalRegistry. This is expected Zod behavior for sharing a registry across module instances, not a malicious pattern. It only stores schema references and metadata locally and performs no network, filesystem, or process operations.

A top-level IIFE at the end of the file ('seal-cjs-exports') converts getter-only export properties into frozen data properties and calls Object.freeze(exports). This runs at import time but is a benign anti-tampering measure on the module's own exports; it does not touch global state, files, network, or processes.

The allowsEval cached getter uses new Function("") to probe whether eval-like dynamic code execution is allowed. While wrapped in try/catch and gated by config/userAgent checks, it directly invokes the Function constructor, which is a red-flag pattern for dynamic code execution and could be abused if the cached result or configuration is tampered with. The code does not actually execute attacker-controlled strings, but the presence of new Function at module import time is noteworthy.

The file contains a top-level IIFE 'seal-cjs-exports' that runs at import time, iterating over exports, invoking getters, and freezing the exports object. This is benign module hardening but constitutes code that executes on import. No network, filesystem, or process access is involved.

randomString uses Math.random() to generate strings. This is unsuitable for any security-sensitive use (tokens, IDs, nonces). The function is exported and could be misused by downstream callers expecting cryptographic randomness. This is a security-hygiene issue, not a malicious pattern.

Several utilities manipulate object descriptors and prototypes (mergeDefs, createTransparentProxy, putProp, mirrorShape, defineLazy, defineLazyInternal, installLazyProp, members, derived). finalizeIssue explicitly skips __proto__ keys, indicating awareness of prototype pollution. The code generally guards against inherited setters with assignProp/own, but the extensive use of Reflect and Object.defineProperty on arbitrary keys is a potential attack surface if inputs are attacker-controlled.

Helpers such as putProp, assignProp, deferProp, defineLazy, and defineLazyInternal use Object.defineProperty and guard with key in target. The code includes explicit defenses against __proto__ setter abuse and prototype pollution in putProp and finalizeIssue, indicating awareness of these risks rather than exploitation.

randomString uses Math.random(), which is not cryptographically secure. This is a quality concern for security-sensitive use but not malicious; it appears intended for non-cryptographic identifiers.

The allowsEval helper uses new Function('') to detect whether CSP/JIT restrictions allow dynamic code evaluation. This is a capability probe with the throw swallowed and no untrusted input passed, matching the documented purpose in the surrounding comment; it does not execute attacker-controlled code.

The code freezes the exports object and converts getters to static values. This is a defensive pattern to prevent runtime modification and does not constitute malicious behavior.

This file only re-exports the Ukrainian locale from './uk.cjs' and marks the previous 'ua' locale as deprecated. It contains no suspicious imports, network calls, environment access, dynamic execution, or process spawning.

The IIFE at the end of the file runs at import time to seal/freeze the exports object. This is a benign pattern used to prevent mutation of exports and does not perform any malicious activity such as network access, file system manipulation, or process spawning.

An IIFE executes at module load to seal exports by converting getters to static values and freezing the exports object. This is a defensive measure to prevent export tampering, not malicious. It does not access external resources, environment variables, or execute dynamic code.

The IIFE at the end of the module executes at import time, iterating over all own property names of exports, invoking getters, and redefining them as non-configurable, non-writable frozen values before calling Object.freeze(exports). While this pattern is a defensive measure common in library bundles (here likely to fix circular-require semantics), it is a top-level side effect that mutates the module namespace and can break consumers relying on live bindings or monkey-patching. Any module that runs code on import deserves scrutiny, though no exfiltration or command execution is present.

The sealing IIFE calls desc.get() on every configurable getter export. If any export were defined as a getter with side effects, those side effects would be triggered at import time. In this file the getters map to plain schema functions, so no malicious behavior occurs, but the pattern of invoking accessors over the whole exports object is unusual and would be a useful camouflage for lazily triggered payloads in a tampered package.