dev.to post on CVE-2026-118759: keep JWT inspection 100% client-side to avoid token leaks

What the post claims

A post published on dev.to on November 2, under the DevOmniTools account, describes a vulnerability it identifies as CVE-2026-118759 and makes a blunt argument: token inspection should never leave the browser. According to the post, the root cause is authentication token leakage combined with session fixation enabled by insecure loopback cookies, and the attack vector is man-in-the-middle interception of inspection queries — in practice, a developer debugging an auth flow pastes a live production token into a centralized online formatter, and that request, along with headers, session IDs and user metadata, lands in the provider's access logs. The post does not elaborate on how the loopback-cookie condition connects to that formatter scenario. It cites RFC 7519, the JSON Web Token standard, and the W3C Web Cryptography API as reference points.

The proposed remediation

The fix the authors propose is architectural rather than a patch: all token decoding and cryptographic payload assertions should execute strictly in browser memory, using the standard WebCrypto interface exposed as window.crypto.subtle, with zero server-side telemetry.

To demonstrate, the post includes a TypeScript function that splits a JWT into its three dot-separated segments, base64url-decodes the signature, imports an RSA public key supplied in JWK form, and calls crypto.subtle.verify with RSASSA-PKCS1-v1_5 and SHA-256 to check the signature. Because every step runs inside the page, no token material travels to any endpoint. Two practical limits are visible in the sample as written: it covers RS256-style signatures only, so teams using HS256, ES256 or EdDSA would need additional code, and it verifies a signature rather than validating claims such as expiry or audience, which applications still have to enforce.

A caveat on sourcing

This post is the sole source for the story, and it doubles as promotion: it points readers to a free "JWT & Token Decoder" utility that the authors themselves run, described as executing entirely in browser RAM. The identifier CVE-2026-118759 cannot be cross-checked against any other material provided here, and the post names no affected product, no patch and no assigning authority. The vulnerability framing should therefore be read as the authors' claim rather than a confirmed advisory. The underlying hygiene advice, however, stands on its own merits.

Why it matters

Whether or not this particular CVE checks out, the risk it points at is concrete: any hosted utility — a formatter, regex tester or base64 encoder — sees everything submitted to it, and may log or retain that input. JWTs are an especially poor fit for such tools because the payload is merely base64-encoded, not encrypted, and routinely carries session identifiers, scope or tenant claims, or user details. A production token exposed this way should be treated as compromised: revoke it, rotate whatever access it granted, and review the provider's logging behaviour if possible.

The alternative the post recommends costs little. WebCrypto verification is a few dozen lines of code, works offline, and removes the need to trust a third-party service with secrets at all. The generalizable rule for teams is to keep secret-bearing debugging local — in editor plugins, CLI tools or self-hosted utilities — and if a web tool must be used, confirm in the browser's network panel that it makes no outbound requests before pasting anything sensitive.