CyberSecBulletin
CVE-2026-66901NVD status: Deferred

Google::Auth: Insertion of Sensitive Information Into Sent Data

Published Updated By the CyberSecBulletin desk

CVE-2026-66901 is a high-severity insertion of sensitive information into sent data vulnerability in Google::Auth from CJCOLLIER, with a CVSS 3.1 base score of 7.5 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists version 0.09 as the first without the flaw, so updating Google::Auth to that release or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.52% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Google::Auth to 0.09 or a later version.
  2. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
CJCOLLIERGoogle::Authbefore 0.090.09

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
NoneNothing can be modified.
Availability
NoneAvailability is not affected.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Scored by CISA (ADP).

Official description

Google::Auth versions before 0.09 for Perl allow server side request forgery and credential exfiltration via unvalidated URLs taken from the credentials JSON. The URLs the library requests are read from the credentials JSON, and their hosts were not checked against the universe domain before the request. For an external_account configuration, retrieve_subject_token fetched credential_source.url with headers from the same JSON, and fetch_access_token posted the subject token to token_url, then sent the STS access token it received to service_account_impersonation_url in an Authorization: Bearer header. The authorized_user, impersonated_service_account and service_account configurations posted the client secret and refresh token, the source access token, and a signed JWT assertion to their own JSON-supplied token_uri or impersonation URL. Any caller that builds credentials from a configuration it does not fully control issues those requests from the application's network position, reaching hosts the configuration names, including internal services and link-local metadata endpoints, and hands them the credentials each request carries. The service_account assertion is bound to aud, so it is not replayable against Google. Version 0.06 added a _validate_url host check to the external_account class, keyed on a universe_domain read from the same credentials JSON. Version 0.07 gated a JSON-supplied universe domain behind GOOGLE_EXTERNAL_ACCOUNT_ALLOW_CUSTOM_UNIVERSES=1, deriving the pin flag from arguments that an earlier BUILDARGS pass had already merged on the make_creds path. Version 0.08 passed the pin decision through as an explicit constructor argument and moved _validate_url to Google::Auth::Credentials, adding the call to UserRefreshCredentials and ImpersonatedServiceAccountCredentials, and 0.09 added it to ServiceAccountCredentials.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Insertion of Sensitive Information Into Sent Data

The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.

How developers prevent this class of flaw

  • Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.
  • Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.
  • Setup default error messages so that unexpected errors do not disclose sensitive information.

More Insertion of Sensitive Information Into Sent Data vulnerabilities (CWE-201)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: partial).
  3. Record last changed materially (score, affected products, status or references).

References

Other vulnerabilities in Google::Auth

All Google::Auth vulnerabilities

Recent Insertion of Sensitive Information Into Sent Data vulnerabilities

Spotted an error? Tell us.