Every post in this arc so far has been about a reviewer flagging a concern. This one is about a reviewer proving one. A device-certificate authority service, the component that decides which devices get to hold a valid identity certificate, and takes that identity away when a device is lost or offboarded, went through two independent adversarial review rounds before its second milestone shipped. Both reviewers had real build, Docker, and OpenSSL access, and were explicitly told to generate real certificate requests and sign them rather than review the code statically. They found two vulnerability classes that static reading alone would very plausibly have missed, and both were confirmed the only way that actually settles the question: by running the exploit against the live service.
What a revocation bypass looks like when it’s real, not hypothetical
The service’s enrollment path never checked a device’s current status before issuing it a fresh certificate. Replaying an already-processed enrollment request against a device that had just been revoked (marked offboarded or lost) minted that device a brand-new, fully valid certificate anyway. Both independent reviewers reproduced this live, separately, without coordinating with each other. It directly contradicted the service’s own design commitment: that urgent revocation takes effect in minutes, not days. As shipped, revocation didn’t take effect at all, if the revoked device’s owner still had a copy of the original enrollment request to replay.
The fix rejects replay against any mapping that isn’t in a fresh, unenrolled state. The verification that mattered was not reading the fix’s diff and agreeing it looked right. It was revoking a real device, confirming its status flipped to revoked, then attempting the exact replay exploit again and confirming it now failed with the correct rejection, and confirming the status stayed revoked afterward, not silently reset by the attempted replay.
A certificate that claimed to be someone else
The second finding: the certificate authority signed whatever identity a device’s certificate request asked for, verbatim, in one specific field, while the service’s own published API documentation explicitly claimed a device could not self-assert its identity through that field, “any more than it could through any other field.” That claim was false as shipped. Only one identity field was actually being overwritten with the service-derived, authoritative identity; a second field passed through completely unmodified, so a request crafted with an arbitrary identity string in that field would get it signed into a certificate that looked authoritative.
Confirming the fix meant doing exactly what an attacker would do: constructing a certificate request that asked for an attacker-chosen identity, submitting it, and inspecting the certificate that came back to confirm its actual identity field held the service-derived value, not the requested one. Read-only verification of the fixed code path was explicitly not treated as sufficient; the check was run against the live, running service.
A third bug the exploit-hunting turned up along the way
The same review pass, still driving the live service rather than reading it, surfaced a genuine data-integrity bug in how the service tracks device rotation: the forward and backward links recording which device replaced which. The original design had preconditions on the two link directions that were mutually impossible to satisfy in any call order, and worse, the code as shipped would silently accept a mismatched link between two unrelated devices, letting the two trails disagree about the rotation history. One reviewer proved this live too: enrolling a device that claimed a predecessor whose actual successor was a different device, and watching the mismatched claim get accepted without complaint. That directly undermined the one property device rotation tracking exists to provide: a resolver being able to reconstruct, later, an honest history of which device replaced which.
Verification, done independently of the agent that fixed it
The person closing out the milestone did not accept the fixing agent’s own report as sufficient, stated explicitly because the automated safety check that would normally have reviewed the fixing agent’s work had timed out and was unavailable that session. Instead: the full test suite was re-run independently. The actual fix code for the two most severe findings was read directly rather than trusting the summary of it. And then the running service was driven through both exploit sequences personally: the attacker-chosen certificate request, confirmed via direct inspection of the issued certificate’s actual identity field; the revoke-then-replay sequence, confirmed rejected with the correct error and confirmed the device’s status stayed revoked afterward.
The part worth stealing
The strongest form of “the review caught it” in this arc is not a reviewer’s written concern: it’s a reviewer’s concern confirmed by actually running the exploit against the real running system, and then confirming the fix the same way. If your security review process stops at reading the diff and agreeing it looks correct, it is one step short of the bar this case sets: give your reviewers the access and the explicit instruction to try to break the thing, not just read it.
What Next
The Local Coding Harness
A different arc, same underlying doctrine applied to a smaller, faster loop: what it took to get a local model from 'cannot write a valid patch' to 'fixes a genuinely foreign repository, zero cloud calls.'