EUVD-2026-45193
GHSA-3rp9-gq85-w2mf
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
AC:H reflects the need for many controlled timing measurements; C:L added because HMAC signature bytes (cryptographic material) are recovered through the oracle.
Primary rating from Vendor (CPANSec).
CVSS VectorVendor: CPANSec
Lifecycle Timeline
4DescriptionCVE.org
Mojo::JWT versions before 1.02 for Perl verify HMAC signatures with a non-constant-time string comparison.
The decode() method compares the supplied signature to the recomputed HMAC with Perl's eq operator, which stops at the first differing byte, so the comparison time varies with the number of matching leading bytes.
A caller that decodes attacker supplied tokens leaks the expected signature through this timing variation, which can be aggregated over many requests to recover the signature and forge a token.
AnalysisAI
Token forgery is possible against any Perl application using Mojo::JWT versions before 1.02 due to a timing side-channel in HMAC signature verification. The decode() method compared the supplied signature against the recomputed HMAC using Perl's native eq operator, which short-circuits on the first differing byte, leaking the expected signature byte-by-byte through measurable response time variation. An attacker with the ability to submit many attacker-controlled tokens to an endpoint that calls decode() can statistically aggregate these timing differences to reconstruct the valid HMAC signature and subsequently forge arbitrary JWT tokens. No public exploit has been identified at time of analysis, and EPSS sits at the 7th percentile, indicating low automated exploitation probability.
Technical ContextAI
Mojo::JWT (CPE: cpe:2.3:a:jberger:mojo::jwt:*:*:*:*:*:*:*:*) is a JWT implementation for the Perl Mojolicious web framework authored by Joel Berger. The root cause is CWE-208 (Observable Timing Discrepancy): Perl's string equality operator eq performs a lexicographic comparison that halts at the first non-matching byte, making comparison time proportional to the length of the common prefix between the attacker-supplied signature and the expected HMAC value. Since HMAC-SHA signatures are deterministic given a fixed key and payload, an attacker can probe byte positions incrementally - submitting crafted tokens and measuring whether response latency increases - to recover the full expected signature one byte at a time. This class of oracle attack does not require knowledge of the HMAC secret directly; it exploits the comparison path rather than the cryptographic primitive. The fix, confirmed in commit b8aefb846613e44b5b12bc170898ffd5b05094a2, replaces the eq comparison with Mojo::Util::secure_compare(), which is a constant-time comparison function that eliminates the timing variation.
RemediationAI
Upgrade Mojo::JWT to version 1.02 or later, which replaces the non-constant-time eq comparison with Mojo::Util::secure_compare() in the decode() method. The patch is confirmed in upstream commit b8aefb846613e44b5b12bc170898ffd5b05094a2 and the 1.02 release is flagged by the maintainer as a mandatory security upgrade. Update via CPAN: cpanm Mojo::JWT or cpan Mojo::JWT. If an immediate upgrade is not feasible, a compensating control is to add artificial uniform-latency padding to all token validation responses (e.g., sleep until a fixed deadline per request), though this degrades performance and does not eliminate the channel if the attacker can subtract the padding or if jitter is insufficient. Restricting the rate of token submission requests at the application or WAF layer reduces the attacker's ability to aggregate measurements but does not eliminate the vulnerability. The only complete fix is the constant-time comparison in version 1.02. Reference: https://seclists.org/oss-sec/2026/q3/168.
Same weakness CWE-208 – Observable Timing Discrepancy
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: ModerateShare
External POC / Exploit Code
Leaving vuln.today