23 Chrome Exploit PoCs on an Open AWS Server: Inside an Active CVE-2026-4440 Exploit Development Toolkit

When @1ZRR4H flagged an open directory on an AWS EC2 instance, we found a complete Chrome/Android exploit development toolkit — 23 files served from a bare Python SimpleHTTPServer, targeting CVE-2026-4440 and at least five additional WebGL/ANGLE vulnerabilities across a multi-stage exploit chain designed to compromise Pixel devices through Chrome's GPU process.

The server hosts active exploit development: iterative PoC refinement, device-specific heap shaping, TOCTOU race exploitation, and sandbox escape research — hosted on an open directory with no access controls.

We recovered all 23 files, hashed them, and analyzed the complete exploit chain. Here is everything we found.

---

Discovery and Infrastructure

On April 13, 2026, threat intelligence researcher Germán Fernández (@1ZRR4H, CronUp/CuratedIntel) identified an open directory at 100.48.195[.]190:80. The IP resolves to an AWS EC2 instance in the us-east-1 region.

The server was running Python's built-in SimpleHTTPServer — the kind of quick-and-dirty file serving you use during development when you don't care who sees your work. Navigating to the root displayed a standard directory listing with 23 files: 19 HTML exploit PoCs, 3 Python collection/exfiltration servers, and 1 index page cataloging the toolkit.

Server Profile:

• IP: 100.48.195[.]190 (AWS EC2, us-east-1)
• Service: Python SimpleHTTPServer on port 80
• Authentication: None
• TLS: None
• Total Files: 23 (19 HTML, 3 Python, 1 index)
• Total Size: ~240 KB of exploit code

The operator made no attempt to restrict access — no .htaccess, no IP allowlisting, no authentication layer. The index page even includes a structured table describing each file's purpose, target vulnerability, and development status. This is a working exploit lab that was never meant to be public-facing, but was left exposed on AWS infrastructure.

---

The Exploit Chain Architecture

The recovered files reveal a methodical, multi-stage exploit chain targeting Chrome's rendering and GPU pipelines on Android. The developer is building toward a complete Chrome compromise: arbitrary read/write in the renderer, GPU process code execution, and sandbox escape. The chain breaks down into six attack surfaces.

Stage 1: PassAsSpan Use-After-Free — Renderer R/W Primitive

The foundation of the chain is a use-after-free in Chrome's PassAsSpan implementation. The file stage1_combined_demo.html (21 KB) implements a combined demonstration of the renderer-level read/write primitive and ASLR bypass.

The exploit allocates a Uint8Array backed by a SharedArrayBuffer, triggers a UAF through a carefully timed span invalidation, and reclaims the freed memory with a controlled object. The result is a corrupted ArrayBuffer with an attacker-controlled backing store pointer — the classic renderer RCE primitive that converts a memory corruption into arbitrary read/write within the renderer process.

This is the prerequisite for everything that follows. Without a renderer R/W primitive, the GPU process bugs are just crashes. With it, they become a path to code execution outside the sandbox.

Stage 2: CVE-2026-4440 — GPU Process Integer Overflow

The centerpiece of the toolkit. CVE-2026-4440 is an integer overflow in Chrome's GPU process triggered through WebGL texture handling. The developer has written four separate PoC files targeting this single vulnerability, each exploring a different trigger path:

• cve_2026_4440_poc.html (17 KB) — The primary proof-of-concept. Triggers the integer overflow through oversized texture dimensions that overflow the size calculation in the GPU process's texture allocation path. The PoC creates a WebGL context, allocates a texture with dimensions designed to cause an integer wrap during width * height * bytes_per_pixel computation, and monitors for GPU process behavior indicating successful overflow.

• cve_2026_4440_targeted_poc.html (10.7 KB) — A refined version targeting specific Adreno GPU driver versions. The code includes conditional paths for Adreno 540 (Pixel 2) and Adreno 640 (Pixel 4), adjusting texture parameters based on the GPU's maximum texture size and memory alignment requirements.

• cve_2026_4440_comparison_poc.html (6.8 KB) — A diagnostic harness that runs the trigger with varying parameters and compares GPU process behavior across iterations. This is the kind of file you write when you're trying to find the exact boundary condition that separates a clean crash from a controlled overflow.

• cve_4440_cubemap_and_compressed.html (14.7 KB) — Explores triggering the overflow through cubemap textures and compressed texture formats (ETC2, ASTC). Compressed formats have different size calculations than uncompressed RGBA, and cubemaps multiply the allocation by 6 faces — both additional multiplication points that may overflow differently.

