The report
On October 14, researchers presented P2Patch, a vulnerability-repair workflow in which a proposed fix is deliberately attacked again after it blocks the exploit that motivated it. The experiment asks a more demanding question than whether the original proof of vulnerability stopped running: does a different input still cross the same security boundary?
The system alternates an exploitation agent and a repair agent. A separate execution controller checks whether the candidate exploit works, and every confirmed bypass becomes a persistent repair requirement. Construction-time proofs are excluded from the held-out suites used to evaluate the final patch. In 101 C/C++ and Java vulnerability subjects, the researchers reported new execution-confirmed bypasses in 41% of repair runs after the first proof had been blocked. The authors qualify the distinctness of those bypasses because semantic independence was not separately adjudicated. The finding is evidence of residual testable paths, not a claim that 41% of deployed security patches are exploitable.
On the held-out fix-closed oracle, coverage improved from 78.1% for single-pass Claude Code repair to 84.7% for P2Patch. The separate beyond-upstream metric moved from 42.1% to 62.5%, measuring paths beyond those blocked by the upstream fix. These measures should not be added or treated as the proportion of production vulnerabilities eliminated. The underlying research Case preserves the test design and uncertainties.
The operational implication is narrow but important. A disappearing error, a passing scanner, or a repaired original proof is only one observation. A defensible patch review also tests alternative inputs, retains regression cases, checks ordinary functionality, and uses an independent execution oracle. None of these finite tests certifies the absence of all future bypasses.