zod@4.1.13 security report

The module calls config(en()) at import time, which is a side-effectful global initialization. While this is legitimate zod locale configuration and not malicious, it is top-level code that runs when the module is imported.

The $replace conditional type recursively transforms metadata types at compile time. This is a legitimate TypeScript utility and not runtime code execution, but deep recursive conditional types on untrusted complex schemas could lead to excessive type instantiation / compiler resource exhaustion (a known DoS vector for type-heavy packages) when consumers pass adversarial types.

The module writes to globalThis.__zod_globalRegistry at import time, mutating shared global state. While the stated intent is deduplication across CJS/ESM builds, attaching named properties to globalThis can be abused by other code to hijack or overwrite the registry (e.g., registry poisoning or prototype pollution scenarios) and makes the module's behavior dependent on ambient global state.

The statement (globalThis as GlobalThisWithRegistry).__zod_globalRegistry ??= registry<GlobalMeta>(); runs at module import time, creating a shared mutable registry on the global object. Any code that imports this module will automatically trigger this side effect, which is a common pattern exploited in supply-chain attacks to persist state or install hooks.

The allowsEval cached getter attempts new Function('') to probe whether dynamic code evaluation is allowed in the runtime, and returns false on Cloudflare Workers based on navigator.userAgent. This is a capability probe, not an exploit: it does not execute attacker-controlled input, and guards against environments where new Function would throw. It is a common pattern in validation libraries to decide whether to use eval-based fast paths. No payload, no exfiltration, no abuse.

randomString uses Math.random() to generate identifiers. This is cryptographically insecure and could be a problem if the output is used as a token, nonce, or session identifier. In this library the function appears to be a generic utility (e.g., for generating test/schema IDs), and no secret material is derived from it in this file, but callers should avoid using it for security-sensitive values.

The base64/hex conversion helpers use atob/btoa and manual byte array construction. These are standard encoding utilities, not obfuscation. No hidden payloads are present and no data is transmitted externally.

In write(arg), if arg is a function it is invoked twice: once with { execution: "sync" } and once with { execution: "async" }. This pattern mirrors documented magicast/ast-types-style code generation usage, but invoking a callback twice with the same Doc instance and different flags is a control-flow oddity worth reviewing: a callback that mutates this.content non-idempotently can duplicate or corrupt generated code, and the async pass suggests execution paths not fully visible in this file.

The file uses new Function/compile for JIT code generation in $ZodObjectJIT (Doc.compile). This is a legitimate optimization in Zod for object parsing. It does not use external/untrusted input to compile code; it generates code from schema shape keys after escaping them via util.esc. No eval, no process spawning, no network I/O.

randomString uses Math.random() to generate strings. This is not cryptographically secure and may be inappropriate for security-sensitive contexts (e.g., token generation), though within zod it is likely only used for internal identifiers.

createTransparentProxy and various Reflect.* operations allow unrestricted property interception, which could be misused if applied to security-sensitive objects, though by itself it is a normal library utility.

The allowsEval getter inspects navigator.userAgent for Cloudflare; behavior differing by environment can be a fingerprinting/evasion pattern, though here it plausibly reflects CSP/workerd constraints.

The assignProp and mergeDefs functions use Object.defineProperty and Object.assign with user-controlled keys (e.g., prop, descriptors from defs). While these are internal utilities, if exposed to untrusted input, they could allow modification of object prototypes or injection of malicious properties. However, in the context of schema definition (zod library), the inputs are typically developer-controlled.

The randomString function uses Math.random(), which is not cryptographically secure. If this function is used for generating tokens, nonces, or other security-sensitive values, it could introduce predictability. It appears to be a utility for generating random strings, but the naming and general-purpose nature warrant caution.

The captureStackTrace constant references Error.captureStackTrace, which is a V8-specific extension. This is not malicious but indicates environment-specific behavior. No security risk directly.

The allowsEval function uses new Function('') to test whether dynamic code evaluation is allowed in the current environment. While this specific call does not execute attacker-controlled code, the presence of this capability check suggests the library may conditionally use eval/Function elsewhere, which is a code smell and potential risk if inputs are not properly sanitized.

The finalizeIssue function constructs error messages and deletes certain fields (inst, continue, input). If not properly configured, error messages might include sensitive input data. However, there is logic to delete input unless ctx?.reportInput is true, which is a reasonable safeguard.

The base64 encoding/decoding functions use atob and btoa, which are standard in browsers and Node.js. No obfuscation or malicious payload is detected. However, these functions are often used in encoded payloads; here they appear to be legitimate codec utilities.

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.