Two additional CVE-2026-4440 files push the exploitation further:

• cve_4440_65layer_heap_overflow.html (12 KB) — Attempts to convert the integer overflow into a heap overflow by allocating a 65-layer texture array. The 65th layer overflows the allocation size, causing subsequent texture data writes to corrupt adjacent heap objects in the GPU process.

• cve_4440_format_conversion.html (9 KB) — Targets the format conversion path. When the GPU process converts between texture formats (e.g., RGBA to RGB), it allocates a temporary buffer sized by the overflowed calculation. The conversion write then exceeds the buffer, providing a write primitive in the GPU process heap.

The iterative refinement across six files demonstrates a developer who is methodically probing every trigger path for the same underlying vulnerability. This is professional exploit development.

Stage 3: MapBufferRange TOCTOU Race — FencedAllocator UAF

Three files target a time-of-check-time-of-use (TOCTOU) race condition in the MapBufferRange implementation within Chrome's ANGLE layer:

• poc_mapbufferrange_toctou.html (31 KB) — The largest file in the toolkit. Implements a multi-threaded race using SharedArrayBuffer and Atomics to exploit a TOCTOU window in ANGLE's FencedAllocator. The attack maps a buffer range, races a free operation against a use operation on the fenced allocation, and attempts to trigger a use-after-free in the allocator's internal state.

• poc_mapbufferrange_overlap_exploit.html (26 KB) — Exploits overlapping buffer mappings to create aliased memory regions. If two MapBufferRange calls can be made to return overlapping views of GPU memory, the attacker gets a write-after-free primitive when one mapping is unmapped while the other remains valid.

• poc_mapbufferrange_crash_test.html (5 KB) — A minimal crash test that rapidly maps and unmaps buffer ranges to confirm the race window exists before deploying the full exploit.

The TOCTOU approach is notable because race conditions in GPU process code are extremely difficult to exploit reliably — the timing window depends on GPU driver scheduling, which varies by device and load. The 31 KB size of the primary PoC suggests the developer has invested significant effort in heap grooming and timing stabilization.

Stage 4: Index Buffer Out-of-Bounds — ANGLE Vulkan Backend

Two files target an out-of-bounds read/write through index buffer handling in ANGLE's Vulkan backend:

• poc_index_buffer_oob.html (16 KB) — Creates an index buffer with out-of-bounds indices that reference memory beyond the vertex buffer allocation. On the Vulkan backend, ANGLE's bounds checking has a different code path than the OpenGL ES backend, and this PoC probes for indices that pass validation but trigger OOB access during draw calls.

• index_buffer_oob_pixel2.html (12.3 KB) — A Pixel 2-specific variant tuned for the Adreno 540's Vulkan driver. The Pixel 2's older driver version may have weaker bounds checking than newer Adreno parts, making it a softer target for index buffer OOB exploitation.

Stage 5: VP9 Partition Isolation Bypass Research

• poc_vpx_bucket_gaps.html (8.3 KB) — Investigates whether VP9 video decoding in Chrome's GPU process can be used to bypass partition isolation. The PoC creates VP9 frames with carefully crafted partition boundaries and monitors for memory access patterns that indicate cross-partition reads. This appears to be early-stage research rather than a working exploit.

Stage 6: JSPI/WebAssembly Sandbox Escape Feasibility

Three files probe Chrome's JavaScript Promise Integration (JSPI) and WebAssembly stack switching implementation:

• jspi_probe.html (8.6 KB) — Enumerates JSPI support and WebAssembly stack switching behavior. Tests whether stack switching creates exploitable state in the renderer's stack guard pages.

• jspi_functional_test.html (8.4 KB) — Tests JSPI promise resolution across different stack states. If stack switching can be triggered during a promise resolution that also involves a GPU process call, the combined state may create a sandbox escape path.

• jspi_test_v2.html (6.6 KB) — Refined version with additional stack exhaustion testing.

This is the speculative end of the chain. JSPI is a relatively new Chrome feature, and the developer appears to be assessing whether it provides a viable sandbox escape vector. The files are smaller and less refined than the GPU exploit code, suggesting this is exploratory research.

---

Device Targeting and GPU Probing

Two files are dedicated to fingerprinting and diagnostics:

• gpu_limits_probe.html (6.5 KB) — Queries every WebGL extension, maximum texture size, maximum renderbuffer size, maximum viewport dimensions, and compressed texture format support. The results feed directly into the CVE-2026-4440 PoCs, which use these limits to calculate overflow-triggering dimensions.

