Summary
I have a security finding in the signed tool-approval path (experimental_toolApprovalSecret) and no working private channel to report it through. Opening this issue to request one rather than to disclose the details.
Deliberately withholding the specifics here, since the issue is unfixed.
What I can say without arming anyone
- It affects the input binding of the approval HMAC, not the HMAC or the key handling.
- For a specific and reasonably common category of input field, a signature issued for one input verifies against a different input. The documented guarantee is that "changing any of these after signing invalidates the approval."
- Other fields in the same input remain correctly bound, so the failure is silent and type-scoped — no error is raised.
- It is adjacent to, but not the same as, the
canonicalJSONcollision discussed in #18157 / #18187. The fixes in #18265 and #18394 do not cover it; #18394 explicitly limits itself to array-element handling. - It also updates one assessment in #18187: that report concluded the approval caller was safe because its inputs are "JSON-round-tripped". That is not the case for all inputs, which is what makes this reachable.
I have a minimal reproduction using the real signToolApproval / verifyToolApprovalSignature functions, plus a version driven through parseToolCall with a real schema, and controls confirming the correct cases still fail verification as expected. Roughly 40 lines total.