CVE-2026-13410: Dancer::Plugin::Auth::Google Auth Bypass

CVE-2026-13410 Overview

CVE-2026-13410 affects Dancer::Plugin::Auth::Google versions through 0.07 for Perl. The plugin disables TLS certificate verification in its default user agent. Specifically, the underlying HTTP client is initialised with SSL_verify_mode explicitly set to disabled.

This flaw allows an attacker with network man-in-the-middle (MITM) capability between the Dancer application and googleapis.com to intercept the OAuth2 token exchange and the userinfo request. The attacker can return a forged access_token and user profile, and authenticate to the Dancer application as any Google user. The weakness is categorized under CWE-295: Improper Certificate Validation.

Critical Impact
An attacker positioned on the network path can impersonate arbitrary Google users and gain authenticated access to any Dancer application that relies on this plugin.

Affected Products

Dancer::Plugin::Auth::Google for Perl, all versions through 0.07
Perl web applications built on the Dancer framework that use this plugin for Google OAuth2 authentication
Deployments relying on the plugin's default Furl-based user agent configuration

Discovery Timeline

2026-07-17 - CVE-2026-13410 published to the National Vulnerability Database (NVD)
2026-07-17 - Public discussion posted to the Openwall OSS Security list
2026-07-17 - Last updated in NVD database

Technical Details for CVE-2026-13410

Vulnerability Analysis

The plugin implements Google OAuth2 authentication by calling Google endpoints over HTTPS. To perform these calls, it instantiates a default HTTP user agent based on Furl. During initialization, the plugin passes SSL_verify_mode set to a disabled value, which instructs the SSL/TLS layer to accept any peer certificate.

With verification disabled, the client does not validate the server certificate chain or hostname. Any TLS certificate, including one issued by an attacker-controlled certificate authority or a self-signed certificate, is accepted for connections to oauth2.googleapis.com and www.googleapis.com. The OAuth2 code exchange and the subsequent userinfo lookup are therefore not authenticated at the transport layer.

The consequence is a complete break of the OAuth2 trust model. The client cannot distinguish Google from an on-path attacker. See the Furl documentation on HTTPS requests for context on the underlying default behaviour.

Root Cause

The root cause is Improper Certificate Validation [CWE-295]. The plugin explicitly disables SSL_verify_mode in the default user agent instead of using strict verification with a trusted certificate authority bundle. Developers using the plugin inherit this insecure configuration unless they supply their own user agent.

Attack Vector

An attacker must obtain a MITM position between the Dancer application server and Google's OAuth endpoints. Suitable positions include compromised upstream network devices, hostile Wi-Fi or transit networks, rogue DNS or BGP hijacks, or a malicious egress proxy. The attack requires user interaction, since a legitimate user must initiate the Google login flow.

Once positioned, the attacker intercepts the TLS connection to oauth2.googleapis.com, presents any certificate, and responds to the token exchange with a crafted access_token. The attacker then intercepts the userinfo request and returns a chosen Google identity, such as an administrator's email. The Dancer application accepts the response and establishes an authenticated session for the attacker as that user.

No verified exploit code is published in the referenced sources. Refer to the upstream pull request and the MetaCPAN patch for CVE-2026-13410 for the technical fix.

Detection Methods for CVE-2026-13410

Indicators of Compromise

Successful Google logins to the Dancer application originating from unexpected source IP addresses or geolocations
Application logs showing OAuth2 callbacks where the resolved Google user identity does not match the initiating session context
Network traffic to oauth2.googleapis.com or www.googleapis.com presenting certificates not issued by Google Trust Services
Egress connections to Google endpoints traversing an unauthorized proxy or unusual next-hop

Detection Strategies

Inventory Perl deployments for Dancer::Plugin::Auth::Google at version 0.07 or earlier using cpan -l or manifest scans of production hosts
Inspect application source and configuration for custom user agent overrides; flag any use of the plugin's default constructor
Perform TLS inspection at the egress boundary and alert on non-Google issuers for connections destined to Google API hostnames
Correlate authentication events with source IP reputation and prior login history for the same Google identity

Monitoring Recommendations

Log all OAuth2 token exchanges and userinfo responses handled by the Dancer application, including remote peer certificate fingerprints
Monitor for repeated logins by high-privilege accounts from new devices or ASN combinations following patch deployment
Enable alerting on any outbound TLS handshake where certificate validation would fail if enabled, using proxy or DPI logs

How to Mitigate CVE-2026-13410

Immediate Actions Required

Upgrade Dancer::Plugin::Auth::Google to a fixed release above 0.07 as soon as it is available on CPAN
Until a fixed release is installed, apply the MetaCPAN patch for CVE-2026-13410 to the deployed module
Rotate any OAuth2 client secrets configured for the affected Dancer applications
Invalidate active sessions and force reauthentication for all users

Patch Information

The upstream fix is tracked in pull request #5 on the Dancer-Plugin-Auth-Google repository. The corresponding patch file is published as CVE-2026-13410-r1.patch via MetaCPAN Security. The fix enables strict TLS verification in the default user agent so that Google API responses are authenticated at the transport layer.

Workarounds

Supply a custom user agent to the plugin that enforces SSL_verify_mode => SSL_VERIFY_PEER and points at a trusted CA bundle such as Mozilla::CA
Restrict the application's egress to Google endpoints through a controlled proxy that performs full certificate validation and pins to Google Trust Services issuers
Temporarily disable Google OAuth2 login in the Dancer application and require an alternative authentication method until patched

bash

# Configuration example: enforce TLS verification when constructing the user agent
cpanm Mozilla::CA
cpanm IO::Socket::SSL

# In the Dancer application, pass a verifying Furl instance to the plugin:
#   use Furl;
#   use IO::Socket::SSL;
#   use Mozilla::CA;
#   my $ua = Furl->new(
#       ssl_opts => {
#           SSL_verify_mode => IO::Socket::SSL::SSL_VERIFY_PEER(),
#           SSL_ca_file     => Mozilla::CA::SSL_ca_file(),
#       },
#   );