"Can you really exploit this?"

If you’ve spent any time working in cybersecurity, you are probably all too familiar with this question. Answering it is not always easy: one person simply can't know everything. CVE-2025-22376, with a CVSS 3.1 score of 9.8, is one of those vulnerabilities that often ends up being questioned regarding its relevance. This is why I chose to analyze this vulnerability in greater depth.

Let’s take a moment to explore this vulnerability and decide for ourselves.

What is this vulnerability?

This vulnerability, which impacts the Perl OAuth library Net::OAuth::Client, was disclosed on the evening of January 3, 2025. The description is as follows:

"In Net::OAuth::Client in the Net::OAuth package before version 0.29 for Perl, the default nonce is a 32-bit integer generated using the built-in rand() function, which is not cryptographically strong."

The issue is classified under CWE-338, which pertains to the "Use of Cryptographically Weak Pseudo-Random Number Generators (PRNGs)." In this case, the weak PRNG could make the nonce predictable, potentially undermining the security guarantees of OAuth.

The vulnerability carries a CVSS 3.1 score of 9.8—a remarkably high score, often associated with remote code execution or similarly severe flaws. However, while this score highlights the potential for exploitation, it may not fully account for real-world constraints or mitigations, which could make the vulnerability less impactful in practice.

What is a nonce?

A nonce is a unique value, used only once, to ensure the security of communications. By preventing the reuse of specific data elements, nonces help safeguard against replay attacks. Think of a nonce as a unique ticket number for a single transaction, ensuring it cannot be reused fraudulently.

If you are curious about nonces and want to know more, Okta has an excellent article on them which I strongly suggest you read.

Now, let’s explore the specific role of nonces in OAuth 1.0, particularly in the context of CVE-2025-22376, to understand how they impact the security of authentication systems.

What's the role of the nonce mentioned in CVE-2025-22376?

To answer this question, we need to delve deeper into the vulnerability. OAuth, in its various forms, involves multiple nonces used in different contexts, so it’s crucial to identify exactly which one is "the right one." By reviewing recent commits in the project's GitHub repository, we can pinpoint the commit that addresses the issue. Below is a screenshot of the relevant sections:

This commit alignment with the vulnerability description, strongly suggests that it is indeed the patch for CVE-2025-22376. Upon closer inspection (lines 260 to 266), we see that the nonce is among several parameters used in a call. These parameters correspond to OAuth 1.0 as defined in RFC 5849.

You might notice that these parameters are missing the oauth_ prefix. In the case of Net::OAuth::Client, this prefix is added to the parameter names before they are used (as shown on line 169 of the same file). The specific nonce of interest here is oauth_nonce.

What are the requirements for the oauth_nonce?

RFC 5849 provides the following definition:

"A nonce is a random string, uniquely generated by the client to allow the server to verify that a request has never been made before and helps prevent replay attacks when requests are made over a non-secure channel. The nonce value MUST be unique across all requests with the same timestamp, client credentials, and token combinations."

This means that the nonce itself does not need to be universally unique. Instead, the combination of the nonce, timestamp, client credentials, and token must be unique. While the RFC specifies that the nonce should be a random string, it offers no explicit guidance on how the value should or should not be generated. Additionally, notes in the RFC emphasize the importance of high-entropy random values, but these recommendations are directed at secrets, not nonces.

Interestingly, multiple APIs still support OAuth 1.0 today. None of the documentation for the following APIs specify strict requirements for the oauth_nonce parameter:

• https://developer.mastercard.com/platform/documentation/authentication/using-oauth-1a-to-access-mastercard-apis/

• https://developer.x.com/en/docs/authentication/oauth-1-0a/authorizing-a-request

• https://developers.google.com/api-client-library/java/google-oauth-java-client/oauth1

X even states in its documentation that "any approach which produces a relatively random alphanumeric string should be OK". However, a review of the libraries provided by Mastercard, X and Google reveals that all their implementations consistently use cryptographically secure random number generators for nonce generation.

Conclusion #1: While it’s not mandatory to use a cryptographically secure PRNG for generating oauth_nonce, it appears to be a widely adopted best practice.

Now that we have a better understanding of the requirements, let's have a look at the risk of of using predictable nonces.

So what are the risks and consequences of  an oauth_nonce being generated by an unsafe PRNG?

There’s no simple answer to this question—it depends on several factors, including:

• How does the server implement nonce validation?

  • If validation is incomplete, it could lead to replay attacks (e.g., resending a previous request repeatedly) or even denial-of-service (DoS) attacks by preemptively sending known valid nonces.

• Is the nonce used, by the server, outside the scope of the RFC in a specific implementation?

  • If so, the risks are unpredictable and entirely dependent on how the implementation repurposes the nonce.

• Is the communication channel encrypted end-to-end?

  • If not, and communication occurs over a plaintext channel, an attacker could intercept nonce values. This might enable targeted DoS attacks or make it easier to predict future nonce values.

• Are OAuth parameters passed in the request URI?

  • While less common, OAuth does allow this. In this scenario, the risks are similar to those of unencrypted communication.

• Is the nonce being generated on a shared computer?

  • I’ll admit, this one’s a bit of a stretch… but in such cases, risks similar to those of unencrypted communications could arise.

Conclusion #2: The risks associated with using an unsafe PRNG for generating oauth_nonce are highly context-dependent. When the code is part of a generic OAuth library, used in various contexts, the potential risks increase because of the wide ranging usage scenarios of these libraries.

With that in mind, let’s return to a more existential question...

"Can you really exploit this?"

Short answer: Yes.

Realistic answer: "Kinda."

It’s entirely possible for someone to guess future nonces when an unsafe PRNG is used. However, guessing the nonce is just one piece of the puzzle. Leveraging that guessed nonce to execute a meaningful attacks is a different challenge altogether. Of course, it’s feasible! But as we’ve explored earlier, the implications and consequences depend heavily on the context and the specificities of the client implementation as well as the server implementation.

"What's your take on the CVSS 3.1 score of 9.8 on this one?"

I find myself questioning this score.

While it’s true that this vulnerability could lead to significant compromises, in isolation—and assuming the absence of other security flaws (a critical detail in my reasoning)—it seems unlikely to justify such a high score as scored by CISA-ADP. I recalculated the CVSS 3.1 score, basing this one on the current analysis, and arrived at a significantly lower value of 5.3.

Below is a screenshot of the calculator: