Summary
Togoder Security scanned the npm package pino@10.0.0 on Oct 4, 2026. An AI review of 39 source files produced 1 high, 5 medium, 7 low severity findings. The overall verdict is medium: the findings flag risky but common patterns (dynamic code, unsafe defaults, broad file or network access) rather than confirmed malware.
Findings 13
Unvalidated version string injection
NPS-84DC72EDD7E2
The version passed via process.argv is trimmed and stripped of a leading 'v' but not otherwise validated before being interpolated into JavaScript source code written to lib/meta.js. A crafted version string (e.g., containing a quote and additional code) could inject arbitrary code into the generated meta.js module, which would execute when that module is later imported.
Dynamic code execution via vm module
NPS-645E699BEFC6
The code reads the contents of loglevel.js from node_modules and executes it using Node's vm module (vm.createContext, vm.Script, runInContext). While this appears to be for benchmarking purposes (wrapping loglevel's methodFactory), executing code from node_modules via vm could be exploited if the loglevel package were compromised or replaced with malicious code. It bypasses normal module loading and provides an implicit trust boundary crossing.
Prototype pollution / global scope modification
NPS-B597CAD0FDB0
The pfGlobalThisOrFallback function attempts to define a globalThis property directly on Object.prototype as a fallback mechanism to obtain a global object reference. Modifying Object.prototype is a dangerous anti-pattern that can lead to prototype pollution and unexpected behavior across the entire application. While the intent appears to be a legacy compatibility shim, this pattern could be exploited or cause collateral damage.
File system manipulation outside package scope
NPS-4530CE029FCC
The script writes to './package.json' using path.resolve, which resolves relative to the current working directory rather than the script's location. If run from an unexpected directory (e.g., a parent project directory), it could overwrite an unrelated package.json file.
Dynamic module loading with external input
NPS-6F6A296CD9BB
The function loadTransportStreamBuilder (target) dynamically loads modules based on the 'target' parameter. It uses realRequire and realImport with a path derived from 'target' (prepending 'file://' if not present). This allows loading arbitrary modules from computed input, which could be exploited to load malicious modules if an attacker controls the target path. However, the code includes some validation (the module must export a function), but the risk remains as dynamic loading of external input is present.
Use of eval-like dynamic import
NPS-E5B4FEEEA452
The use of realImport (dynamic import) on a computed URL (toLoad) can execute arbitrary code from the loaded module. Although the code attempts to handle errors and fallback to require, the dynamic import itself is a form of code execution from external input.
Process Spawning
NPS-72E8E30EDF49
Uses child_process.spawn to execute benchmark files. The spawned command uses process.argv[0] (the Node.js executable) with a path constructed from __dirname and a hardcoded benchmark name from the benchmarks object. While the benchmark name is user-controlled via process.argv[2], it is validated against the benchmarks map keys (basic, object, deep-object, etc.), and only those fixed filenames are passed to join. This limits the risk, but the general pattern of spawning child processes based on command-line arguments warrants noting.
Top-level Execution
NPS-4C41874187D6
The script executes immediately on import/run, parsing process.argv and launching benchmarks via steed.series. This is expected behavior for a benchmark runner CLI, but it is top-level code that runs without being explicitly invoked.
Filesystem access outside package scope
NPS-0D9B1864E9C2
The script reads a file from ../../node_modules/loglevel/lib/loglevel.js using readFileSync with a computed path. This is a relative path traverse outside the package's own directory (benchmarks/utils/). It relies on the presence and integrity of an external dependency and could be used to read arbitrary files if the path were influenced by external input in a different context.
Dynamic global object access with fallback
NPS-ECC65E8953E9
The code probes multiple global references (globalThis, self, window, this) and dynamically defines properties on Object.prototype to resolve the global scope. Although common in older browser-focused libraries, this pattern is a red flag when combined with object prototype mutation.
Potential path traversal / arbitrary file overwrite
NPS-7038C0CF0375
Both fs.writeFileSync calls use path.resolve with hardcoded relative paths. While the paths themselves are fixed, resolving relative to CWD rather than __dirname means the script can write to unexpected locations depending on where it is invoked from.
File system write outside package scope
NPS-8267876B0F99
The example writes log files to the OS temporary directory using a predictable filename based on the process ID. While this is intentional for the demo, writing to a shared temp location with a predictable name could allow symlink attacks or file clobbering if used in a privileged context.
Environment-dependent code execution
NPS-7AC7CB394A99
The code conditionally requires 'ts-node/register' or 'ts-node-dev' based on the presence of process[Symbol.for('ts-node.register.instance')] or process.env.TS_NODE_DEV. This means that if these environment variables or symbols are set, additional code (ts-node) will be loaded and executed. While this is a legitimate feature for TypeScript support, it represents a potential vector for execution of untrusted code if the environment is compromised.
Files reviewed
| File | Verdict | What the reviewer saw |
|---|---|---|
| benchmarks/utils/runbench.js | medium | This is a legitimate benchmark runner script with expected child process spawning and CLI argument handling; no malicious patterns were detected, though process spawning and top-level execution are noted as low-severity observations. |
| benchmarks/utils/wrap-log-level.js | medium | The script uses vm to execute loglevel code from node_modules for benchmarking, which is unusual but not overtly malicious; the main concern is dynamic code execution of external module content without integrity verification. |
| browser.js | medium | This is the well-known pino browser logger source; it contains no data exfiltration, backdoors, or process spawning, but it does use a risky Object.prototype fallback for global scope detection that could enable prototype pollution. |
| build/sync-version.js | medium | A build utility that syncs package version and generates a meta.js file; it lacks input validation on the version argument and uses CWD-relative paths for writes, creating code-injection and file-overwrite risks. |
| lib/transport-stream.js | medium | The code dynamically loads and executes modules based on an input parameter, which could be exploited for arbitrary code execution if the input is attacker-controlled, but no overt malicious patterns like data exfiltration or backdoors are present. |
| benchmarks/basic.bench.js | safe | No malicious patterns detected |
| benchmarks/child-child.bench.js | safe | This is a legitimate pino logging benchmark file with no malicious patterns detected. |
| benchmarks/child-creation.bench.js | safe | No malicious patterns detected; the file is a legitimate benchmarking script for loggers writing to /dev/null. |
| benchmarks/child.bench.js | safe | No malicious patterns detected; the code is a standard benchmarking script for logging libraries with no network, credential, obfuscation, or process execution concerns. |
| benchmarks/deep-object.bench.js | safe | No malicious patterns detected; the file is a legitimate benchmark script for comparing logging libraries, with no network exfiltration, credential harvesting, obfuscation, or suspicious system interactions. |
| benchmarks/formatters.bench.js | safe | No malicious patterns detected; file is a legitimate benchmark script for the pino logging library. |
| benchmarks/internal/custom-levels.js | safe | No malicious patterns detected |
| benchmarks/internal/just-pino-heavy.bench.js | safe | No malicious patterns detected |
| benchmarks/internal/just-pino.bench.js | safe | This is a benchmark file for the pino logging library that only writes to /dev/null and performs no network, credential, or system-level operations. |
| benchmarks/internal/parent-vs-child.bench.js | safe | No malicious patterns detected; this is a legitimate benchmark file for pino logging performance testing. |
| benchmarks/internal/redact.bench.js | safe | This is a legitimate benchmark file for the pino logging library; it writes only to /dev/null and contains no malicious patterns, network calls, credential harvesting, or dynamic code execution. |
| benchmarks/long-string.bench.js | safe | No malicious patterns detected |
| benchmarks/multi-arg.bench.js | safe | No malicious patterns detected |
| benchmarks/multistream.js | safe | This is a benchmark file comparing pino and bunyan logging performance, with no malicious patterns detected. |
| benchmarks/object.bench.js | safe | No malicious patterns detected |
| benchmarks/utils/generate-benchmark-doc.js | safe | No malicious patterns detected; the script only runs local benchmark subprocesses and prints documentation. |
| bin.js | safe | The bin.js script only prints a deprecation notice to stderr and exits with code 1, containing no malicious patterns. |
| examples/basic.js | safe | No malicious patterns detected |
| examples/transport.js | safe | This is a benign Pino logging example that only writes to the temporary directory and contains no malicious behavior. |
| file.js | safe | Cleared by Jev triage; no further analysis needed |
Show 14 more files
| File | Verdict | What the reviewer saw |
|---|---|---|
| lib/caller.js | safe | No malicious patterns detected; the code only retrieves caller file names using V8 stack traces. |
| lib/constants.js | safe | Cleared by Jev triage; no further analysis needed |
| lib/deprecations.js | safe | Cleared by Jev triage; no further analysis needed |
| lib/levels.js | safe | No malicious patterns detected; the code is standard Pino logging level management with no network, filesystem, process spawning, or obfuscated behavior. |
| lib/meta.js | safe | Cleared by Jev triage; no further analysis needed |
| lib/multistream.js | safe | No malicious patterns detected; the code is a legitimate Pino multistream implementation with no exfiltration, credential harvesting, obfuscation, or suspicious behavior. |
| lib/proto.js | safe | No malicious patterns detected; this is a legitimate Pino logger prototype implementation with standard logging functionality and no suspicious network, filesystem, process, or dynamic execution behavior. |
| lib/redaction.js | safe | No malicious patterns detected; the code is a legitimate redaction utility using the slow-redact library. |
| lib/symbols.js | safe | Cleared by Jev triage; no further analysis needed |
| lib/time.js | safe | No malicious patterns detected |
| lib/tools.js | safe | No malicious patterns detected; this is a legitimate logging library (pino) module with standard serialization, stream, and transport handling code. |
| lib/transport.js | safe | No malicious patterns detected; the code is a legitimate pino transport implementation using thread-stream for worker-based logging with no signs of exfiltration, credential harvesting, obfuscation, or other security concerns. |
| lib/worker.js | safe | No malicious patterns detected; the code is a legitimate pino.js worker for transport stream processing. |
| pino.js | safe | No malicious patterns detected; this is the legitimate pino logger entry point with only standard logging library functionality. |
Affected version ranges
None of the 2 scanned versions of pino are flagged high or critical. The latest scanned version, 10.3.1, is not scanned. Only versions we have scanned are listed; unscanned versions between them are not covered.
| Versions | Verdict | Count | Range | Top findings |
|---|---|---|---|---|
| 10.3.1 | Not scanned | 1 | 10.3.1 | |
| 10.0.0 | Needs review | 1 | 10.0.0 | Unvalidated version string injection; Dynamic code execution via vm module |
| 9.8.0 – 9.9.0 | Not scanned | 2 | >=9.8.0 <=9.9.0 | |
| 7.11.0 | Needs review | 1 | 7.11.0 | Dynamic module loading with computed input; Conditional dynamic require based on environment variables |
Full list, including published versions not scanned yet: version ranges API.
Scanned versions of pino
Frequently asked questions
Is pino safe to use?
No confirmed malware was found in pino@10.0.0, but the review flagged 1 high, 5 medium, 7 low severity findings for risky patterns worth checking before you rely on it.
Does pino contain malware?
No malware was identified in pino@10.0.0 when Togoder Security scanned it on Oct 4, 2026. A new version can still introduce malicious code, so scan the exact versions in your lockfile.
How was pino checked?
Togoder Security downloaded the published npm package and had an AI model read its 39 source files, looking for install scripts, credential access, network exfiltration, obfuscation, backdoors and crypto-wallet theft. The results are cached by file hash and shown here.
How do I scan pino together with the rest of my dependencies?
Upload your lockfile at https://security.togoder.click/scan or call the API documented at https://security.togoder.click/api-docs. Files that have already been scanned, like the ones in pino@10.0.0, cost nothing.