CVE-2026-9537 in Mojo::JWT
Summary
by MITRE • 07/17/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/17/2026
The vulnerability in Mojo::JWT versions prior to 102 represents a critical timing side-channel attack vector that undermines the security of JSON Web Token implementations. This flaw resides in the decode() method's handling of HMAC signature verification, where the library employs Perl's native eq operator for string comparison instead of implementing constant-time comparison mechanisms. The eq operator performs a byte-by-byte comparison that terminates immediately upon encountering the first mismatched character, creating measurable timing variations that directly correlate to the number of matching leading bytes between the attacker-supplied signature and the expected HMAC value.
This timing variation creates a covert channel through which an attacker can infer information about the correct signature by measuring response times across multiple decoding attempts. The vulnerability operates under the principle of timing attacks where the temporal differences in processing time reveal partial knowledge of the target value, making it particularly dangerous in environments where network latency variations are minimal or controlled. The impact extends beyond simple information disclosure to enable full token forgery capabilities when attackers can aggregate timing measurements over numerous requests to reconstruct the complete HMAC signature.
The technical implementation flaw directly maps to CWE-203, which specifically addresses "Observable Timing Discrepancy" in cryptographic implementations, and aligns with ATT&CK technique T1496 for "Resource Hijacking" through timing-based information leakage. The vulnerability creates a pathway for attackers to perform signature recovery attacks that bypass traditional cryptographic protections by exploiting the predictable timing characteristics of the comparison operation. The lack of constant-time string comparison means that even when signatures are properly generated and transmitted, the verification process itself introduces a security weakness that can be systematically exploited.
From an operational standpoint, this vulnerability affects any application relying on Mojo::JWT for token validation where attacker-controlled tokens might be processed, particularly in scenarios involving user authentication, API access control, or session management. The attack requires only that the attacker can submit crafted tokens and observe response times, making it highly practical against web applications that do not implement proper mitigation strategies. Organizations using affected versions face significant risk of unauthorized access, privilege escalation, and potential data breaches when attackers can aggregate sufficient timing measurements to reconstruct valid signatures for token forgery operations.
Mitigation strategies include upgrading to Mojo::JWT version 1.02 or later where constant-time comparison has been implemented, or implementing custom solutions that utilize constant-time string comparison functions such as those provided by the Crypt::Util or similar cryptographic libraries. Security-conscious implementations should also consider additional protections including request rate limiting, token entropy validation, and monitoring for unusual timing patterns in API response times that might indicate exploitation attempts. Network-level protections such as load balancer configurations that introduce consistent response time variations can provide additional defense-in-depth measures against this class of timing-based attacks while proper code review processes should mandate constant-time comparison practices for all cryptographic verification operations to prevent similar vulnerabilities from emerging in future implementations.