EUVD-2026-59987Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AC:H because exploitation needs a non-confirming provider outside attacker control, UI:R because the victim must authorize the attacker's request token, A:N as there is no availability impact - only account-linking integrity/confidentiality loss.
Primary rating from Vendor (9b29abf9-4ab0-4765-b253-1875cd9b441e).
CVSS VectorVendor: 9b29abf9-4ab0-4765-b253-1875cd9b441e
Lifecycle Timeline
5DescriptionCVE.org
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.
AnalysisAI
Silent OAuth 1.0a-to-1.0 protocol downgrade in the Perl module Net::OAuth::Client (versions before 0.32) lets a service provider strip the anti-session-fixation protection an application explicitly requested. When an app configures a callback (selecting 1.0a) but the provider's request-token response omits oauth_callback_confirmed, get_request_token silently reverts to OAuth 1.0, which drops the oauth_verifier from the access-token exchange with no exception or warning, re-exposing the app to OAuth session fixation. No public exploit identified at time of analysis; EPSS is low (0.21%) and this is not in CISA KEV, but the fix is vendor-confirmed in release 0.32.
Technical ContextAI
The affected component is Net::OAuth::Client, the consumer/client class of the Perl Net-OAuth distribution (author RRWO/vurtdev on CPAN and GitHub). OAuth 1.0a, defined in RFC 5849, hardened OAuth 1.0 against a callback-fixation attack by adding two coupled elements: the provider echoes oauth_callback_confirmed in the request-token response, and it later returns an oauth_verifier that the client must present when trading the request token for an access token. The verifier cryptographically binds the authorization step to the token exchange. The root cause maps to CWE-757 (Selection of Less-Secure Algorithm During Negotiation, i.e. an algorithm/protocol downgrade): the client uses presence of oauth_callback_confirmed as its sole signal and, when absent, rebuilds the access-token request from the OAuth 1.0 message class, which has no verifier parameter, so gather_message_parameters() discards any oauth_verifier the caller supplied.
Affected ProductsAI
Net::OAuth (Net-OAuth Perl distribution) at all versions before 0.32, specifically the Net::OAuth::Client class; the fix landed in 0.32 (metacpan release RRWO/Net-OAuth-0.32). Only applications that pass a callback to Net::OAuth::Client->new (thereby selecting OAuth 1.0a) and interact with a provider that omits oauth_callback_confirmed are actually exposed. Vendor advisory: GitHub Security Advisory GHSA-jh72-4qq2-8j6g (https://github.com/vurtdev/Net-OAuth/security/advisories/GHSA-jh72-4qq2-8j6g); additional references include the oss-security disclosure (https://seclists.org/oss-sec/2026/q3/506), VulDB entry https://vuldb.com/vuln/391188, and EUVD-2026-59987.
RemediationAI
Vendor-released patch: 0.32 - upgrade Net-OAuth to 0.32 or later (fixing commit fd505dac1988723ed96721657663f2e4ac731644; changelog at https://metacpan.org/release/RRWO/Net-OAuth-0.32/changes). After upgrading, get_request_token croaks instead of silently downgrading when the provider fails to confirm the 1.0a callback, and get_access_token warns if a verifier is supplied while in 1.0 mode. If you must interoperate with a genuinely OAuth-1.0-only provider, you can opt back into the old behavior with allow_v1a_downgrade => 1 in the constructor - but this restores the session-fixation exposure and should only be used against providers you trust and that never handle a 1.0a authorization flow; prefer instead to fix the provider or refuse 1.0. If you cannot upgrade immediately, a compensating control is to assert oauth_callback_confirmed yourself in application code before proceeding past the request-token step and abort the flow if it is missing, rather than relying on the library.
Same technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| openSUSE Tumbleweed | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today