• gpu_info.html (3 KB) — A lightweight GPU fingerprinting page that extracts the WEBGL_debug_renderer_info extension to identify the exact GPU model and driver version.

• pixel4_crash_diagnostic.html (5 KB) — A crash diagnostic page specifically for the Pixel 4 (Adreno 640). Monitors Chrome's GPU process crash behavior and extracts crash metadata to distinguish between exploitable crashes (controlled corruption) and non-exploitable crashes (null derefs, assertion failures).

The explicit targeting of Pixel 2 (Adreno 540) and Pixel 4 (Adreno 640) — combined with code references to AWS Device Farm — suggests the developer is using AWS's cloud-hosted device testing infrastructure to remotely test exploits against real Pixel hardware. This is a professional workflow: write PoC locally, deploy to SimpleHTTPServer, point Device Farm browser sessions at the server, collect crash results.

---

Collection Infrastructure

Three Python scripts handle result collection from exploit runs:

• result_server.py (2.3 KB) — A Flask or BaseHTTPServer-based collection endpoint. PoC files send exploit results (crash data, memory leak values, GPU info) to this server via fetch() POST requests. Results are logged with timestamps and device identifiers.

• server.py (2 KB) — The primary SimpleHTTPServer script serving the open directory. Minimal configuration — exists solely to serve the PoC files over HTTP.

• server_threaded.py (2.1 KB) — A threaded variant of the server, likely created to handle concurrent Device Farm sessions hitting the server simultaneously. The standard SimpleHTTPServer is single-threaded and will queue requests, which interferes with timing-sensitive TOCTOU exploits.

---

Attribution Assessment

The evidence points to a professional exploit developer — likely an offensive security researcher, government contractor, or exploit broker:

1. Methodical iteration: Six files for a single CVE, each exploring a different trigger path. This is not a hobbyist; this is someone being paid to find the most reliable trigger.

2. Device-specific tuning: Code paths branching on Adreno GPU model, with Pixel 2 and Pixel 4 specific variants. The developer has access to (or is renting) real hardware.

3. AWS Device Farm references: Using cloud-hosted device farms for remote exploit testing is an established workflow in the exploit brokerage industry.

4. No obfuscation: The code is clean, well-commented, and uses descriptive variable names. This is development code, not deployment code. The developer hasn't reached the weaponization phase where code gets packed and obfuscated.

5. Multi-stage chain architecture: Building from renderer R/W → GPU process exploitation → sandbox escape research. This is the structure of a commercial exploit chain.

6. OPSEC failure: Running a dev server on a public EC2 instance with no authentication. This is consistent with a developer who is focused on the technical work and treating AWS as a disposable lab environment — common in the exploit development community where infrastructure is burned regularly.

We assess with moderate-high confidence that this represents active exploit development targeting Chrome on Android, likely for sale or government use. The toolkit is not yet weaponized — the sandbox escape research is still exploratory — but the renderer and GPU process exploits appear close to functional.

---

CVE-2026-4440 Status

CVE-2026-4440 was assigned to a Chrome GPU process integer overflow affecting texture size calculations in the WebGL implementation. At the time of our investigation (April 13, 2026), the vulnerability had been reported to Chrome's security team but no patch had been released in the Chrome stable channel.

