CVE-2026-72889 in Net::OAuth
Summary
by MITRE • 08/19/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in Net::OAuth versions prior to 0.33 represents a critical authentication bypass flaw rooted in the library's handling of cryptographic algorithm negotiation during OAuth signature verification. This issue, classified under CWE-757: Selection of Less-Secure Algorithm During Negotiation and aligned with MITRE ATT&CK technique T1621 (Cryptographic Failure), allows an attacker to manipulate the integrity checks that are fundamental to the OAuth 1.0a protocol defined in RFC 5849. The core technical flaw lies in the verify method, which dynamically resolves the signature verification class based on the signature_method parameter provided by the incoming request message rather than enforcing a pre-configured or server-side pinned algorithm. Because the signature_method field is mandatory for every OAuth request, this design choice effectively delegates control over the cryptographic strength and type of authentication to the client side, creating an opportunity for protocol downgrade attacks where the verifier accepts weaker algorithms that may not align with the provider's security expectations.
In a typical RSA-SHA1 deployment scenario, which relies on asymmetric cryptography, the service provider holds only the consumer public key to verify signatures. According to RFC 5849, the HMAC-based methods require both consumer_secret and token_secret for signature generation, whereas RSA-SHA1 uses the private key held by the client and verified against the public key held by the server. Consequently, when a provider is configured exclusively for RSA-SHA1 verification, it does not possess or utilize the consumer_secret in its validation logic; instead, this parameter is often populated with a placeholder value such as an empty string or null to satisfy API interface requirements without performing actual cryptographic derivation against that secret. This architectural separation between asymmetric and symmetric signing methods creates a dangerous asymmetry if algorithm selection is left unchecked by the verifier.
An attacker can exploit this discrepancy by crafting malicious OAuth requests that explicitly specify HMAC-SHA1 or HMAC-SHA256 as the signature_method, despite the server expecting RSA-based verification. When such a request reaches the vulnerable Net::OAuth implementation, the library switches to an HMAC verification routine and attempts to validate the signature using the placeholder consumer_secret value alongside any provided token secret. Since the attacker controls both the message content and the algorithm selection, they can generate valid HMAC signatures by guessing or brute-forcing the placeholder secret if it is weak, predictable, or known from other sources. This capability allows the forgery of requests for any consumer key and token pair, effectively bypassing authentication entirely because the server accepts a signature that was mathematically generated using a symmetric algorithm against a static, potentially guessable key rather than verifying an asymmetric digital signature tied to a specific private key.
The operational impact of this vulnerability is severe, as it compromises the integrity and authenticity guarantees provided by OAuth 1.0a. Successful exploitation enables unauthorized access to protected resources, data exfiltration, or account takeover depending on the scope of permissions associated with the targeted consumer keys. Furthermore, because the attack relies on manipulating a standard protocol parameter rather than exploiting a buffer overflow or injection flaw, it is difficult to detect through traditional input validation mechanisms that do not inspect cryptographic context. The vulnerability persists until the library enforces algorithm pinning at the configuration level, ensuring that the verifier only accepts signature methods compatible with its deployed keys and rejects any attempt by clients to negotiate weaker symmetric algorithms when asymmetric ones are intended.
Mitigation strategies must focus on enforcing strict algorithm constraints within the OAuth verification process. Developers should update Net::OAuth to version 0.33 or later, where this logic has been corrected to prevent arbitrary algorithm selection during verification. In environments where upgrading is not immediately feasible, a defensive coding approach involves implementing custom wrapper functions that validate the signature_method parameter against an allowlist of approved algorithms before passing it to the underlying verify routine. Additionally, organizations should review their OAuth configurations to ensure that if RSA keys are deployed, HMAC-based fallbacks are explicitly disabled or rejected at the application layer rather than relying on library defaults. Regular security audits and static code analysis tools configured to detect CWE-757 patterns can help identify similar implementation flaws in other authentication libraries where algorithm negotiation is not properly constrained by server-side policy.