CVE-2026-72888

The CVSS 6.5 rating for this Net::OAuth vulnerability obscures a fundamental truth: memory exhaustion occurs before any signature verification, meaning authentication provides no protection against this attack. The verify() function resolves the signature_method parameter to a class name before checking credentials — a sequence that makes a forged or garbage signature trigger the exact same resource exhaustion path as a legitimate one. Your authentication layer, which should be the gatekeeper, sits downstream of the vulnerable code path. The critical deployment variable is whether you're running persistent Perl workers. In mod_perl, FastCGI, or PSGI environments, the smart_require cache accumulates across thousands of requests — one attacker sending unique garbage signature_method values per request progressively fills worker memory with failed lookup keys. In traditional CGI, each request resets the process, limiting exposure to per-request exhaustion. If you're running persistent workers with Net::OAuth, this is a denial-of-service vector with no effective mitigation short of patching. There is an asymmetry worth noting: the Authorization header path has an implicit length bound (HTTP specs constrain headers), but the POST body signature_method parameter has no stated length constraint. This difference matters for exploit development. However, the header-bound protection is accidental rather than designed — it exists for unrelated HTTP reasons, making it fragile. A protocol revision or proxy behavior change could eliminate it. The deeper pattern here is recurring. This is the fourth time in a decade that an OAuth-adjacent library has exhibited unbounded memoization of failed class lookups — SAML, OIDC, and prior OAuth implementations all show the same cognitive anti-pattern. Each time CVSS scores moderate, each time the fix is 'add a bound,' and each time that creates a new failure mode when legitimate traffic hits the bound. Worse, Net::OAuth handles OAuth 1.0 — a protocol abandoned by IETF in 2012. The library has had no meaningful release in years. If you're running this in production, the realistic remediation isn't 'wait for a patch' — it's migrate away from OAuth 1.0 or isolate the integration. That's a materially different response posture than a live library with an incoming fix, and the CVSS of 6.5 communicates none of it.

Reviewed through automated stages and approved by a human before publication.