Critical Code Injection Vulnerability Found in Tinypool (CVE-2026-104849)

A critical security vulnerability has been discovered in Tinypool, a lightweight Node.js worker-thread pool used by applications to run JavaScript tasks across worker threads.

Tracked as CVE-2026-104849, the vulnerability can allow an attacker to cause an application to load and execute an attacker-controlled JavaScript module. The flaw has been assigned a CVSS 4.0 score of 9.5, placing it in the critical severity category.

The vulnerability affects versions of Tinypool before 2.1.2 and has been addressed in version 2.1.2.

What is Tinypool?

Tinypool is a minimal worker-thread pool implementation for Node.js. Worker pools allow applications to execute tasks using multiple worker threads rather than handling everything within the main Node.js process.

The library can be used by other JavaScript and Node.js projects as a dependency, meaning an application may use Tinypool without developers necessarily interacting with the library directly.

This makes vulnerabilities in relatively small open-source dependencies important, as they can potentially affect larger applications further up the software supply chain.

What is CVE-2026-104849?

CVE-2026-104849 is classified as CWE-94, Improper Control of Generation of Code, commonly referred to as code injection.

The problem occurs because vulnerable versions of Tinypool can read the filename property from an options object supplied to pool.run() without checking that the property actually belongs to that object.

An attacker who has already managed to pollute JavaScript’s Object.prototype can therefore potentially introduce a malicious filename property.

When an affected application subsequently supplies its own options object to pool.run(), Tinypool may use the attacker-controlled value rather than the filename intended by the application.

How the attack works

The vulnerability involves a combination of prototype pollution and the way Tinypool handles worker-module filenames.

JavaScript objects can inherit properties from Object.prototype. If an attacker is able to modify that prototype, properties that were not explicitly supplied by an application can appear to exist on other objects.

In the vulnerable Tinypool implementation, the filename used for a worker could be obtained from an inherited property.

This creates a potential attack chain:

1. An attacker first needs a way to pollute Object.prototype.
2. The attacker introduces a malicious filename property.
3. An affected application calls pool.run() while supplying an options object.
4. Tinypool obtains the inherited filename.
5. The worker pool can then load the attacker-selected JavaScript module.
6. The malicious code executes with the privileges of the host Node.js process.

The vulnerability therefore does not necessarily provide an attacker with a direct entry point by itself. A prototype-pollution vulnerability or another mechanism capable of modifying the relevant JavaScript object prototype may be required first.

Potential impact

If successfully exploited, the vulnerability could allow attacker-controlled JavaScript to execute within the affected Node.js application environment.

According to the vulnerability information, malicious code could potentially read or modify task data and operate with the privileges available to the host process.

Depending on the application and the permissions available to its Node.js process, successful exploitation could therefore affect:

• Confidentiality of application data
• Integrity of application data
• Availability of the application
• Data processed by worker threads
• Other resources accessible to the Node.js process

The CVSS 4.0 assessment gives the vulnerability a score of 9.5. The published vector identifies network attack access, low attack complexity, no privileges required and no user interaction, while also noting that attack requirements are present.

Who is affected?

The affected software is:

Tinylibs Tinypool

Affected versions: earlier than 2.1.2

Fixed version: 2.1.2

Applications that do not provide a second options argument to pool.run() use a trusted default options object and are not affected by this particular filename lookup path, according to the published vulnerability description.

However, organisations should still check how Tinypool is being used within their applications rather than assuming that the dependency is safe simply because it is not directly exposed to the internet.

Supply-chain implications

CVE-2026-104849 highlights the security risks associated with software dependencies.

Modern Node.js applications frequently depend on large numbers of third-party packages. A vulnerability in a relatively small library can therefore become relevant to applications that use it indirectly through another package.

Developers should identify whether Tinypool is installed directly or appears somewhere in the dependency tree.

Dependency-management tools can help identify vulnerable versions, while software composition analysis can provide a broader view of affected components.

Updating Tinypool

Developers using an affected version should update Tinypool to version 2.1.2 or later.

Where Tinypool is installed directly, the dependency can be updated through the project’s normal Node.js package-management process.

Where it is an indirect dependency, developers should check which package is bringing Tinypool into the application and determine whether updating that parent dependency also brings in the fixed version.

After updating, applications should be tested to ensure that worker-thread functionality continues to operate correctly.

Why prototype pollution matters

The vulnerability also demonstrates why prototype pollution remains an important security concern in JavaScript applications.

Prototype pollution can allow attackers to add or modify properties on shared JavaScript prototypes. Those properties can subsequently be inherited by other objects throughout an application.

On its own, a polluted prototype does not automatically mean arbitrary code execution. The impact depends on how an application or library subsequently uses inherited properties.

In the case of CVE-2026-104849, the inherited filename property can influence which JavaScript module Tinypool attempts to load, turning a prototype-pollution condition into a potential code-execution scenario.

What organisations should do

Organisations using Node.js applications should check their dependency inventories for Tinypool versions earlier than 2.1.2.

Security teams should:

• Identify applications using Tinypool.
• Check whether vulnerable versions are installed.
• Determine whether Tinypool is a direct or transitive dependency.
• Upgrade to Tinypool 2.1.2 or later.
• Review applications for possible prototype-pollution vulnerabilities.
• Monitor applications for unexpected JavaScript module loading.
• Rebuild and redeploy applications after dependency updates where appropriate.
• Review Node.js process permissions and limit access to sensitive resources.

Applications that expose prototype-pollution vulnerabilities should receive particular attention because such a vulnerability could potentially provide the prerequisite condition needed to exploit CVE-2026-104849.

Conclusion

CVE-2026-104849 is a critical vulnerability in the Tinypool Node.js worker-thread library that can potentially turn prototype pollution into attacker-controlled JavaScript execution.

The vulnerability affects Tinypool versions before 2.1.2 and has been fixed in version 2.1.2. With a CVSS 4.0 score of 9.5, organisations using the affected library should identify vulnerable installations and update them.

The incident is another reminder that the security of a modern application depends not only on its own code, but also on the numerous open-source components sitting underneath it.