“Exposing patches before CVEs since 2025”
Tuesday, February 10, 2026
Feb 5, 2026, 07:26 PM — vercel/next.js
Commit: 6aeef8e
Author: nextjs-bot
The code was directly accessing the `$typeof` property on potentially untrusted objects without proper validation, allowing attackers to exploit prototype pollution to inject malicious `$typeof` properties. The patch introduces a `readReactElementTypeof` function that uses `hasOwnProperty.call()` to safely check for the property's existence on the object itself rather than the prototype chain.
if (value.$typeof === REACT_ELEMENT_TYPE) {
var typeName = getComponentNameFromType(value.type) || "\u2026",
key = value.key;
value = value.props;
Object.prototype.$typeof = Symbol.for('react.element'); const maliciousObj = { type: 'script', props: { dangerouslySetInnerHTML: { __html: 'alert(1)' } } }; // This would bypass React element validation due to polluted prototype
Feb 6, 2026, 08:03 PM — vercel/next.js
Commit: 6dfcffe
Author: Niklas Mischkulnig
The code performed integer division without checking for division by zero, which could cause a panic and crash the application. The patch replaces direct division with checked_div() to handle zero divisors safely.
if max_chunk_count_per_group != 0 {
chunks_to_merge_size / max_chunk_count_per_group
} else {
unreachable!();
}
Set max_chunk_count_per_group to 0 through configuration or input parameters. When make_production_chunks() is called with this configuration, the division chunks_to_merge_size / max_chunk_count_per_group will cause a panic, crashing the Turbopack bundler and causing a denial of service.
Feb 9, 2026, 10:38 PM — vercel/next.js
Commit: 9a2113c
Author: Luke Sandberg
The code incorrectly used max() instead of min() to clamp worker counts, causing all systems to be treated as having 64+ cores and potentially overflowing usize on systems with many actual cores. This could lead to memory exhaustion or application crashes.
let num_workers = num_workers.max(64); (num_workers * num_workers * 16).next_power_of_two()
On a system with a large number of cores (e.g., 10000), the calculation becomes: (10000 * 10000 * 16).next_power_of_two() = 1,600,000,000.next_power_of_two() = 2,147,483,648, which exceeds usize limits on 32-bit systems and causes massive memory allocation attempts leading to DoS.
Feb 4, 2026, 03:12 AM — facebook/react
Commit: 3ce1316
Author: Joseph Savona
The code had improper path resolution that allowed attackers to access files outside the intended directory structure. The patch fixes relative path resolution by properly normalizing paths relative to PROJECT_ROOT instead of allowing arbitrary relative paths from the current working directory.
const inputPath = path.isAbsolute(opts.path) ? opts.path : path.resolve(process.cwd(), opts.path);
yarn snap compile ../../../etc/passwd
Feb 4, 2026, 06:43 PM — facebook/react
Commit: cf993fb
Author: Hendrik Liebau
The recursive traversal of async node chains in visitAsyncNode causes stack overflow when processing deep async sequences. Database libraries creating long linear chains of async operations can trigger this DoS condition. The patch converts recursive traversal to iterative to prevent stack exhaustion.
function visitAsyncNode(...) {
if (visited.has(node)) {
return visited.get(node);
}
visited.set(node, null);
const result = visitAsyncNodeImpl(request, task, node, visited, cutOff);
// Create a deep chain of async sequences (10000+ levels)
let current = null;
for (let i = 0; i < 10000; i++) {
current = { previous: current, end: -1 };
}
// This deep chain will cause stack overflow in visitAsyncNode
// when React Flight processes the async node traversal
Feb 8, 2026, 07:14 PM — facebook/react
Commit: 2dd9b7c
Author: Jimmy Lai
The code incorrectly checked for debugChannel existence instead of debugChannelReadable, causing the server to signal debug info availability even with write-only channels. This could cause clients to block indefinitely waiting for debug data that never arrives, resulting in a denial of service condition.
debugChannel !== undefined,
// Server-side: Pass a write-only debug channel (no readable side)
const { Writable } = require('stream');
const writeOnlyChannel = new Writable({ write() {} });
renderToPipeableStream(component, { debugChannel: writeOnlyChannel });
// Client will now block forever waiting for debug data that cannot be read