- Shipped
- August 19, 2026 at 2:18 AM UTC
- Author
- kamo
- Commit
- f55a95c
KToken could not verify a real token. The four ids it carries are int64s, and the Java signer (kamo-shared-library KToken#canonicalForMac) appends each as a raw `long`, so all 19 digits go into the MAC material. This class read them with Number(), which rounds past 2^53, and every setter then applied `v|0` -- a 32-bit truncation on top of the rounding. 1168485648209608710 came out as a small integer, the recomputed HMAC did not match the one the server signed, and parseAndVerifyCookie returned null: a valid token read as forged. It only ever agreed with itself, on ids small enough to represent. The ids are now the cookie's own digit strings, so the material matches the signer byte for byte, and are validated by shape rather than by Number(), which would defeat the point. The expiry stays a number -- epoch seconds are ~1.8e9 and in no danger. Nothing calls parseAndVerifyCookie today, in any of the three Next apps; the cookie is forwarded to the services verbatim. So this fixes a landmine rather than an outage -- but it is a landmine in an auth path, where the failure would look like a rejected login rather than a rounding bug. The new tests are mutation-proven: 4 of the 6 fail against the previous implementation. The same fix goes to kamo-login and kamo-register, which carry diverged copies of this file with the identical defect.