Live › vulnerability › CVE-2026-74760
Google::Auth versions 0.11 through 0.12 for Perl do not check the OAuth state value on the gcloud login callback. A local process can submit its own Google authorization code, so the stored credentials end up belonging to the attacker's account.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-01 17:21 UTC. All times on this page are UTC.
Teams that use the Perl Google::Auth library and run the gcloud-auth or application-default login flow on a machine where other local users or processes could run code. The flaw is local: an attacker must already be able to run a process on the same machine during the login window. Systems that do not use the Perl library or the gcloud login flow on shared hosts can skip it.
No product ranges from the sources yet.
perl -MGoogle::Auth -e 'print $Google::Auth::VERSION'Google::Auth pinned to 0.11 or 0.12Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Google::Auth versions from 0.11 through 0.12 for Perl accept an authorization code from any local process because the gcloud-auth login callback does not check the OAuth state.
The gcloud-auth login and application-default login commands send a state parameter with the authorization request, then take the code from the first request to reach their loopback listener without comparing the returned state.
A local attacker can submit an authorization code for their own Google account. The CLI exchanges it and stores the refresh token as the user's credentials, so the user's tools then act as the attacker's account.
This page as .md · .json · in your agent: get_signal("CVE-2026-74760")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.