CVE-2021-21220 is an insufficient validation flaw in the V8 JavaScript and WebAssembly engine in Google Chrome prior to version 89.0.4389.128. A remote attacker could use a crafted HTML page to trigger heap corruption while the page is processed by a vulnerable browser.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
6 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a full offensive lab rather than a single minimal PoC. It implements an end-to-end browser-to-implant intrusion chain centered on CVE-2021-21220. The structure is split across six Dockerized services: an exploit server hosting a malicious webpage, a delivery server that token-gates download of a Windows implant, a C2 redirector, a C2 server/controller, an exfil redirector, and an exfil receiver. The top-level launch.sh orchestrates environment setup, IP aliasing, token generation, PKI generation, shellcode patching, and docker-compose startup. Core exploit path: exploit-server/exploit-contents/utils.js contains a browser exploit for CVE-2021-21220. During build, delivery-server/Dockerfile patches generated shellcode into utils.js. That shellcode comes from exploit-server/shellcode-generation/src/stager.asm and resolves WinExec from kernel32, then launches PowerShell to download a payload from https://HOST_IP:8443/update/DOWNLOAD_TOKEN, save it as C:\Users\Public\i.exe, and trigger execution with a fodhelper-based UAC bypass via HKCU\Software\Classes\ms-settings\shell\open\command. The downloaded payload is the Windows implant, renamed MicrosoftEdgeUpdate.exe. The implant/C2 implementation lives in c2-server/C2-Server-and-Implant/. The Linux-side controller (src/controller.c) listens for implants on port 443, supports enrollment-on-first-contact, maintains up to 8 sessions, provides an operator menu, runs remote commands, checks/creates persistence via schtasks, and handles spyware task acknowledgements. TLS logic in src/tls.c enforces TLS 1.3, supports initial enrollment without a client cert, signs implant CSRs using the CA key, and optionally checks a serial whitelist. Packet framing in src/protocol.c pads messages to 512-byte boundaries and drops keepalive packets transparently. The Windows implant (src/implant.c) is operational malware-style code, not just a detector. It decodes an obfuscated enrollment token, enrolls for a client certificate, reconnects over mTLS, and supports a separate HTTPS exfil channel using WinHTTP to POST data to /exfil/<hostname>/<filename> on port 9443. The code explicitly disables certificate validation for that exfil channel. It also includes keepalive traffic shaping and Windows-specific command execution helpers. Spyware functionality is implemented in src/spyware.c. Based on the visible code and documentation, capabilities include keylogging, clipboard capture, screenshots, browser credential theft (Edge/Chrome Local State + Login Data with DPAPI handling), browser history theft, camera snapshots, recursive sensitive-file search under C:\Users\, messaging data theft (Discord, Telegram, Signal), and arbitrary file exfiltration. Exfiltrated bulk data is not returned over the C2 channel; instead it is uploaded directly to exfil-receiver/server.js, which stores files under /opt/exfil (host-mounted as exfil-data/). Additional notable behavior: exploit-server/exploit-contents/server.js also acts as a phishing credential collector. It accepts POSTs to /login from the fake Weibo-themed page in index.html, logs the submitted credentials, and forwards them over HTTPS to the exfil receiver under /exfil/weibo-phish/<filename>. This means the repository combines browser exploitation, phishing, implant delivery, C2, persistence, and data theft. Overall assessment: this is a real exploit chain and post-exploitation framework for a controlled lab. It is not part of Metasploit/Nuclei/etc. Maturity is OPERATIONAL because it includes a working payload and infrastructure, but customization is largely driven by build-time variables rather than a reusable public framework.
This repository is a full offensive lab rather than a single standalone PoC. It chains a browser exploit for CVE-2021-21220 with staged payload delivery, a Windows implant, a mutual-TLS C2 server, redirectors, and a separate HTTPS exfiltration path. The structure is split across six Dockerized services: an exploit server on port 8888 serving a malicious webpage and patched utils.js, a delivery server on 8443 serving a token-gated implant binary, a C2 redirector on 443 forwarding raw TCP to the internal controller, an exfil redirector on 9443 forwarding HTTPS uploads to an internal receiver, plus the controller and exfil receiver themselves. The main exploit path is: victim visits http://<host>:8888 -> browser-side JavaScript exploit in exploit-server/exploit-contents/utils.js achieves code execution -> embedded shellcode from shellcode-generation/src/stager.asm launches PowerShell -> PowerShell downloads MicrosoftEdgeUpdate.exe from https://HOST_IP:8443/update/<DOWNLOAD_TOKEN> to C:\Users\Public\i.exe -> shellcode uses the HKCU ms-settings\shell\open\command fodhelper hijack for UAC bypass/elevation -> implant starts. The implant, implemented in C in src/implant.c with helpers in spyware.c, performs first-contact enrollment by generating an RSA keypair and CSR in memory, sending it to the controller over one-way TLS, receiving a signed certificate, then reconnecting over TLS 1.3 mutual TLS. The controller in src/controller.c accepts multiple implants, maintains sessions, provides an operator menu, supports arbitrary command execution, shutdown, and persistence management. The custom protocol in protocol.c pads packets to 512-byte boundaries and includes keepalive traffic shaping. Capabilities go beyond reverse shell behavior. The implant supports screenshot capture, keylogging, clipboard theft, browser credential theft, browser history theft, camera snapshots, recursive sensitive-file search, messaging-app data theft (Discord/Telegram/Signal), and arbitrary file exfiltration. Bulk data is not returned over the C2 channel; instead implant.c posts it directly to the exfil receiver over HTTPS at /exfil/<hostname>/<filename>. The exploit server also doubles as a phishing collector: index.html presents a fake Weibo login page and server.js forwards submitted credentials to the exfil infrastructure. Repository languages are primarily C, JavaScript, Bash, Python, HTML/CSS, assembly, and Docker/YAML. Key entry points are launch.sh for orchestration, controller.c for the server, implant.c for the Windows payload, exploit-server/exploit-contents/server.js for the exploit/phishing web server, delivery-server/token_server.js for authenticated payload delivery, and exfil-receiver/server.js for data collection. Overall, this is a real exploit chain and post-exploitation framework for a controlled lab environment, with operational payloads but largely hardcoded infrastructure and workflow.
Repository is a small JavaScript proof-of-concept/teaching exploit for CVE-2021-21220 in Google Chrome's V8 engine. It contains 5 files: a README presentation-style explanation, two JavaScript demos, one helper library, and a text artifact. The main exploit is `clean_demo.js`, which loads `clean_demo_helpers.js` and demonstrates a full browser-engine exploitation chain in the V8 `d8` shell. The exploit triggers a JIT optimization bug using `(b[0] ^ 0) + 1` with `0x80000000` in a `Uint32Array`, corrupts an array length to `-1`, uses fixed overlap indexes to extend neighboring array lengths, and builds `addrof`/`fakeobj` primitives from overlapped object/double arrays. It then creates a WebAssembly function, walks V8/Wasm metadata to derive a code pointer, redirects an `ArrayBuffer` backing store to executable Wasm memory, and patches native code through a `DataView`. The default payload is a minimal x86-64 stub that returns 2026 instead of 1337; an optional payload writes `demo_succeeded.txt` with `demo succeeded\n`, demonstrating native code execution. `clean_demo_helpers.js` provides conversion helpers, byte-dump utilities, and payload builders including the file-creation payload. `jit_value_mismatch_demo.js` is a smaller standalone demonstration that only shows the incorrect optimized arithmetic result after warmup and does not itself achieve memory corruption. Overall, this is a real exploit demonstration rather than a detector: it is educational but operational within a specifically vulnerable V8 build and relies on hardcoded heap-layout assumptions and offsets rather than a generalized framework.
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 contains a working exploit for CVE-2021-21220, a V8 type confusion vulnerability in Google Chrome. The structure includes: - 'exploit.js': The main exploit logic, which abuses a type confusion bug to achieve arbitrary read/write and ultimately execute shellcode in a RWX memory page via WebAssembly. The shellcode is provided as an array of 32-bit integers and is written to executable memory, then executed. - 'exploit.html': A simple HTML file that loads 'exploit.js'. - 'main.go': A Go-based HTTP server that serves the current directory, allowing the exploit to be delivered to a browser at 'http://localhost:3000/exploit.html'. - 'README.md': Brief documentation and reference links. The exploit is operational and demonstrates remote code execution in the browser context. The attack vector is browser-based, requiring a user to visit the malicious page. The exploit targets unpatched versions of Google Chrome on both Windows and Linux platforms.
This repository contains a single Metasploit module targeting CVE-2021-21220, a remote code execution vulnerability in the V8 JavaScript engine of Google Chrome prior to version 89.0.4389.128/90.0.4430.72. The exploit is delivered via a malicious web page served by the Metasploit HTTP server. When a vulnerable Chrome browser (running with the --no-sandbox flag) visits the page, the embedded JavaScript exploits the V8 bug to achieve arbitrary code execution by injecting shellcode into a WebAssembly RWX page and executing it. The module is operational and leverages Metasploit's payload system to deliver shellcode. The only fingerprintable endpoint is the root path (/) of the HTTP server started by the module, which serves the exploit page. The exploit targets Chrome on Linux, Windows 10, and macOS, and requires the browser to be run without sandboxing for successful exploitation.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
6 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A browser vulnerability where insufficient input validation leads to heap corruption/out-of-bounds write; the content states it was exploited in the wild.
A browser vulnerability in which insufficient input validation leads to heap corruption / out-of-bounds write; the content states it was exploited in the wild.
A Google Chrome vulnerability used during Pwn2Own and patched before the observed attacks; the article explicitly suggests it was likely not used in this campaign.
Browser input-validation flaw that allows heap corruption.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.