Loading story…
A security flaw tracked as CVE-2026-66901 affects Google::Auth for Perl versions before 0.09, allowing server-side request forgery (SSRF) and credential exfiltration when applications build credentials from untrusted or partially trusted JSON configuration. The issue stems from unvalidated URLs embedded in credential data, which can cause affected applications to send outbound requests to attacker-controlled hosts, including internal services and link-local metadata endpoints, while transmitting sensitive authentication material.
The vulnerability impacts multiple credential flows, including external_account, authorized_user, impersonated_service_account, and service_account. Google’s Perl auth library repository shows a related remediation in a security fix titled "Validate token_uri in ServiceAccountCredentials", and version 0.09 is reported to fully address the issue by validating URL hosts against googleapis.com or an application-pinned universe domain before requests are made; versions 0.06 through 0.08 only provided partial mitigations.
See affected versions and whether adversaries are exploiting it.
5 events from the most recent confirmed update back to the earliest known activity.
Robert Rothenberg of the CPAN Security Group published an advisory for CVE-2026-66901 describing SSRF and credential exfiltration risks in Google::Auth versions before 0.09 affecting multiple credential flows.
Version 0.09 added URL validation to ServiceAccountCredentials and fully fixed the SSRF and credential exfiltration issue by validating URL hosts against googleapis.com or an application-pinned universe domain before requests are made.
A security-related repository commit titled "fix(security): Validate token_uri in ServiceAccountCredentials" was dated August 3, 2026, indicating remediation work in the Google-Auth component for service account credential handling.
Version 0.08 moved _validate_url to Google::Auth::Credentials and added URL validation to UserRefreshCredentials and ImpersonatedServiceAccountCredentials, extending but not fully completing the fix.
Version 0.06 introduced a partial mitigation by adding a _validate_url host check to the external_account class, but the check relied on a universe_domain value read from the same credentials JSON.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
3 references tracked. Mallory keeps watching after this page renders.
seclists.org
Open sourcegithub.com
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A researcher disclosed a **Google identity provider** vulnerability that allowed account takeover through the OAuth 2.0 Device Authorization Grant (`RFC 8628`). The issue reportedly stemmed from two flaws in Google's implementation: a device authorization session could be transferred across browsers using a copied challenge URL, and the authorization server did not ensure that the `client_id` and requested scopes in the later consent step matched those originally tied to the issued `device_code`. The write-up describes the bug as a **confused deputy** condition that let attackers hijack device-code sign-in flows and obtain tokens for arbitrary Google-registered clients. By combining those weaknesses with `prompt=none`, an attacker could allegedly send a single link to a victim already signed in with Google and trigger silent token issuance without a consent screen, fresh 2FA challenge, or obvious account-activity warning. The researcher said the attack could move beyond limited scopes such as YouTube TV and be escalated to **Google Cloud** permissions and even **Gmail** access through IMAP XOAUTH2 when a substituted client was permitted to request `https://mail.google.com`. According to the disclosure, the bug was reported to Google through its VRP, initially rejected, later reopened, fixed, and ultimately awarded a **$13,337** bounty.
Jul 17, 2026
Google has patched a maximum-severity remote code execution flaw in **Gemini CLI** that affected headless deployments, especially **GitHub Actions** and other CI/CD workflows. The vulnerability stemmed from overly permissive workspace trust handling that automatically treated active folders as trusted and could load attacker-controlled configuration files and environment variables from local `.gemini` directories. The issue was independently discovered by Elad Meged of Novee and Dan Lisichkin of Pillar Security, and researchers warned that successful exploitation could expose secrets, credentials, source code, and connected downstream systems. Google said the issue is addressed in **Gemini CLI** versions `0.39.1` and `0.40.0-preview.3`, but warned that applying the fix may require additional workflow changes to avoid breaking automation. The `run-gemini-cli` GitHub Action defaults to the latest release, which can disrupt pipelines that depended on the previous implicit trust behavior, while workflows using `--yolo` mode may fail silently unless tool allowlists are updated to align with the new policy engine. Google is urging organizations to review CI/CD jobs and move to explicit trust settings and compatible allowlists before resuming automated use.
Jun 29, 2026
Google's MCP Toolbox was found vulnerable to a DNS rebinding attack tracked as **`CVE-2026-9739`**, affecting deployments that use **Server-Sent Events (SSE)** under specification **`v2024-11-05`**. The flaw stemmed from a hardcoded permissive CORS header, **`Access-Control-Allow-Origin: *`**, left in the SSE initialization handler even after `allowed-origins` and `allowed-hosts` controls were introduced during beta. The issue is classified as **`CWE-942`** and was reported to Google through `cve-coordination@google.com`, with public disclosure tied to GitHub issue **`#3053`**. Researchers said the weakness could let an attacker abuse a victim's browser to access internal MCP Toolbox services and connected enterprise databases, potentially exposing sensitive data and enabling unauthorized queries. Google addressed the issue in pull request **`#3054`** by removing the wildcard origin behavior and enforcing stricter origin validation. Organizations using MCP Toolbox are being urged to upgrade to the patched release, limit allowed origins to trusted domains, disable unnecessary SSE endpoints, audit internet-exposed SSE services, and watch for unusual internal request patterns that could indicate exploitation.
Jun 29, 2026