CVE-2026-102992 in piscina
Summary
by MITRE • 09/30/2026
piscina is a node.js worker pool implementation. Prior to 4.9.4, 5.3.2, and 6.0.0-rc.5, Piscina stores ThreadPool.options in src/index.ts as a plain object that inherits from Object.prototype. Applications with a separate prototype-pollution primitive can therefore supply inherited values for security-sensitive options that do not have own defaults. An inherited execArgv value is passed to the Node.js Worker constructor and can preload attacker-controlled code in worker threads, an inherited loadBalancer function can execute during task scheduling, and inherited env values can alter worker environments. This issue is fixed in versions 4.9.4, 5.3.2, and 6.0.0-rc.5.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified within the Piscina Node.js worker pool implementation stems from a prototype pollution flaw that allows attackers to manipulate configuration objects used during thread initialization. Prior to versions 4.9.4, 5.3.2, and 6.0.0-rc.5, the library stored ThreadPool options in src/index.ts as plain JavaScript objects that inherently inherit properties from Object.prototype. This design choice creates a critical security gap because it fails to isolate configuration values from inherited prototype properties. When an application possesses any primitive capable of injecting or modifying object prototypes, such as through unsafe merging operations like those found in lodash.merge or similar utilities, the attacker can inject malicious values into these shared defaults. Consequently, even if specific options are not explicitly set by the legitimate user code, they may still be populated with inherited values that were injected via prototype pollution, leading to unintended execution paths and privilege escalation within the worker threads.
The operational impact of this vulnerability is severe due to the direct influence it exerts over Node.js Worker thread construction. Specifically, an attacker can exploit the inherited execArgv property to inject arbitrary command-line arguments into the worker process initialization sequence. This capability allows for the preloading of attacker-controlled code modules before any application logic executes within the new thread, effectively bypassing security controls and enabling remote code execution or data exfiltration from a context that is typically isolated from the main event loop. Furthermore, the inherited loadBalancer function can be manipulated to execute custom logic during task scheduling phases, potentially disrupting service availability or causing denial of service conditions by introducing infinite loops or resource exhaustion strategies. Additionally, inherited environment variables (env) can be altered to change the runtime behavior of worker threads, such as modifying Node.js flags or injecting malicious environment-specific configurations that compromise the integrity and security posture of the entire application infrastructure.
From a classification perspective, this vulnerability aligns with CWE-1325, which pertains to Incorrectly Controlled Modification of Object Prototype Attributes, often referred to generically under CWE-94 as Improper Control of Generation of Code or Command Injection when it leads to code execution. In the context of attack tactics, this flaw facilitates initial access and command execution via ATT&CK technique T1059, specifically through JavaScript interpretation mechanisms within worker threads. The exploitation chain typically requires a prior prototype pollution primitive elsewhere in the application stack, highlighting that while Piscina is the vector for escalation, the root cause often lies in broader input validation failures across the Node.js ecosystem.
To mitigate this risk, organizations must upgrade to patched versions of Piscina, specifically 4.9.4, 5.3.2, or 6.0.0-rc.5 and later, which address the inheritance issue by ensuring that configuration objects do not inadvertently pull in prototype properties. Developers should also audit their codebase for unsafe object merging practices that could facilitate prototype pollution attacks against any library used within the application. Implementing strict input validation on all user-supplied data before it interacts with internal structures is essential to prevent injection of malicious prototypes. Additionally, employing static analysis tools and runtime security monitoring can help detect attempts to modify Object.prototype or other core JavaScript objects, providing an additional layer of defense against this class of vulnerabilities.