A use-after-free vulnerability exists in the WebRTC component of Google Chrome prior to version 89.0.4389.90. The flaw allows a remote attacker to trigger heap corruption by enticing a user to visit a specially crafted HTML page, leading to use of memory after it has been freed.
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.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
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.
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.
No public activity tracked yet. Mallory keeps watching.
No public activity observed for this vulnerability.
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.