V8's ToBoolean path leaks the secret bit that constant-time-js was written to hide

A developer who calls `select(condition, a, b)` in a crypto routine is buying one property: the same instructions run and the same memory gets read whichever way the secret bit falls. The disclosure email from the University of British Columbia group, which Soatok reproduced in the pull request for the fix, says the property does not survive the trip from JavaScript to the machine. Yayu Wang wrote that the leakage arises from V8's ToBoolean mechanism, its different handling of -0 and -1, and direct accesses to the raw true and false Oddball objects on different cache lines ^[8].

There is no `if` in the library's source. V8 still has to decide whether the condition is truthy, and the path it takes to do that touches different cache lines depending on the answer ^[8]. An attacker measuring cache accesses on the same machine learns the condition.

Soatok documented the limit himself, six years early: his 2020 guide said the algorithms it discussed could not rule out compiler or runtime optimizations that undermine security goals ^[25], and stated the ceiling plainly: "You can achieve algorithmic constant-time, but any higher assurance was outside the scope of the work being done" ^[2]. On the cost of doing better, he wrote that "as a furry who writes blog posts in my spare time for fun, I don't exactly have the budget for massive research projects in formal verification" ^[22].

The email arrived at 4:51 PM on 2026-08-21 and he answered Wang at 4:54 PM, three minutes later ^[11][18], with "I'm currently traveling and will not be at a keyboard until Tuesday" ^[12]. Handling was quick where one person controlled it. He verified the report and wrote a patch on 25 August, and sent it to everyone on the thread the next day ^[13][14], five days after the first email ^[19]. Wang confirmed the leakage was gone on 9 September, 14 days after receiving the patch ^[15][21], and version 0.5.0 went public on 10 September, 20 days after disclosure ^[16][20].

Why verify first? Soatok wrote that AI-driven vulnerability hunting, "punctuated by severity inflation and frequent hallucinations", has significantly increased the proportion of bogus reports to legitimate ones ^[17].

The measured blast radius is zero. NPM shows no dependent packages for constant-time-js ^[4], and Soatok said he has no idea whether any proprietary software built on his designs ^[5]. The CVE request is aimed at those users: he wrote that an `npm audit` result or an assigned CVE is likely to trip a company's internal security processes and prompt an upgrade ^[10]. The report covers three named functions in one library on one engine, and it does not measure other JavaScript cryptography code.

For anyone weighing a constant-time helper in JavaScript, the question is whether the threat model includes an attacker who can observe cache behaviour on the same host. Then whether you can inspect the instructions your runtime emits for the branchless expression you wrote. In a JIT the second answer is no, and here the engine's own boolean conversion is the leak ^[8]. Where the first answer is yes, that operation belongs in code whose output you can read, or the function's documentation has to name the attacker it stops short of. The cheap version of that work costs a paragraph. Formal verification is the expensive version, and the library's author said he cannot fund it ^[22].