Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-16T14:16:54.860Z",
  "pubdate": "2026-08-16T14:16:54.860Z",
  "executiveSummary": "Net::OAuth::Client versions before 0.32 for Perl suffer from an OAuth 1.0a to OAuth 1.0 downgrade vulnerability within the get_request_token function.\nThe vulnerability allows a service provider to silently downgrade the protocol without generating exceptions, warnings, or providing an option to strictly require OAuth 1.0a.\nWhen the request token response omits the oauth_callback_confirmed parameter, the implementation revokes the OAuth 1.0a choice selected during constructor initialization and switches to the OAuth 1.0 message class for the subsequent access token request.\nThis omission causes the crucial oauth_verifier parameter to be dropped entirely from the request, even when explicitly supplied to get_access_token.\nThe primary risk implication is exposure to OAuth 1.0 session fixation attacks, where an attacker can link a victim's provider account to an attacker-controlled session.\nNo active attacker manipulation of the protocol is strictly necessary to trigger the downgrade, as a non-confirming service provider alone is sufficient.\nAffected systems consist of applications utilizing Net::OAuth::Client for Perl prior to version 0.32.",
  "technicalDetails": "The root cause of the vulnerability resides in the strict conditional handling within the get_request_token function of Net::OAuth::Client. When an application passes a callback parameter to the constructor, the client ostensibly selects OAuth 1.0a compliance.\nHowever, if the service provider's request token response fails to return the oauth_callback_confirmed parameter, the client logic automatically revokes the OAuth 1.0a selection without raising exceptions, emitting warnings, or enforcing strict protocol requirements.\nSubsequent cryptographic message construction for the access token request relies on the OAuth 1.0 message class rather than the OAuth 1.0a implementation.\nBecause the OAuth 1.0 message class lacks support for the verifier parameter, the oauth_verifier value is systematically dropped from the request payload, even if get_access_token was explicitly provided with one.\nThe oauth_verifier parameter serves as the foundational cryptographic binding introduced in OAuth 1.0a to securely connect the user authorization step with the final token exchange phase.\nThe step-by-step attack flow proceeds as follows: First, an attacker initiates an authentication flow and obtains a valid request token from the service provider. Second, the attacker tricks the victim into authorizing this specific request token on the provider's platform. Third, because the client implementation silently falls back to OAuth 1.0 and drops the oauth_verifier, the attacker captures the authorized request token without requiring validation of the verifier. Fourth, the attacker completes the token exchange using the acquired credentials, successfully linking the victim's provider account to a session entirely controlled by the attacker.\nThe vulnerable component is the get_request_token method within Net::OAuth::Client versions prior to 0.32. The attack requires network exposure between the client application, the service provider, and the victim, but does not necessitate specific authentication or elevated privileges from the attacker."
}