CVE-2026-12740: OAuth 2.0 State Parameter Missing in Plack::Middleware::OAuth – Account Takeover Risk

Technical summary

The vulnerability stems from two related implementation gaps in RequestTokenV2 and AccessTokenV2 functions. RequestTokenV2 constructs the provider authorization redirect URL without generating or tracking a state parameter—a cryptographic nonce that binds the authorization request to the user's session. Subsequently, AccessTokenV2 processes the OAuth callback and exchanges the authorization code for an access token, then registers the token into the session via register_session, but performs no validation that the callback corresponds to an authorization request initiated by that specific session. This allows an attacker-controlled callback to be accepted by any session, enabling login CSRF (cross-site request forgery). The attacker can weaponize this by initiating an OAuth flow with their own provider account, obtaining a valid callback, and delivering it to a victim's browser—their session will then complete the authorization flow and associate the attacker's provider identity and token with the victim's account.

Business impact

Applications using Plack::Middleware::OAuth 0.10 or earlier for OAuth 2.0 authentication face immediate account takeover risk. An attacker can assume control of a victim's account without knowing the victim's password, provided the application persists OAuth account linkages. This is particularly dangerous in multi-tenant environments or SaaS platforms where account compromise could lead to unauthorized access to sensitive data, lateral movement, or privilege escalation. The attack requires only user interaction (clicking a malicious link or visiting a compromised site) and no special privileges, making it practical to exploit at scale.

Affected systems

Plack::Middleware::OAuth through version 0.10 is affected. Plack is a Perl web application interface and toolkit; this middleware is used by Perl-based web applications to delegate authentication to OAuth 2.0 providers (such as GitHub, Google, or custom OAuth servers). Any Perl application using this middleware for login is vulnerable if it has not upgraded past version 0.10. Applications not using OAuth 2.0 for authentication, or those using alternative OAuth libraries, are not affected.

Exploitability

This vulnerability is highly exploitable with a low attack complexity. It requires only network access and user interaction (the victim must visit or be redirected to a malicious link or site), but no authentication or special privileges. The attacker does not need to compromise the OAuth provider or the target application's infrastructure. The attack is reliable and does not depend on race conditions or timing issues. No special tools are required beyond the ability to craft a URL and host a redirect. Given the prevalence of OAuth-based login and the ease of executing a phishing or redirect attack, this vulnerability poses a significant practical risk.

Remediation

Organizations must upgrade Plack::Middleware::OAuth to a version newer than 0.10 that properly implements OAuth 2.0 state parameter validation. Verify against the vendor advisory for the specific patched version number and installation instructions. Until patching is complete, consider disabling OAuth 2.0 login and reverting to alternative authentication mechanisms, or implement compensating controls such as a Web Application Firewall rule that detects and blocks authorization callback URLs missing expected state parameters (though this is not a substitute for a proper fix).

Patch guidance

Consult the official Plack::Middleware::OAuth repository or CPAN distribution for the latest released version. Apply the patch and test thoroughly in a staging environment to ensure OAuth 2.0 login workflows function correctly and that state parameter validation is active. Verify that callback URLs without a matching state parameter are rejected. If using a CPAN client (e.g., cpanm or perl -MCPAN), update to the latest version available. Document the update in your change management system and communicate the patching timeline to stakeholders.

Detection guidance

Monitor application logs for OAuth callback requests that lack a state parameter or have a state value that does not match any active authorization request in your session store. Web application firewalls can be configured to flag suspicious OAuth callback patterns. Review authentication logs for sudden account linkage changes or new OAuth account associations from unexpected IP addresses or user agents. Conduct a user audit: identify any accounts that have recently linked OAuth identities and, where possible, contact those users to confirm the link was intentional. For development and testing, enable debug logging in the OAuth middleware to observe state parameter handling and ensure it is present and validated.

Why prioritize this

This vulnerability warrants immediate attention due to its CVSS 3.1 score of 8.1 (HIGH severity), practical exploitability, and the severity of the potential impact—account takeover without password compromise. The attack requires only user interaction and network access, making it likely to be exploited against publicly facing applications. The lack of CISA KEV inclusion does not diminish the urgency; patching should proceed without delay.

Risk score, explained

The CVSS 3.1 score of 8.1 reflects a network-accessible vulnerability (AV:N) with low attack complexity (AC:L) that requires user interaction (UI:R) but no attacker privileges (PR:N). The impact is high for both confidentiality and integrity (C:H/I:H), as an attacker can assume full account control and access sensitive data. Availability is not impacted (A:N). The scope is unchanged (S:U), meaning the vulnerability does not affect other components or users beyond the target session. The score appropriately conveys the serious but non-catastrophic nature of login CSRF in OAuth implementations.

Frequently asked questions