By Kat Traxler —

No Permissions Required: Cross-Tenant Data Theft via BigQuery Data Transfer

No Permissions Required: Cross-Tenant Data Theft via BigQuery Data Transfer

Google Cloud customers who use the BigQuery Data Transfer Service as directed are at risk: an attacker with no permissions in their project can exfiltrate their private data. Google has no plans to fix it.

If you use the service, shrink your exposure window. The network attachment can be used as an open door into your network when it's configured to run a BQ Data Transfer. The moment a transfer finishes, remove the attachment to prevent possible data exfiltration.

Service Background

This issue arises due to how one service, the BigQuery Data Transfer Service, uses another: Private Service Connect. Some background.

Private Service Connect (PSC) lets a Google-managed service reach a resource via a network attachment into a private Virtual Private Cloud (VPC). This Google Cloud feature lets a producer service attach a network interface in a VPC and reach the private resources inside. The attachment's connection preference decides who may enter: ACCEPT_AUTOMATIC admits any producer; ACCEPT_MANUAL admits only an allow-listed set of producer projects.

The BigQuery Data Transfer Service (DTS), when configured by customers, allows for the copying of data into BigQuery on a schedule. When the source sits on a private network, such as a private-IP database, DTS reaches through a PSC network attachment. The connector that reads the data does not run in your project. It runs on shared, Google-managed infrastructure. That shared fleet is the deputy in this report.

The flaw

A network attachment is a protected resource, and the permission compute.networkAttachments.use decides who may place an interface on it. DTS never checks it the caller requesting data to me moved has the compute.networkAttachments.use on the network attachment.

The Google-managed infrastructure, the DTS connector fleet, attaches to whatever attachment a caller names, and it never asks the two questions that matter: may this caller use this attachment, and does this attachment even belong to the caller's project? The caller can name an attachment in another project, so the deputy performs its one privileged act, placing a network interface inside a VPC, for someone who could never perform it directly.

The result? An attacker can name a network attachment in another tenant. If that network attachment has been configured to use BigQuery Data Transfer, they can exfiltrate the data into the attacker-controlled project.

Diagram: the shared fleet as a confused deputy

The attacker never touches Project A. The shared fleet simply acts on the caller's instruction and carries the data back to the caller's own BigQuery.

Impact

An attacker with self-satisfiable BigQuery transfer permissions in their own project, with no relationship to the victim, can read a private database in another tenant's VPC and land the data in their own BigQuery. This was reported to Google on June 1st 2026; they confirmed it as a valid vulnerability, albeit a duplicate on July 1st and I reproduced the impact again on October 23rd, 2026. That is, a caller can read a private PostgreSQL database in a separate project, and the secret row lands in the caller's own BigQuery table when victim preconditions are satisfied, those simply being using BigQuery DTS as directed.

Databases at risk. The DTS Integration-Connector can connect to four database protocols: PostgreSQL, MySQL, Oracle, and SQL Server. Any such database reachable only from inside the victim's VPC is potentially at risk. The end-to-end exfiltration was demonstrated against a private PostgreSQL instance.

Attacker prerequisites: minimal

An attacker can grant themselves all of the IAM permissions needed, with the only barrier being knowledge of the victim's network attachment name.

  • Self-satisfiable permissions, in the attacker's own project: permission to create and run a BigQuery transfer configuration (bigquery.transfers.update), and ownership of the destination dataset. The attacker already controls that project.
  • Nothing in the victim's project: no IAM role, no compute.networkAttachments.use, no actAs, no relationship of any kind.
  • Knowledge, not access: the name of the victim's PSC network attachment, plus the private address of the target database. Both are reconnaissance facts, not permissions. They make the attack targeted rather than broad.

Victim prerequisites: the documented setup

