One day short of a full chain: Real world exploit chains explained

Bridging the gap between PoC and real-world attacks

Most security research ends at a proof of concept: code that triggers a vulnerability to show it exists, without the reliability needed for actual deployment against a target. That is a long way from the weaponized exploit chains seen in real-world intrusions. The difference matters not just for understanding attacker capability, but for measuring whether the mitigations baked into modern platforms actually hold up under pressure.

GitHub Security Lab set out to test that question by assembling a full exploit chain against Android. The work combines three vulnerabilities reported in Google and Qualcomm components, stitched together to go from a malicious webpage to kernel code execution. The chain was built in reverse, starting from the end goal—kernel compromise—and working backward to the entry point in Chrome. All three bugs were reported in 2020; two were caught before leaving Chrome Beta, and all have since been patched.

Fence-hopping: why a single bug is rarely enough

Modern browsers lean on sandboxing to contain a compromised renderer, keeping an attacker locked inside a restricted process. Getting from a browser bug to privileged system access means defeating that containment, then chaining further exploits against the OS itself. Each hop is a separate vulnerability, often paired with its own mitigation bypass. The assembled sequence is what researchers call a full exploit chain.

For this project, the chain had three links. The entry point is a renderer exploit triggered by a malicious website. That yields code execution inside the sandboxed Chrome renderer. From there, a second vulnerability breaks out of the Chrome sandbox, giving the attacker the privileges of an Android app. Finally, a third flaw in a Qualcomm kernel driver is exploited to elevate to kernel code execution. A visit to a compromised page is all that would be needed to complete the scenario on affected devices.

From kernel back to entry point

The endpoint of the chain is kernel code execution via a use-after-free in the Qualcomm Kernel Graphics Support Layer (KGSL). Tracked as GHSL-2020-375 (CVE-2020-11239), the flaw affects Android devices built on Qualcomm chipsets, including the Google Pixel 4, Samsung A71, and Samsung S20. UAF bugs let an attacker influence the contents of freed memory objects, then feed attacker-controlled data back into system code that interacts with those objects. For this flaw, that was enough to escalate from the context of an Android app to full kernel privileges.

Working backward from that goal, the next link is a Chrome sandbox escape in the browser's payment processing code. Reported as GHSL-2020-165 (CVE-2020-16045), it was found in the Beta channel of Chrome. The memory management bug allowed an attacker who already had code execution inside the renderer to elevate to app-level privileges—the context needed to reach the Qualcomm KGSL driver.

The final piece sits at the start of the chain, where a victim first lands on a malicious page. GHSL-2020-167 (CVE-2020-15972) is another UAF, this time in Chrome's WebAudio handling code. Exploiting it achieves arbitrary code execution in the sandboxed renderer process, kicking off the sequence.

What the exercise actually demonstrates

Beyond the technical detail, the chain is a reality check on how exploit development is often characterized. Sophisticated chains tend to be attributed to state-sponsored groups with deep resources. This one was built by a single researcher at GitHub Security Lab, working from open research material and without unusual tooling or funding.

That has a practical consequence for defenders. Seeing how modern mitigations are bypassed in practice—rather than in theory—exposes gaps in current protections and points toward concrete improvements. Demonstrating these attacks is also a way to calibrate expectations: advanced exploitation is not magic, and the gap between a proof of concept and a deployed chain is narrower than it might appear. Each stage of this research is documented separately, providing the full technical breakdown for researchers who want to study the details. Updates to affected Android devices patch all three flaws, and the timeline gave users ample opportunity to install those fixes.