Bug#1144539: libnet-oauth-perl: CVE-2026-72887 CVE-2026-72888

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