Organizations running Chrome on Android — particularly on Qualcomm Adreno GPU devices — should monitor the Chrome release notes for a patch addressing this CVE and apply updates immediately upon availability. Until patched, the WebGL attack surface can be reduced by disabling WebGL in Chrome flags (chrome://flags/#enable-webgl) on sensitive devices, though this will break many legitimate web applications.

---

MITRE ATT&CK Mapping

Tactic	Technique	ID	Description
Resource Development	Acquire Infrastructure	T1583.003	AWS EC2 instance for exploit hosting and testing
Resource Development	Develop Capabilities: Exploits	T1587.004	Active CVE-2026-4440 and multi-vuln exploit chain development
Resource Development	Stage Capabilities	T1608.004	PoC files staged on open HTTP server for Device Farm delivery
Initial Access	Drive-by Compromise	T1189	HTML PoC files designed for browser-based delivery
Execution	Exploitation for Client Execution	T1203	WebGL/ANGLE exploitation for renderer and GPU process code execution
Defense Evasion	Exploitation for Defense Evasion	T1211	Sandbox escape research via JSPI/WebAssembly stack switching
Discovery	System Information Discovery	T1082	GPU fingerprinting via WebGL extensions and debug info
Collection	Data from Local System	T1005	result_server.py collecting crash data and memory leak values from target devices

---

YARA Rule

rule CVE_2026_4440_PoC_Toolkit {
    meta:
        description = "Detects HTML PoC files from the CVE-2026-4440 Chrome/Android exploit development toolkit"
        author = "Breakglass Intelligence"
        date = "2026-04-16"
        reference = "https://intel.breakglass.tech/blog/cve-2026-4440-chrome-exploit-dev-server-open-directory"
        tlp = "WHITE"

    strings:
        $cve_ref = "CVE-2026-4440" ascii wide
        $teximage = "texImage2D" ascii
        $teximage3d = "texImage3D" ascii
        $cubemap = "TEXTURE_CUBE_MAP" ascii
        $mapbuffer = "MapBufferRange" ascii
        $fenced = "FencedAllocator" ascii
        $passasspan = "PassAsSpan" ascii
        $adreno540 = "Adreno 540" ascii wide
        $adreno640 = "Adreno 640" ascii wide
        $device_farm = "Device Farm" ascii wide
        $overflow1 = "integer overflow" ascii nocase
        $overflow2 = "heap overflow" ascii nocase
        $webgl_ctx = "getContext('webgl" ascii
        $result_post = /fetch\(['"]https?:\/\/[^'"]+result/ ascii

    condition:
        filesize < 100KB and (
            ($cve_ref and any of ($teximage, $teximage3d, $cubemap)) or
            ($mapbuffer and $fenced) or
            ($passasspan and $overflow1) or
            (any of ($adreno540, $adreno640) and any of ($overflow1, $overflow2)) or
            ($cve_ref and $result_post) or
            (3 of ($cve_ref, $webgl_ctx, $overflow1, $overflow2, $device_farm))
        )
}

---

Indicators of Compromise

Network Indicators

Type	Value	Context
IPv4	100.48.195[.]190	Exploit development server (AWS EC2, us-east-1)
URL	http://100.48.195[.]190/	Open directory root
URL	http://100.48.195[.]190/cve_2026_4440_poc.html	Primary CVE-2026-4440 PoC
URL	http://100.48.195[.]190/stage1_combined_demo.html	Combined Stage 1 renderer exploit
Service	Python SimpleHTTPServer	Port 80, no authentication

File Hashes (SHA256)

File	SHA256	Size	Purpose
cve_2026_4440_poc.html	fed824ecf9b2723df754ddc530a5fec5fc1f52259f1ff1b95e46338fda495e5e	17 KB	Primary CVE-2026-4440 PoC
cve_2026_4440_targeted_poc.html	afe0a661a82bad8bfacd4b4fdbb0c38112b4116993a29f812d2d83bd54d7dd45	10.7 KB	Adreno-targeted PoC
cve_2026_4440_comparison_poc.html	021c7f6dd0655c1611bcb59f5d0894b13484bd1338f3bcee1a6a4d76c1d02e0c	6.8 KB	Comparison/diagnostic PoC
cve_4440_cubemap_and_compressed.html	692f2629a33de1f7fa973cb5c83aa8835f3ac8bb396d4b6ee0cf2cadc980868a	14.7 KB	Cubemap/compressed format trigger
cve_4440_65layer_heap_overflow.html	2887693584bab11e22383825402602b35f7b5a3fa114f3c5e81d887b8cae07e2	12 KB	65-layer heap overflow
cve_4440_format_conversion.html	cc8d7d58a5cc4d410ea6b680c23d8754b3029be464f74d9444ac56501dc2c21e	9 KB	Format conversion trigger
poc_mapbufferrange_toctou.html	8e2475d293e307b97e7fcf34845d7f6047141b8795d4d912d2bd78b988861e35	31 KB	TOCTOU race exploit
poc_mapbufferrange_overlap_exploit.html	019245f443fe1b68926dad658fbf98fca6918ae33c21446209a488b4d08af713	26 KB	Overlapping buffer mapping exploit
stage1_combined_demo.html	ff9ca959412b086ec3c8def9e9dac24208cbde70c7042e9feea03a1c92999a7a	21 KB	Combined renderer R/W + ASLR bypass
poc_index_buffer_oob.html	93cb956290ea727b58be3d134872830c4f90b0f3747bd036bd05c1fdac3ef8ff	16 KB	Index buffer OOB (ANGLE Vulkan)
jspi_probe.html	452d4f3b4f3ce2abda1825088a77383316319f9f0c3a43c55be5f34ef88b8463	8.6 KB	JSPI/WebAssembly probe
jspi_functional_test.html	016b89b322f35fda0381db9febe63d71b44aa0ce555d0fc5eaaf79f9e0f1b64d	8.4 KB	JSPI functional test
jspi_test_v2.html	a41ab944ec53b4655632ea79b1b6bda313f4436bcfe953178f7995916d48635a	6.6 KB	JSPI test v2
gpu_limits_probe.html	2e05f417726c4aafb61a88dede3156e33ac62c7b944342272336323c60179e59	6.5 KB	GPU limits enumeration
gpu_info.html	75a4de9e9bfad99d94c3d7c31a0a81f91c57261f9af7a2cee907e37a8f7f49b2	3 KB	GPU fingerprinting
pixel4_crash_diagnostic.html	4c6d562a68d10242d158b8a1a1a0d9dd951eccf0f48b103cbe6210e2ddafe0f1	5 KB	Pixel 4 crash diagnostics
poc_mapbufferrange_crash_test.html	90567738e21b85be8365fce026a81d00109e802345bcdc0556c471efeb0d8753	5 KB	MapBufferRange crash test
poc_vpx_bucket_gaps.html	f90cd96834d8dac0183ee569e396ca0e9b56f8248a74bd00aa62a010c04bfa00	8.3 KB	VP9 partition isolation probe
index_buffer_oob_pixel2.html	2c0def09409b4ce4767935a8dcaa25e44d3b9769aca5b74ffa29026de7dc283b	12.3 KB	Index buffer OOB (Pixel 2)
result_server.py	586e6c9d916115aaed65215cd37e20254d17c7ae8d7fd9b3d8317e628936995f	2.3 KB	Exploit result collection server
server.py	85bfcc2ed51c56b4e7beba47edbe257f518b0373f7437a8c6bab319fc889c951	2 KB	HTTP file server
server_threaded.py	d1392d08d6575bfae23b7e886724c1903c8266c46a1a113ba2608a15d095302a	2.1 KB	Threaded HTTP server
index.html	1c5c902c35fb100c35116bc7954397265a653b7041c9651ce2655c2fe1b90a60	1.9 KB	Directory index page

---

Recommendations

1. Monitor for CVE-2026-4440 patch: Track Chrome release notes and apply updates immediately when a fix ships. This vulnerability affects the GPU process texture handling path and is actively being exploited in development.

2. Disable WebGL on sensitive devices: On high-value Android devices, disable WebGL via chrome://flags/#enable-webgl until CVE-2026-4440 is patched. This eliminates the primary attack surface.

3. Block the IOC IP: Add 100.48.195[.]190 to network blocklists. While the server may be ephemeral AWS infrastructure, blocking it prevents any active exploit delivery from this endpoint.

4. Deploy the YARA rule: Use the provided YARA rule to scan web proxy logs and endpoint caches for PoC file delivery. The rule targets the specific code patterns and string combinations found in this toolkit.

5. Review AWS Device Farm usage: Organizations using AWS Device Farm should audit their device sessions for connections to unexpected HTTP servers. The exploit developer's workflow involves pointing Device Farm browser sessions at the exploit server.

6. Hunt for related infrastructure: The developer may have additional servers. Search for Python SimpleHTTPServer instances on AWS EC2 (us-east-1) serving HTML files with WebGL exploit patterns.

---

Conclusion

This investigation exposed an active, professional-grade Chrome/Android exploit development operation. The developer has built a multi-stage exploit chain targeting at least six distinct vulnerability classes — from renderer-level use-after-free primitives through GPU process integer overflows, TOCTOU races, and out-of-bounds access, all the way to sandbox escape research through JSPI/WebAssembly.

The quality of the code, the iterative refinement across multiple PoC variants, the device-specific targeting of Qualcomm Adreno GPUs, and the use of AWS Device Farm for remote testing all point to a well-resourced actor — most likely an exploit broker or government offensive capability developer.

The toolkit is not yet fully weaponized. The sandbox escape research (JSPI/WebAssembly) is still exploratory, and there is no evidence of a completed end-to-end chain from initial browser compromise to code execution outside the Chrome sandbox. But the renderer and GPU process components appear close to functional, and the developer is clearly working toward a complete chain.

Credit to @1ZRR4H (Germán Fernández, CronUp/CuratedIntel) for the initial tip that led to this discovery.

---

Breakglass Intelligence provides offensive threat research, vulnerability analysis, and adversary infrastructure mapping for organizations that need to understand the threats targeting their stack. If you need help assessing your exposure to Chrome/WebGL exploitation or want a threat briefing on exploit development trends, contact us at consulting.breakglass.tech.