Heap Buffer Overflow in Google Chrome Tab Groups

This repository is a small standalone browser exploit PoC consisting of four files: a README with setup/attack-chain notes, a Node.js static file server (server.js), a landing page (index.html), and the main exploit logic (exploit.js). The exploit is not part of a larger framework. The core capability is in exploit.js: it uses JavaScript and WebAssembly to exploit a V8/Chrome vulnerability by grooming arrays and creating memory corruption primitives. It implements addrof/fakeobj helpers, then arbitrary read and arbitrary write, discovers the RWX memory backing a WebAssembly instance, copies an embedded shellcode blob into that page, and transfers execution to it by invoking the wasm export. This is a classic browser-to-native-code execution pattern. server.js is only an auxiliary component that hosts the exploit files over HTTP on port 8888 by default. index.html simply loads exploit.js in the browser. The README describes the intended environment as a vulnerable Windows x64 Chromium/Chrome 90.0.4403.0 build and instructs the operator to browse to localhost:8888. It also describes a larger post-exploitation chain involving a downloader shellcode, implant.exe, and controller.exe, but those binaries are not present in this repository. There is a notable inconsistency in the claimed CVE: the README says the exploit relies on CVE-2021-21220, while index.html labels it as CVE-2021-21192. Regardless, the code clearly functions as an exploit PoC rather than a detector. Because the payload is embedded and executed directly but not operator-customizable within a framework, the maturity is best assessed as OPERATIONAL.

This repository is a compact browser exploit PoC for CVE-2021-21192 targeting a vulnerable Windows Chromium/Chrome build. The structure is minimal: README.md contains setup instructions, server.js is a simple Node.js static file server, index.html is the landing page that loads the exploit, and exploit.js contains the full client-side exploitation logic. The exploit flow is straightforward and operational. The user is instructed to obtain a specific Chromium snapshot, run the included local server, launch chrome.exe with --no-sandbox, and browse to localhost:8888. Once loaded, exploit.js uses a V8 bug pattern to corrupt array state and derive exploitation primitives: integer/float conversion helpers (ftoi/itof), addrof, fakeobj, arbitrary read, and arbitrary write. It then creates a WebAssembly instance to obtain an executable RWX memory page, reads the RWX page address from the wasm object, redirects an ArrayBuffer backing store to that address, copies a hardcoded native shellcode blob into the page, and finally invokes the WebAssembly export to transfer execution to the shellcode. There is no command-and-control logic, no remote callback infrastructure, and no post-exploitation framework integration. The only network exposure is the local HTTP server on port 8888 used to deliver the HTML/JavaScript to the browser. This is not a detection script and not merely a README; it is a real exploit PoC with an embedded payload, making it more than a basic crash PoC. However, because the payload is hardcoded and the repository is standalone rather than framework-driven, the maturity is best classified as OPERATIONAL rather than WEAPONIZED.