GHSA-85c8-ppgw-ccpr: Code Injection
tinypool is a fork of piscina and inherited the same prototype-pollution surface. When pool.run(task, options) is called, the filename option is read from the provided options object. If that object does not have an own filename property, the lookup falls through to Object.prototype.
An attacker who can pollute Object.prototype.filename (for example, via a vulnerable lodash.merge, qs.parse, or similar elsewhere in the application) can make tinypool load and execute an attacker-controlled worker module.
This is the tinypool counterpart to the piscina root discovery GHSA-x9g3-xrwr-cwfg.
pool.run(task) with no second argument is not affected, because kDefaultOptions.filename is null and the options object is not user-controlled. The exploit only triggers when the caller passes their own options object to pool.run().
Impact
Arbitrary JavaScript execution in the worker pool. If the application passes attacker-controlled data as the run() task and also supplies a run() options object, the attacker can redirect execution to a malicious worker that exfiltrates or modifies that data, achieving remote code execution and/or data exfiltration.
Proof of Concept
js // legitimate-worker.mjs export default async (task) => ({ by: 'legitimate-worker', processed: task })
// malicious-worker.mjs export default async (task) => ({ by: 'attacker', stolenRequestBody: task })
// main.js import express from "express"; import Tinypool from "tinypool"; import { fileURLToPath } from "node:url"; import path from "node:path";
const dirname = path.dirname(fileURLToPath(import.meta.url));
// Simulate upstream prototype pollution (lodash merge, qs parse, etc.) Object.prototype.filename = path.join(dirname, "malicious-worker.mjs");
const pool = new Tinypool({ filename: path.join(dirname, "legitimate-worker.mjs"), });
express() .use(express.json()) .post("/", async (req, res) => { const ac = new AbortController(); const result = await pool.run(req.body, { signal: ac.signal }); res.json(result); }) .listen(31337);
Suggested fix
Read all user-supplied options from own properties only (Object.hasOwn or Object.prototype.hasOwnProperty.call) and build the internal ThreadPool.options object with a null prototype.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/tinypoolto a version that resolves this vulnerability.Fixed in 2.1.2 - Compensating control
Read all user-supplied pool.run() options from own properties only using Object.hasOwn or Object.prototype.hasOwnProperty.call, and build the internal ThreadPool.options object with a null prototype.
Event History
Frequently Asked Questions
Which application flows are exposed?
Exposure requires code that calls pool.run(task, options) with a caller-supplied options object. An attacker must also be able to pollute Object.prototype.filename, such as through a separate prototype-pollution issue in the application.
Are calls to pool.run(task) without a second argument affected?
No. Calls with no second argument use the default filename value of null and do not use an attacker-controlled options object.
What can an attacker do if exploitation succeeds?
They can cause tinypool to load an attacker-controlled worker module and execute arbitrary JavaScript in the worker pool. The malicious worker may exfiltrate or modify data.
How can I assess whether my application is potentially affected?
Review uses of pool.run() for calls that pass an options object, especially where task data is attacker-controlled. Also identify any paths that could allow prototype pollution of Object.prototype, including vulnerable object-merge or query-string parsing behavior.