---
title: "Stolen Qubole credentials opened AWS accounts at more than a dozen firms via old roles"
summary: "What Wiz and Sentra reported on 9 November about 14 to 26 October: how a leftover cross-account role let a vendor’s stolen credentials in, and the check that finds yours."
url: https://www.thetechbag.com/blog/qubole-credentials-aws-accounts-trust-roles
format: Note
desk: "Security"
area: "Identity & access"
region: Global
published: 2026-11-10
facts_checked: 2026-11-10
author: TechBag (The TechBag Journal)
tags: ["Qubole","AWS IAM","cross-account role","trust policy","External ID","AssumeRole","third-party risk","supply chain","CloudTrail","S3","Wiz","Sentra"]
cover: https://www.thetechbag.com/blog/covers/qubole-credentials-aws-accounts-trust-roles.png
---

# Stolen Qubole credentials opened AWS accounts at more than a dozen firms via old roles

*What Wiz and Sentra reported on 9 November about 14 to 26 October: how a leftover cross-account role let a vendor’s stolen credentials in, and the check that finds yours.*

Note · Security · Identity & access · By TechBag · Published 2026-11-10 · Facts checked 2026-11-10 · Canonical: https://www.thetechbag.com/blog/qubole-credentials-aws-accounts-trust-roles

Between 14 and 26 October an attacker holding credentials from an AWS account linked to Qubole, a big-data platform, used them to enter the AWS accounts of more than a dozen organisations, through access those organisations had once given Qubole.[1][2] Most of those roles were not otherwise in use, and in some cases whole S3 storage buckets were downloaded.[1] No victim has been named, and neither Wiz nor Sentra, the two security companies that reported it on 9 November, says how the credentials were obtained.[1][2]

## How a cross-account role works, and where this one failed

Software that works inside a customer’s AWS account usually gets in through a role. The customer creates the role and writes a trust policy naming the vendor’s AWS account; the vendor then asks AWS for temporary credentials to act as that role.[1][3] Nothing about the arrangement expires when the customer stops using the vendor.

**Figure: A forgotten cross-account role accepts anyone who holds the vendor’s credentials and External ID**

*How a third-party AWS role is set up and how it was used, 14–26 October*

1. 01The customer creates a roleIts trust policy names the vendor’s AWS account and, usually, an External ID.
2. 02The vendor assumes itIt calls sts:AssumeRole and receives temporary credentials limited to that role.
3. 03The customer leavesThe role stays. Sentra says Qubole’s had been dormant since the spring.
4. 04Stolen credentials arriveThe same call, with the right External ID, from a VPN and a rented server. Every request succeeded.

Source: Wiz; Sentra; AWS IAM documentation · as of 9 November 2026

The External ID was no protection here. Every request Wiz tied to the attacker carried one, and every one succeeded; AWS itself says it “does not treat the external ID as a secret”.[1][3] In most of the environments Wiz saw, the attacker’s were the only role assumptions from Qubole’s account all October.[1]

Once inside, the attacker listed what each role could reach and read credentials from Lambda settings, Secrets Manager and Parameter Store, then tested them against AWS, Entra ID and Okta.[1] Sentra counted about 100 passwords and keys read in seven minutes, and no write actions at all.[2] Both companies say a single condition limiting the role to Qubole’s own network addresses would have blocked every login they saw.[1][2]

## The check to run this week

**Find the roles.** In every AWS account you hold, list the roles that trust Qubole’s account (the ID is Wiz’s):

`aws iam list-roles --query "Roles[?contains(to_string(AssumeRolePolicyDocument), '805246085872')].RoleName" --output text`

For every vendor at once rather than one, an IAM Access Analyzer external-access analyzer reports roles shared outside your account.[4]

**See when each was last used.** The listing call does not return this, so ask for each role:[5]

`aws iam get-role --role-name ROLE_NAME --query Role.RoleLastUsed`

AWS only reports the trailing 400 days, so an empty answer does not prove a role has never been used.[6]

**Remove what you no longer use.** Delete the role or take the vendor out of its trust policy.[1] For vendors you keep, narrow the trusted principal and add an `aws:SourceIp` condition.[1]

**If you ever used Qubole, read the logs.** Wiz advises reviewing CloudTrail from 1 October for `AssumeRole` events from that account where the source address is not an AWS one. If you find any, rotate every secret the role could read and revoke its active sessions, because rotating a credential does not end temporary sessions already issued.[1] CloudTrail’s management events will not show what was read from S3: object reads need data events or server access logs, and in several affected environments the missing logs meant responders could not tell which files had gone.[1]

How we did this

Figures as of 10 November 2026, 7:30pm IST

Everything about the campaign is from Wiz and Sentra, who both sell cloud security products and investigated it with Mandiant; neither post carries a response from Qubole and we found none on its website. Sentra uses both “more than a dozen” and “dozens”: we use the lower figure, which is its own count of organisations, and Wiz says only “multiple”. Wiz also reports a separate use of customer-owned keys on 8–11 October, which it has not linked to this activity and which we leave out of the dates above. How AWS roles, External IDs and role-usage reporting work is from AWS’s documentation. We checked the syntax of the two commands against sample data, not a live account.

Spotted an error? Write to us; corrections are published at the foot of the piece.

Sources

1. [Wiz, Trusted by Default: Qubole Cross-Account Access Abused in the Wild](https://www.wiz.io/blog/qubole-cross-account-access-abused-in-the-wild) — 9 November 2026
2. [Sentra, One Stolen Vendor Key, Every Customer’s Data Exposed: Inside the Qubole Supply Chain Attack](https://sentra.io/blog/breaches/inside-the-qubole-supply-chain-attack) — 9 November 2026
3. [AWS, IAM User Guide: Access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) — undated page
4. [AWS, IAM User Guide: What is IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) — undated page
5. [AWS, IAM API Reference: ListRoles](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoles.html) — undated page
6. [AWS, IAM API Reference: RoleLastUsed](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RoleLastUsed.html) — undated page

**Disclosure.** TechBag is a software reseller: it earns a margin when a reader buys through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view.

**Read this next:** [Amadeus breach hit at least ten airlines through one booking system](https://www.thetechbag.com/blog/amadeus-breach-airlines-one-supplier) — Another supplier as the way in: how one booking supplier exposed records at ten airlines, what was read, and why the counts cannot be added.

Go deeper on TechBag

- [Privileged access management guide](https://www.thetechbag.com/browse/identity-access/privileged-access-management) — controls on the standing access a vendor keeps inside your cloud
- [Identity governance guide](https://www.thetechbag.com/browse/identity-access/identity-governance) — reviews of who, including a former supplier, still holds access
- [Cloud workload security guide](https://www.thetechbag.com/browse/security/cloud-workload-security) — tools that map which outside accounts can reach your cloud