Source: libnet-oauth-perl Version: 0.31-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for libnet-oauth-perl. CVE-2026-72887[0]: | Net::OAuth::Client versions before 0.32 for Perl allow the service | provider to silently downgrade OAuth 1.0a to OAuth 1.0 in | get_request_token. Passing a callback to the constructor selects | OAuth 1.0a. get_request_token then revokes that choice when the | request token response omits oauth_callback_confirmed, with no | exception, no warning and no option to require 1.0a. The access | token request is built from the OAuth 1.0 message class, which has | no verifier parameter, so oauth_verifier is dropped from the request | even when get_access_token was passed one. oauth_verifier is the | binding that OAuth 1.0a added between the authorization step and the | token exchange. An application that asked for 1.0a and gets 1.0 is | open to OAuth 1.0 session fixation, where an attacker obtains a | request token, has the victim authorize it, and then completes the | exchange themselves, linking the victim's provider account to a | session the attacker controls. No attacker action sets up the | downgrade: a provider that does not confirm the callback is enough. CVE-2026-72888[1]: | 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. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-72887 https://www.cve.org/CVERecord?id=CVE-2026-72887 [1] https://security-tracker.debian.org/tracker/CVE-2026-72888 https://www.cve.org/CVERecord?id=CVE-2026-72888 Regards, Salvatore
