CVE-2026-72889
CriticalCVSS 9.8Exploitation Probability (EPSS)
Low risk27th percentile - higher than 27% of all known CVEs
Summary
In Net::OAuth for Perl before version 0.33, the sender can choose the signature algorithm used for verification. The signature_method parameter is required on every request, so the verifying party cannot pin the method. If a message names HMAC-SHA1 or HMAC-SHA256, the key is derived from consumer_secret and token_secret rather than from the provider's key. A provider using RSA-SHA1 holds only the consumer public key, and RFC 5849 does not use consumer_secret for that method, so the required parameter is filled with a placeholder. A client that names HMAC-SHA1 instead has its signature checked against that placeholder, so a guessable one is enough to forge requests for any consumer key and token.
Risk Assessment
An attacker can forge OAuth requests, potentially leading to unauthorized access to protected resources or data integrity compromise.
Recommendation
Update Net::OAuth to version 0.33 or later, which allows the verifying party to pin the signature algorithm.
Other vulnerabilities in Net::OAuth
See all- CVE-2026-75589High
Net::OAuth versions before 0.33 for Perl check HMAC-SHA1, HMAC-SHA256 and PLAINTEXT signatures with a non-constant-time comparison in verify. Each comparison uses the eq operator, which returns as soon as the strings differ, allowing an attacker to recover a valid signature one byte at a time by timing the replies. Under PLAINTEXT, the compared value is the signature key itself, so the search recovers consumer_secret and token_secret.
- CVE-2026-72888Medium
Net::OAuth versions before 0.32 for Perl allow memory exhaustion via unbounded caching of failed module loads in smart_require. smart_require stores results in a process-global hash with no bound and no eviction, and keeps an entry for every class name it is asked about, including names that failed to load, because the return value of the failed eval is stored before the error is checked. The key comes off the wire on the server side: _signature_method_class builds the class name from the signature_method parameter of the incoming message, and verify resolves it before any signature is checked. A remote client chooses both how many entries are created and how long each key is. In a persistent server the hash grows for the life of the worker process until it exhausts memory. Header size limits bound the key length on the Authorization header path, but not on a POST body.
Original NVD description (English source)
Net::OAuth versions before 0.33 for Perl allow the sender to choose the signature algorithm in verify. verify resolves the signature method class from the signature_method parameter of the incoming message. signature_method is required on every request, so the algorithm used to check a signature is chosen by whoever sent it, and nothing lets the verifying party pin the method instead. When a message names HMAC-SHA1 or HMAC-SHA256, the key is derived from consumer_secret and token_secret rather than from the key the provider deployed. A provider deployed on RSA-SHA1 holds only the consumer public key, and RFC 5849 does not use consumer_secret for that method, so the required parameter is filled with a placeholder. A client that names HMAC-SHA1 instead has its signature checked against that placeholder, so a guessable one is enough to forge requests for any consumer key and token.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS