V8 Type Confusion in Google Chrome

The supplied repository contains one README and five standalone JavaScript files under poc/, totaling 2,763 bytes of listed file content. No framework, dependencies, build configuration, network communication, persistence, or command-execution payload is present. The repository URL, actual checkout reference, and archive size were not supplied; repo.size_bytes is therefore recorded as 0 to represent unavailable archive metadata. The common trigger calls Array.prototype.sort with a comparator that executes arr.fill(0). Repeated calls on numeric and object arrays warm up the function. The README alleges that Maglev/TurboFan sort inlining restores an object-containing snapshot after fill has narrowed the array's elements kind to SMI, leaving object references interpreted as small integers. This would expose internal pointer representations through ordinary JavaScript conversions. poc/min.js is the minimal reproducer: it confuses a two-object array and prints its string representation. poc/addrof.js wraps the trigger in addrof(target), parses the first stringified element as a number, and uses bitwise operations to reconstruct an alleged tagged object address. Those operations coerce the result to a signed 32-bit integer, so the output should not be assumed to be a full native address. poc/addrof_check.js adds %DebugPrint to permit comparison against V8's diagnostic object output. poc/exp2_stage.js explores a possible garbage-collection consequence. It allocates temporary arrays to encourage collection and promotion, inserts a new object into an existing array, triggers the confusion, and calls unshift(0). Its comments suggest that moving pointers under SMI semantics could omit write barriers. This is an investigative stage, not a completed use-after-free or arbitrary-memory-access exploit; the script does not guarantee promotion or demonstrate successful exploitation of a missing barrier. poc/regress.js explicitly requests Maglev optimization and asserts that the array does not simultaneously retain SMI elements and expose the original object at index zero. It is a regression test rather than an exploitation payload, and its final message alone is not proof of vulnerability status. The supplied code supports classifying the repository as a type-confusion/address-disclosure proof of concept. Successful reproduction, the stated CVE association, the claimed fix relationship, and the README's assertion of in-the-wild use by a named kit cannot be independently established from these files. No fingerprintable endpoint is contacted by the exploit code; the only external URL is a documentation reference.

This is a standalone eight-file Chrome exploit chain and Linux validation harness, not a framework module. stage1.js implements the CVE-2026-85046 V8 Float64Array corruption primitive, producing cage-relative 32-bit read/write and object-address primitives. poc.js builds custom WebAssembly modules, abuses exception handling/forged getters to extend the primitive, discovers renderer code aliases, and writes embedded x86-64 code that changes memory protections and patches memcpy GOT entries, reporting FULL_RW on success. retarget-loader.js dynamically fetches and instruments poc.js, then creates a sandboxed iframe targeting /STAGE2_C. After renderer-stage completion it enables a user-facing button. retarget-receiver.js receives the iframe message and assigns its source window to a mailto URI, attempting to carry/misattribute the user activation and invoke Evolution externally. run.py serves the stages on an ephemeral localhost port, launches specific vulnerable/fixed Chrome artifact versions via Selenium, monitors /proc and process activity for xdg-open/Evolution, and compares vulnerable versus fixed behavior. The payload is operational but heavily version-specific and uses hard-coded layout assumptions, addresses, native code, and external-handler expectations.

This three-file browser exploit repository contains a README, an HTML launcher, and a 5 KB JavaScript PoC. run.html loads an external CVE-2026-85046 exploit bootstrap followed by poc.js; the bootstrap is not included in this repository, so the provided PoC is a second-stage/chained exploit rather than a standalone reproduction. poc.js programmatically constructs two WebAssembly modules and relies on the external primitive for heap-address and V8-cage memory manipulation. The chain creates WebAssembly instances sharing an imported function table and tag, forges an exception-related getter by copying a private exception key, and repeatedly invokes a driver function to encourage optimization. The getter changes a table entry while optimized code assumes no relevant side effects. This preserves instance A's stale implicit metadata while dispatching to instance D. Instance D uses memory index 6, which the exploit asserts aliases instance A's executable Wasm jump-table/code region. The resulting arbitrary read/write wrappers (arwRead/arwWrite) alter compiled Wasm instructions. main() patches a compiled Wasm body to execute getpid, adjusts a displacement, and then runPayload() overwrites the same body with hard-coded Linux x86-64 code that performs write(1, "PWNED 2026\\n", 11). Success is shown in the page and console as RAW_NATIVE data. The README identifies CVE-2026-85046 and CVE-2026-87491 and claims the target is Chrome 152.0.7977.75. No remote network service, C2 host, IP address, or HTTP API is contacted by the exploit; execution is entirely local to a victim browser renderer.

This three-file browser proof-of-concept repository contains a README, the main exploit logic in poc.js, and a minimal run.html loader. It targets an alleged Chrome 152.0.7977.75 JavaScript-engine vulnerability tracked as CVE-2026-85046. The JavaScript warms up helper functions, then abuses Array.prototype.sort() with a comparator that mutates its input array. The intended primitive leaks a WebAssembly.Module wrapper pointer as an integer, stores that value in an array slot not tracked as an object reference, and permits the original cloned module wrapper to be reclaimed by major/minor garbage collection. The script allocates cloned replacement modules and checks whether one is reallocated at the exact leaked stale address. If so, holder[100] is treated as the replacement module and instantiated, despite originating from a stale pointer. The replacement WebAssembly payload imports env.print, logs a success string, and returns 0x2222. No remote network destinations, IP addresses, domains, registry keys, or external services are embedded; execution is entirely local in the browser context. This is a PoC rather than a weaponized exploit: it depends on an exact browser build, exposed GC, allocation/GC timing, and only demonstrates replacement-module execution and a JavaScript callback.

The repository contains one standalone HTML proof of concept, poc.html, with embedded JavaScript and a small user interface to launch the exploit and display diagnostic output. It targets a claimed V8 Maglev type-confusion condition in the Array.prototype.sort inlining path (TryReduceArrayPrototypeSort). The exploit trains optimized code using mixed PACKED_SMI and PACKED element kinds, uses a sort comparator to cause a receiver-map migration, and abuses insufficient post-sort map validation. It then derives addrof and fakeobj primitives, uses an unbarriered old-to-young reference plus minor-GC/spray reclamation to place a fake JSArray, and creates master/victim aliases for arbitrary reads and writes. Constants for V8 JSArray maps and the empty fixed array are hardcoded for Chromium 150.0.7871.181 on Debian Linux x64. The HTML detects the browser version from navigator.userAgent and may be triggered manually through a button or through its documented local auto-run mode. There are no exploit-network requests or callback endpoints; the four embedded HTTPS URLs are documentation/advisory links only. The implementation is an operational, build-specific browser memory-corruption PoC that demonstrates in-sandbox memory access, not a complete RCE chain.