CVE-2026-66901: Google::Auth for Perl SSRF Vulnerability

CVE-2026-66901 Overview

CVE-2026-66901 is a Server-Side Request Forgery (SSRF) and credential exfiltration vulnerability in the Google::Auth Perl library at versions prior to 0.09. The library reads request URLs from a credentials JSON without validating their hosts against the universe domain. An attacker who controls the credentials configuration can redirect authentication traffic to arbitrary hosts, including internal services and link-local metadata endpoints. Because the library forwards secrets with those requests, the attacker also receives client secrets, refresh tokens, source access tokens, and Security Token Service (STS) tokens issued during the flow.

Critical Impact
Applications that build credentials from untrusted or partially-controlled configuration files can be coerced into leaking OAuth 2.0 secrets and STS tokens to attacker-selected hosts.

Affected Products

Google::Auth for Perl, versions prior to 0.06
Google::Auth versions 0.06 and 0.07 (partial fixes only, gaps in UserRefreshCredentials, ImpersonatedServiceAccountCredentials, and ServiceAccountCredentials)
Google::Auth version 0.08 (fixed for external, user refresh, and impersonated service account, but not ServiceAccountCredentials)

Discovery Timeline

2026-08-04 - CVE-2026-66901 published to the National Vulnerability Database
2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-66901

Vulnerability Analysis

The Google::Auth library derives multiple outbound HTTP request URLs from fields inside the credentials JSON document. For an external_account configuration, retrieve_subject_token fetches credential_source.url using headers taken from the same JSON. The library then posts the subject token to token_url in fetch_access_token and forwards the resulting STS access token to service_account_impersonation_url in an Authorization: Bearer header.

The authorized_user, impersonated_service_account, and service_account configurations each post sensitive material to their own JSON-supplied token_uri or impersonation URL. The authorized_user flow posts the client secret and refresh token. The impersonation flow posts the source access token. The service_account flow posts a signed JSON Web Token (JWT) assertion. Because the JWT is bound to the aud claim, it is not replayable against Google, but the other credentials are directly usable.

The issue is classified under [CWE-201: Insertion of Sensitive Information Into Sent Data].

Root Cause

The library did not validate that hosts named in the credentials JSON matched the configured universe domain before issuing requests. Version 0.06 added a _validate_url host check to the external account class, keyed on a universe_domain field read from the same JSON. That check did not cover sibling credential classes.

Attack Vector

Any caller that builds credentials from a configuration it does not fully control issues those requests from the application's network position. This reaches hosts the configuration names, including internal services and cloud link-local metadata endpoints such as 169.254.169.254, and hands them the credentials each request carries.

text

# Patch history from Google-Auth/Changes
0.09    Mon Aug 3 2026
    - Hardened ServiceAccountCredentials against SSRF by validating token_uri domain.
    - Added regression test for ServiceAccountCredentials token_uri SSRF.

0.08    Sun Aug 2 2026
    - Improve safety and validation for external credentials.
    - Added regression tests for universe domain bypass and sibling class validation gaps.

0.07    Fri Jul 31 2026
    - Hardened credential validation and handling (Custom Universe opt-in safeguards).
    - Added untainting and validation for pluggable credentials commands.

Source: GitHub Patch Commit #cbbb078

Detection Methods for CVE-2026-66901

Indicators of Compromise

Outbound HTTP or HTTPS requests from Perl application hosts to link-local metadata endpoints such as 169.254.169.254 or metadata.google.internal that do not originate from a legitimate metadata client.
Outbound authentication traffic from application servers to hosts that are not *.googleapis.com or the configured universe domain.
Authorization: Bearer headers being sent to unexpected external or internal hosts by processes loading the Google::Auth module.

Detection Strategies

Inventory installed Perl modules and identify hosts running Google::Auth versions below 0.09 using cpan -l or package manifests.
Inspect application code paths that call Google::Auth::Credentials->make_creds with JSON sourced from user uploads, shared storage, or environment-derived paths.
Correlate process telemetry for perl invocations that issue outbound requests to non-Google domains immediately after reading a credentials JSON file.

Monitoring Recommendations

Enforce egress allow-lists on application subnets so Google::Auth clients can only reach the intended universe domain.
Alert on any HTTP request from workload identities that targets link-local or RFC1918 addresses when the workload is not expected to interact with a metadata service.
Log and review changes to credential JSON files in configuration management to detect adversarial modification of token_uri, credential_source.url, or service_account_impersonation_url fields.

How to Mitigate CVE-2026-66901

Immediate Actions Required

Upgrade Google::Auth to version 0.09 or later on all Perl workloads that authenticate to Google Cloud.
Audit every credentials JSON consumed by production applications and verify that token_uri, token_url, and service_account_impersonation_url point only to trusted Google-controlled hosts.
Treat any credentials JSON sourced from user input, tenants, or unreviewed configuration repositories as untrusted until validated.

Patch Information

The fix landed across a series of commits. Version 0.06 introduced the initial _validate_url host check for external accounts. Version 0.07 gated a JSON-supplied universe domain behind the environment variable GOOGLE_EXTERNAL_ACCOUNT_ALLOW_CUSTOM_UNIVERSES=1. Version 0.08 moved _validate_url to Google::Auth::Credentials and applied it to UserRefreshCredentials and ImpersonatedServiceAccountCredentials. Version 0.09 extended validation to ServiceAccountCredentials. See the MetaCPAN Changes for Google-Auth and the Openwall OSS-Security Discussion for full details.

Workarounds

Restrict who can write to the file system paths from which the application loads credentials JSON, and require code review for any change to token_uri or service_account_impersonation_url.
Set restrictive network egress policies so applications cannot reach the cloud metadata service or arbitrary external hosts, limiting SSRF impact.
Do not set GOOGLE_EXTERNAL_ACCOUNT_ALLOW_CUSTOM_UNIVERSES=1 in production unless a custom universe domain is required and the credentials source is fully trusted.

bash

# Upgrade Google::Auth to a patched release
cpan CJCOLLIER/Google-Auth-0.09.tar.gz

# Verify the installed version
perl -MGoogle::Auth -e 'print $Google::Auth::VERSION, "\n"'

# Block egress to the cloud metadata service from application hosts
iptables -A OUTPUT -d 169.254.169.254 -j REJECT