What’s Control-flow hijacking (binary exploitation)?
A control-flow hijack is when an attacker gets a running program to execute code it was never meant to run — classically by overflowing a buffer, overwriting a return address or function pointer, and redirecting execution to attacker-chosen code. It's the mechanism behind most of the highest-severity 'remote code execution' vulnerabilities you see in CVE reports.
Historically this required a human exploit developer: find the memory-safety bug, understand the binary's layout, hand-craft a payload that survives the program's defenses (stack canaries, ASLR, etc.), and chain several small bugs into one working exploit. It's slow, skilled work — one reason offensive cyber capability has stayed a scarce, credentialed resource.
What changed here is that models are now completing that whole chain — find the bug, build the payload, redirect execution — end to end and autonomously, in a real fraction of trials, where the prior model generation managed none. The jump from 0% to single-digit percentages sounds small until you remember it's the difference between 'not yet possible' and 'possible, and about to get cheaper.'
The live debate is whether this cuts both ways: the same automation that lets an attacker chain an exploit also lets defenders find and patch the bug first. Which side benefits faster is exactly the kind of question frontier labs' red-team disclosures like this one are meant to inform — and exactly the kind of claim that's hard to verify from outside the lab.