CVE-2026-12746 in Dancer2::Plugin::Auth::OAuth::Provider
Summary
by MITRE • 07/04/2026
Dancer2::Plugin::Auth::OAuth::Provider versions before 0.23 for Perl do not support the OAuth 2.0 state parameter.
The authentication_url method builds the provider authorization redirect without issuing a state value, and the callback method exchanges the callback code and registers the resulting token into the session without verifying that the callback corresponds to an authorization request this session initiated.
Any application that uses this plugin for OAuth 2.0 login is exposed to login cross-site request forgery: because the callback is not bound to the session that began the flow, an attacker who starts an authorization with their own provider account can deliver the resulting callback to a victim, causing the victim's session to complete the attacker's authorization and associating the attacker's provider identity and access token with that session. Where the application persists this as an account link, the attacker may retain access to the victim's account through their own provider credentials.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/04/2026
The vulnerability in Dancer2::Plugin::Auth::OAuth::Provider versions prior to 023 represents a critical security flaw that directly undermines the integrity of OAuth 2.0 authentication flows. This issue stems from the complete absence of state parameter implementation within the plugin's authentication mechanism, creating a fundamental weakness that exposes applications to sophisticated cross-site request forgery attacks. The state parameter serves as a crucial security measure in OAuth 2.0 protocols by providing a unique value that binds the authorization request to the user's session, ensuring that callbacks can be verified against legitimate authentication initiations.
The technical implementation flaw manifests in two critical areas of the plugin's operation. First, the authentication_url method fails to generate and include a state parameter when constructing the provider authorization redirect URL, eliminating any mechanism for tracking or validating the origin of authentication requests. Second, the callback method processes incoming authorization codes without performing any verification that the callback corresponds to an authorization request initiated by the current session. This design flaw directly violates OAuth 2.0 security specifications and creates a pathway for attackers to exploit the authentication flow through session hijacking techniques.
The operational impact of this vulnerability extends far beyond simple authentication bypasses, creating a persistent security risk that can compromise user accounts and maintain attacker access. An attacker can initiate their own OAuth authorization flow using their credentials, then manipulate a victim into completing the callback process, effectively transferring the attacker's provider identity and associated access tokens to the victim's session. This attack vector leverages the fundamental weakness in session binding and demonstrates how the absence of proper state parameter handling creates opportunities for account takeover scenarios. The vulnerability specifically targets applications that persist OAuth credentials as account links, allowing attackers to maintain long-term access to victim accounts through their own provider credentials.
This security flaw aligns with multiple cybersecurity frameworks and attack patterns, including CWE-384 which addresses session fixation vulnerabilities and the broader category of insufficient session binding mechanisms. From an ATT&CK perspective, this vulnerability maps to techniques involving credential access through session hijacking and authentication bypass methods. The vulnerability also relates to NIST SP 800-63B guidelines for authentication protocol implementation, which specifically require state parameter validation in OAuth flows. Organizations using affected versions of this plugin should immediately implement mitigations including manual state parameter implementation, session binding verification, or complete migration to patched versions that properly support OAuth 2.0 security requirements. The risk assessment should include comprehensive review of all authentication flows and session management practices to identify potential exploitation vectors and ensure proper authorization request tracking mechanisms are in place.