In December 2025 and January 2026, an AI system autonomously discovered zero-day vulnerabilities in Node.js and React, two of the most widely deployed JavaScript runtimes and frameworks in the world. These weren't theoretical weaknesses or best-practice violations. They were exploitable security flaws that received CVE identifiers, and required patches from the Node.js and React core teams. This post documents how these vulnerabilities were found, the technical details of the flaws, and what this means for the future of security research. The Discoveries CVE-2026-21636: Node.js Permission Model Bypass via Unix Domain Sockets Node.js Medium CVE-2026-21636 Permission model bypass via unchecked Unix Domain Socket connections (CVE-2026-21636) Read Analysis Read Analysis Node.js introduced a Permission Model in recent versions - a security sandbox that restricts what code can do when run with the --permission flag. Think of it as Node's attempt to let you run untrusted JavaScript with some guarantees: you can allow filesystem access to specific paths, network access to specific domains, and so on. The vulnerability we discovered breaks this security boundary entirely. The Bug When the Permission Model is enabled without --allow-net , you'd expect that the running code cannot make network connections. And for TCP/IP connections, this holds true. But the implementation missed something: Unix Domain Sockets (UDS). Unix Domain Sockets are a form of inter-process communication that look syntactically similar to network connections but operate entirely on the local filesystem. They're used extensively by databases ( PostgreSQL , MySQL , Redis ), container runtimes ( Docker 's /var/run/docker.sock ), and countless other privileged services. The permission checks in Node.js didn't enforce network restrictions for the Unix socket path. When you connect to a UDS via net.connect({ path: '/var/run/docker.sock' }) , the permission model didn't intervene. JAVASCRIPT COPY // With --permission flag (no --allow-net) // This should be blocked, but wasn't: const net = require ( 'net' ); const socket = net. connect ({ path : '/var/run/docker.sock' }); socket. on ( 'connect' , () => { // You now have access to the Docker daemon // This breaks the entire sandbox }); The implications are severe. An attacker-controlled script that was supposed to be sandboxed could: Connect to the Docker socket and spawn privileged containers Access database sockets and extract sensitive data Communicate with any local service exposing a Unix socket Achieve local privilege escalation through socket-accessible services The fix added permission enforcement on Unix socket connection paths to ensure UDS access is covered. How We Found It Our system starts by building a complete understanding of the codebase. Not just the surface-level API, but the internal call graph, the permission checking logic, and the relationship between different subsystems. For Node.js, this meant understanding that the Permission Model is exposed via lib/internal/process/permission.js and that it hooks into various points in the standard library. The key insight came from analyzing what the permission checks actually check versus what developers assume they check. The permission model has explicit checks for: Filesystem operations ( --allow-fs-read , --allow-fs-write ) Network operations ( --allow-net ) Native addons ( --allow-addons ) Child process spawning ( --allow-child-process ) Inspector access ( --allow-inspector ) WASI ( --allow-wasi ) Worker threads ( --allow-worker ) But "network operations" is an under-specified category. The implementation equated "network" with "TCP/IP", missing that Unix sockets (which use the same API surface) are a distinct capability with distinct security implications. Our threat modeling agent generated the attack scenario: "If network restrictions only apply to TCP connections, can we bypass the sandbox by connecting to local sockets?" The analysis agent traced the code paths through net.connect() and confirmed that Unix socket connections bypassed the permission checks entirely. CVE-2026-23864: React Server Components Denial of Service React High CVE-2026-23864 RSC reply decoder DoS via $K FormData amplification (CVE-2026-23864) Read Analysis Read Analysis React Server Components (RSC) represent a fundamental shift in how React applications can be built. Server Components run on the server, render to a special format, and stream to the client. This creates a new attack surface: the protocol between client and server. The Bug The vulnerability exists in the RSC reply decoder, the code that parses responses from Server Functions. When a client sends a specially crafted HTTP request to a Server Function endpoint, it can trigger multiple failure modes: Infinite loops : Certain payload structures cause the decoder to loop indefinitely, consuming 100% CPU Out-of-memory exceptions : Other payloads trigger unbounded memory allocation Server crashes : ...