The victim does nothing unusual. The exposure follows from using DTS exactly as documented.

  • They run DTS against a private source, and so create a PSC network attachment
  • A private, internal-only database sits behind it, reachable from inside the VPC.
  • The attachment's connection preference is exposed in either setting. ACCEPT_AUTOMATIC admits any producer by definition; it is in effect a wildcard setting. However, the other setting ACCEPT_MANUAL fails to prevent this attack due to the shared DTS connector fleet, a small pool of shared, per-region producer projects. To run their own transfers, the victim must allow-list the producer that serves their region, and that same entry then admits any other tenant's transfer on that producer. The October 2026 retest confirmed full cross-tenant exfiltration under ACCEPT_MANUAL.
  • The documentation leaves no safe path. Google's setup steps route the customer to a network attachment, but never explain the preference choice and never name a producer to allow-list. A customer who wants private connectivity is pushed to the friction-free, exploitable ACCEPT_AUTOMATIC default.

What Google said

Google reproduced the behavior (2026-06-04):

"We have successfully reproduced the behavior described here using the POC files you shared ... It is our understanding that exploitation of this behavior requires that the victim configure a network attachment between their VPC and project number 422792421300 and that the attacker has access to the network attachment name and certain data regarding the Compute Engine instance hosting the vulnerable DB (e.g. internal IP address)."

Google acknowledged the vulnerability and closed it as a duplicate (2026-07-01):

"While your report correctly identifies a valid vulnerability regarding missing authorization checks for Private Service Connect Network Attachments in the BigQuery Data Transfer Service, this exact attack vector was previously reported by another external researcher. Consequently, this submission is being closed as a duplicate of the earlier report. Unfortunately, this also excludes your report from our reward program – duplicate submissions don't qualify for reward or credit."

Google declined to mitigate it (2026-10-19):

"To answer your question regarding a mitigation: the product team has evaluated the ACCEPT_AUTOMATIC configuration is explicitly designed to automatically accept connections, there are no current plans to deploy a mitigation for this behavior by October 26th."

So Google treats the missing authorization check as expected behavior, not a defect to fix.

Disclosure timeline

Google Cloud VRP bug b/518828428.

DateEvent
2026-06-01Reported to Google Cloud VRP as b/518828428: cross-tenant private-database exfiltration through the Data Transfer Service, typed "Auth Bypass."
2026-06-04Google reproduced the behavior from the proof of concept and confirmed the preconditions: a victim attachment that admits the DTS producer, and an attacker who knows the attachment name and the database's internal IP.
2026-06-05Reported the wider exposure: DTS runs on several shared regional producers, so ACCEPT_MANUAL admits a stranger's transfer alongside the victim's own.
2026-07-01Google closed the report as a duplicate of an earlier external researcher's report, acknowledged "a valid vulnerability regarding missing authorization checks," and excluded it from reward or credit.
2026-09-29Notified Google of the planned conference disclosure and asked whether a fix would land first.
2026-10-19Google replied that disclosure is the researcher's call, and that it has no plans to mitigate: ACCEPT_AUTOMATIC works as designed.

Note, this vulnerability was first reported to Google Cloud VDP by an unknown external researcher. If that researcher wants to make themselves known, I'd love to credit them for the initial discovery.

Postscript: observed producer projects

The connector fleet presents on a network attachment as a Google-owned producer project number. Google documents none of these. Each was found empirically, by reading the accepted attachment's connection endpoints after a transfer ran. The admitting producer is per-region and rotates over time, so this is the set observed to date, not a closed list.

BigQuery Data Transfer Service:

  • 422792421300 — us-central1 / US, first seen 2026-05-30
  • 281115440399 — us-central1 / US, first seen 2026-06-05
  • 899422849968 — us-east1, first seen 2026-06-05
  • 881253560129 — us-west1, first seen 2026-06-05
  • 995923985982 — us-central1 / US, first seen 2026-10-23

The us-central1 / US location alone has shown two different numbers (281115440399, then 995923985982): the producer is not a single stable identity. All five are project numbers, not project IDs.

Companion post: "A Security Constitution, at Work." The method that surfaced this finding lives there and in the published framework.