Summary
Togoder Security scanned the npm package pino@7.11.0 on Oct 4, 2026. An AI review of 18 source files produced 6 medium, 3 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 9
Dynamic module loading with computed input
NPS-7168E33DED32
The function loadTransportStreamBuilder accepts a 'target' parameter and dynamically loads it as a module using realImport or realRequire, depending on file extension. The target is controlled by the caller, which could allow loading arbitrary modules if an attacker can influence the target value. This is not inherently malicious but poses a security risk if the input is untrusted.
Conditional dynamic require based on environment variables
NPS-E3E3943F812B
The code conditionally requires 'ts-node/register' or 'ts-node-dev' based on process signals or environment variables (TS_NODE_DEV). This could be exploited if an attacker can set environment variables to trigger loading of malicious modules named 'ts-node' or 'ts-node-dev' from the current working directory or node_modules, potentially leading to arbitrary code execution.
Spawning processes via worker threads
NPS-B205C477442B
The code uses ThreadStream from the 'thread-stream' package, which spawns worker threads to execute JavaScript files specified by the 'filename' argument. This is a form of process/thread spawning that could execute arbitrary code if the filename is controlled by an attacker. The filename is derived from the 'target' option after resolution, which again could be user-controlled.
Potential for arbitrary file execution
NPS-35C54F4E288E
The transport function allows specifying a 'target' that is resolved to an absolute path or file:// URL and then passed to buildStream, which creates a ThreadStream with that filename. If an attacker can control the 'target', they could execute arbitrary JavaScript files on the system. This is a design feature of pino transports but poses a security risk when used with untrusted configuration.
Dynamic module loading with computed input
NPS-B0956E593E8A
The fixTarget function uses createRequire(filePath).resolve(origin) to dynamically resolve and load modules based on the 'origin' parameter, which can be influenced by user input via the transport options. This could allow loading of arbitrary modules if an attacker can control the 'target' or 'targets' option, potentially leading to code execution. While this is intentional for the package's functionality (pino transport), it represents a risk if untrusted input is passed to the transport configuration.
Dynamic module loading
NPS-9F3BE6DBB73C
The function loadTransportStreamBuilder(t.target) dynamically loads and executes modules based on configurable target paths provided in the targets array. If an attacker can control the targets configuration, they could load arbitrary modules, potentially leading to code execution. However, this is standard functionality for the pino transport system and not inherently malicious.
Use of real-require and real-import to bypass module loaders
NPS-D48FC1E08376
The code uses 'real-require' and 'real-import' to bypass Node.js module caching and loaders, which could be used to evade security controls or monitoring. While not malicious per se, it could be used to load modules that would otherwise be blocked.
Process termination / stream closing
NPS-358CB6D93F10
The close function ends all transport streams and invokes a callback. While not inherently malicious, this could be abused to cause denial of service by forcing premature closure of logging streams.
Data writing to multiple streams
NPS-A7205D5A36AA
The process function writes incoming data chunks to multiple target streams via pino.multistream. If targets are configured to external locations, this could result in data exfiltration, but this is expected behavior for a logging transport module.
Files reviewed
| File | Verdict | What the reviewer saw |
|---|---|---|
| lib/transport-stream.js | medium | The code dynamically loads modules based on a provided target and conditional environment variables, which could be exploited if input is untrusted, but no direct malicious patterns were found. |
| lib/transport.js | medium | The code exhibits dynamic module loading and worker thread spawning based on user-controllable inputs, which are inherent to its functionality but could be exploited if untrusted data is passed to the transport configuration. |
| lib/worker.js | medium | The code appears to be a legitimate pino transport worker that dynamically loads transport modules based on configuration; the main security concern is dynamic module loading which could be exploited if configuration is attacker-controlled. |
| bin.js | safe | The bin.js script only prints a deprecation notice to stderr and exits with code 1, containing no malicious patterns. |
| browser.js | safe | No malicious patterns detected; this is a legitimate browser logging library (pino) with standard logging functionality and no data exfiltration, obfuscation, or other security concerns. |
| file.js | safe | Cleared by Jev triage; no further analysis needed |
| lib/caller.js | safe | No malicious patterns detected; the code only retrieves caller file names using V8 stack traces. |
| lib/deprecations.js | safe | No malicious patterns detected; the file only registers deprecation warnings using process-warning. |
| lib/levels.js | safe | No malicious patterns detected; the code implements standard logging level management without exfiltration, credential harvesting, dynamic code execution, or other suspicious behaviors. |
| lib/meta.js | safe | Cleared by Jev triage; no further analysis needed |
| lib/multistream.js | safe | No malicious patterns detected; the code is a standard multistream implementation for the pino logging library with no external calls, credential access, dynamic execution, or process spawning. |
| lib/proto.js | safe | No malicious patterns detected in this Pino logger prototype file; it contains standard logging functionality without data exfiltration, credential harvesting, obfuscation, or process execution. |
| lib/redaction.js | safe | This is a legitimate log redaction module from the pino logging library that only processes path configuration and censors sensitive fields locally without any network, filesystem, or process manipulation. |
| lib/symbols.js | safe | Cleared by Jev triage; no further analysis needed |
| lib/time.js | safe | Cleared by Jev triage; no further analysis needed |
| lib/tools.js | safe | No malicious patterns detected; the code appears to be the legitimate pino logging library with expected functionality. |
| lib/worker-pipeline.js | safe | No malicious patterns detected; the code uses standard Node.js stream pipelines with no data exfiltration, credential harvesting, obfuscation, or shell execution. |
| pino.js | safe | No malicious patterns detected in pino.js; the code appears to be the legitimate pino logging library with standard Node.js module usage and no suspicious behavior. |
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@7.11.0, but the review flagged 6 medium, 3 low severity findings for risky patterns worth checking before you rely on it.
Does pino contain malware?
No malware was identified in pino@7.11.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 18 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@7.11.0, cost nothing.