Bug 2519412 (CVE-2026-72889)

Summary: CVE-2026-72889 Net-OAuth: Net::OAuth: Authentication bypass via chosen signature algorithm
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Net::OAuth for Perl. A remote attacker can exploit this vulnerability by manipulating the signature algorithm used for verification. By specifying a weaker algorithm, such as HMAC-SHA1 or HMAC-SHA256, in the incoming message, the attacker can force the system to use a potentially guessable key for signature validation. This allows the attacker to forge requests, leading to unauthorized access to resources.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2529748    
Bug Blocks:    

Description OSIDB Bzimport 2026-08-19 07:32:01 UTC
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.