What the Qubole AWS Access Breach Shows About Trusted Cloud Integrations

Cloud security firm Wiz says the Qubole AWS access breach began when a threat actor used credentials from an AWS account associated with Qubole. It reached the AWS accounts of multiple Qubole customers, read their secrets and took data from their S3 buckets, Wiz says. Wiz worked with Google’s Mandiant on the investigation, published on 9 November 2026.

The case turns on a setup almost every cloud customer has somewhere: a trust relationship that lets an outside vendor’s AWS account act inside a customer’s own account. This is what Wiz calls cross-account access, and it is the subject of this explainer.

What Cross-Account AWS Access Is, and Why Qubole Has It

Many software-as-a-service platforms work inside a customer’s AWS account. Data-processing platforms like Qubole are one example. They use cross-account IAM roles instead of asking for a customer’s AWS password or access keys.

During onboarding, the customer creates a role in its own account. Its trust policy names the vendor’s AWS account and lets that account call the AWS action sts:AssumeRole. A shared value called an External ID usually gates the trust policy as a second check.

Once that role exists, the vendor’s own AWS identity can call AssumeRole with the role’s address and the External ID. AWS then hands back temporary credentials scoped to whatever that one role can do. The customer never shares a long-lived password or key.

The arrangement is meant to be safer than the alternative, not a loophole. That is what makes this case worth explaining. A trust relationship with a vendor is a normal part of third-party risk. It stays a risk for as long as the role exists, not only while the vendor actively uses it.

The Qubole AWS Access Breach, 14 to 26 October 2026

Wiz’s CIRT team says a threat actor used IAM credentials from an AWS account associated with Qubole’s platform. It called AssumeRole against integration roles inside customer accounts. Every call Wiz attributed to the actor carried a valid External ID, and every one succeeded, because the customers’ own trust policies were still in place.

Wiz says most of the roles the actor assumed were not otherwise in active use. In most affected environments, the actor’s requests were the only role-assumption activity from the vendor’s account that Wiz saw all October. The trust policies were still in place, so the requests succeeded, Wiz says.

Wiz says its first observed activity was on 14 October. On 18 October, the actor began using a second IAM user from the same account, which also carries legitimate Qubole platform traffic. Wiz does not say how the actor first obtained these credentials.

Separately, Wiz describes activity between 8 and 11 October 2026 that it has not been able to link to the role-assumption activity. An actor used AWS access keys that belong to the customers themselves, which Wiz believes were originally set up for Qubole integrations. The actor tested all of these keys within a single hour. In a small number of cases, it went on to compromise the customer’s own cloud environment.

What the Threat Actor Did Inside Customer Accounts

Once a role was assumed, Wiz says the actor enumerated broadly: storage buckets and tables, compute instances, databases, and IAM roles and keys. It then went looking for credentials stored inside AWS itself. It read Lambda function configuration, which can hold environment variables, plus Secrets Manager secrets and SSM Parameter Store values.

Wiz says the actor used the open-source tool TruffleHog to check whether the credentials it found actually worked. It called AWS’s identity-check API with discovered access keys, signed in to Microsoft Entra ID with discovered service-principal secrets, and requested OAuth tokens with discovered Okta client credentials.

These checks confirm a credential is live. They do not by themselves move or copy data.

For S3 data, Wiz describes a consistent pattern: assume the role, list what buckets it can reach, inspect the objects inside, then download them. Wiz says the actor looked opportunistic rather than targeted. It read from whatever a role could reach, and in some cases downloaded an entire bucket in one sitting.

What Is Confirmed, and What Is Still a Claim

Wiz’s own post is the primary account of this activity. Qubole describes itself as “an Idera Inc company” on its own About page.

Brandefense checked Qubole’s blog, its status page, the news page of its parent, Idera, Inc., and AWS’s security bulletins page. As of 10 November 2026, neither Qubole nor Idera had published a notice about this activity. The newest AWS bulletins, dated through 9 November 2026, do not mention it.

Wiz says it has not tied this campaign to any other publicly reported activity. It says the targeting looked opportunistic rather than matching typical state-linked priorities. Wiz also says it has no direct insight into the actor’s motive or what it intends to do with the data. Neither point should be read as more settled than Wiz itself states it.

How to Check Your Own AWS Account

If your organization has ever connected an AWS account to Qubole, Wiz’s advice is to review CloudTrail from 1 October 2026 onward. Do this in every account that holds an integration role for Qubole, rather than assuming the activity stopped at the one account that first comes to mind.

Wiz’s starting points are role-assumption events coming from the AWS account Wiz associates with Qubole’s platform, through a network address that is not AWS’s own infrastructure. A second starting point is any activity at all from an integration role that otherwise has no legitimate recent use.

For every matching session, Wiz says to review what it did next. Look especially at Secrets Manager, SSM Parameter Store, Lambda and S3, since that is where the actor went looking for more credentials and data.

What Changes for Defenders

Wiz’s recommendations, in Brandefense’s own words, start with an inventory. This kind of review is part of ordinary cloud security hygiene, not a one-time response to this case alone. List every IAM role whose trust policy names an external AWS account, and what each one can reach. A role nobody uses anymore is still a door if its trust policy is still in place.

Wiz says to remove trust for integrations that are no longer active, rather than leaving them live just in case they return. Where a vendor supports it, Wiz also recommends narrowing the trusted principal below the account’s root and adding a source-network condition. A correct External ID from an unexpected network is a strong warning sign on its own.

Wiz also treats the External ID as something to rotate after an event like this one. It is logged in plaintext in CloudTrail and was never designed to be a secret.

Finally, Wiz’s advice is to limit what an integration role can read, and to make sure logging actually covers S3 object reads, not just the higher-level role-assumption event. Several of the environments Wiz studied could not fully answer what had been taken, simply because the right logs were not turned on.

Wiz also recommends alerting when a vendor role is assumed from a network the vendor has never used, such as a VPN or a hosting provider. Brandefense’s assessment: any organization that still trusts Qubole’s integration role, used or not, should review and tighten that trust policy before assuming the risk has passed.

Which vendor roles exist, and what they can reach, is exactly the kind of ongoing question Third-Party Risk Management is built to keep current. A one-time inventory goes stale; a continuously scored one does not.