Findings · 2026-10-22 · By VSNARY | Emmanuel Orta
Our receipt checker would have rejected our own receipts
A flaw in our published offline verifiers would have called genuine CrawlCheck receipts forged after our first routine key change. Our tests caught it before any receipt was affected.
CrawlCheck's offline verifiers for JavaScript, Python and the command line would have rejected genuine receipts signed by a key that had since been replaced, and in one case would have accepted a receipt signed by the wrong key. No real receipt was ever affected: the keys involved start signing on 9 November 2026, and our own tests caught the gap first. The fix shipped in SDK 1.9.1 on 22 October 2026. Anyone who verifies CrawlCheck receipts should upgrade before 9 November.
The answers CrawlCheck gives AI agents come back signed, so an agent, or anyone auditing it later, can check them offline with the verifier we publish, without having to trust us. Ours was right about today and wrong about the day after our first routine key change.
What would users have seen? #
After that key change, a genuine receipt signed before it would have failed verification, reported as signed by the wrong kind of key. The gap ran the other way too: a receipt signed by a key that should not have signed it would have passed. The first people to notice would have been the ones relying on the receipts.
What was wrong? #
When a signing key is replaced, the receipts it signed while it was in service are still genuine and must still verify. Our verifiers forgot about replaced keys when deciding which key should have signed a receipt, so they would have judged old receipts by the wrong rule.
| Item | Status |
|---|---|
| Real receipts affected | None |
| Fixed in | SDK 1.9.1, released 22 October 2026 |
| Keys involved start signing | 9 November 2026 |
| Verifiers fixed | npm package, Python package, command-line tool |
| How it was found | a missing case in our own published key-rotation tests |
What changed? #
A replaced key now counts only for the period it was in service. Receipts it signed in that period verify; anything it signs afterwards is rejected. A decision can now only pass if it was signed by the kind of key that was meant to sign it at that moment. The published key-rotation tests now include the case that caught this.
What should you do? #
If you verify CrawlCheck receipts, upgrade to 1.9.1 before 9 November: npm install @crawlcheck/sdk@1.9.1 or pip install crawlcheck==1.9.1. If you wrote your own verifier, run the published conformance tests against it; the key-rotation cases are the ones this flaw would have failed. If you only read CrawlCheck reports, nothing changes for you.
The lesson for anyone who checks signatures #
A signature check is only as good as its rule about time. When you rotate a key, test the documents it signed before the rotation, not only the ones signed today. The same kind of gap left our timestamp proofs stuck at pending; for how signed requests are checked in general, see Web Bot Auth explained.
The main product
Found this on your own site? We fix it for $100.
Scan free to see where you stand. The fix is one site, every finding implemented and re-measured, with a sealed before and after.
Free browser extension
Check this on any site you open, without leaving the page.
CrawlCheck for Chrome grades every site you visit A–F and shows, from your own browser, what search engines and AI assistants are actually served. Free, no account.
Questions this post answers
Were any CrawlCheck receipts rejected because of this?
No. The keys involved had not signed anything and no key had been replaced, so the flaw never judged a real receipt.
Do I need to upgrade?
If you verify CrawlCheck receipts with the npm package, the Python package or the command-line verifier, upgrade to 1.9.1 before 9 November 2026. Readers of reports need to do nothing.
Does a receipt stay valid after its signing key is replaced?
Yes, as long as it was signed while that key was in service. Anything the key signs after it was retired is rejected.
Does a valid receipt mean an agent may act?
No. A valid signature proves the receipt is genuine and unchanged. What the agent may do is the decision written inside it.
Related findings
Comments
Comments are read before they appear. Nothing is published automatically, and no account is needed.
Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.