Qubole: trusted AWS account stole customer secrets

Qubole customers lost secrets and stored data in the second half of October because a role they created for the vendor still trusted Qubole’s AWS account. Cloud security firm Wiz said Monday that an attacker used credentials for that vendor account to assume roles inside multiple customer accounts between October 14 and October 26, 2026. The sessions copied secrets the roles could already read, and they copied data out of S3. Wiz has not said how the attacker obtained the Qubole credentials. Qubole and its owner, Idera, had not posted a public statement when The Hacker News checked on November 9.

Qubole is a data-lake platform. A customer who wants it inside AWS creates an IAM role and a trust policy that lets Qubole’s account assume the role. Each assumption is supposed to present an External ID that Qubole issues. In the accounts Wiz examined, the attacker’s assumptions carried that value, and AWS accepted them. AWS’s own guidance treats the External ID as a value anyone who can read the role is able to see, and CloudTrail records it in the clear. A trust policy that ends at the External ID did not stop this campaign.

Idle roles still opened the account

Wiz says most of the roles the attacker assumed were unused. The project was over. The trust was still live. A role that names Qubole’s account will accept a call from that account after the last person at the customer has stopped logging in.

Sentra saw the activity in several of its customers’ environments and brought the researchers in. In the accounts they reviewed, the sessions collected credentials the roles were allowed to read: the customers’ own AWS keys, Entra ID client secrets, and Okta client credentials. The attacker then checked which of those secrets still worked. The same sessions listed and copied S3 data from buckets the role could reach. Some sessions took an entire bucket. Wiz has not tied the campaign to a named group, and it says the targets sit outside the pattern it associates with state-backed crews.

A second window sits beside this one. From October 8 to October 11, an attacker used AWS access keys that customers had created for Qubole and reached a few of those environments. Wiz treats that access-key activity as a separate incident from the role assumptions.

Wiz has not said whether the vendor credentials have been disabled, or whether the assumptions have stopped.

What to search, and what to revoke

Any organization that has connected Qubole to AWS should read CloudTrail from October 1 forward, in every account that still holds one of those roles. The vendor account Wiz names is 805246085872. The researchers say Qubole’s ordinary calls came from inside AWS. An AssumeRole from that account with a source address outside AWS is the event to hunt.

Wiz names two IAM principals. In the accounts it examined, AIDA3W7DIFLYOLTK63SFS showed up only on the attacker’s activity. AIDAJYRRH5Y3A7AAJM2HW is shared: the attacker used it from October 18, and Qubole’s normal traffic uses it too, so a hit matters when the source address is outside AWS. Session names that start with quiam- are another marker the researchers published. They also published a short list of hosting and VPN addresses. A shared VPN address on its own is a weak signal. Pair it with the account, the principal, and the date.

CloudTrail management events record the assumption and the bucket listing. They omit which objects were read. That record lives in S3 data events or server access logs. Several victims lacked those logs, so they still cannot name the files that left.

If one of your Qubole roles was assumed, rotate every secret, parameter, and Lambda environment value that role could read, and revoke the role’s live sessions. Replacing a secret leaves a session that was already issued still valid until that session is revoked. Remove any Qubole role the business has finished with, or take Qubole’s account out of the trust policy. Where the product allows it, trust the specific principal Qubole uses, and drop a standing trust of the account root. Wiz says a condition that limits assumptions to the network ranges Qubole actually uses would have blocked every assumption the researchers saw. After an incident of this kind, change the External ID, and give each role its own value.

Read the policy that was attached when the role was born. Qubole’s setup material has included a sample that lets the role read every bucket in the account. Vendor roles also collect Lambda configuration, Secrets Manager, and Parameter Store because the integration is easier that way. Cut the role back to the buckets and secrets the job still needs. Alert when a vendor account assumes a role from a network that vendor has not used before. Turn on an organization trail for every account and region, and turn on S3 data events for buckets whose contents you would notice missing.

The customers who thought they had finished with Qubole are the ones this campaign found. A trust policy is a current credential. Delete it when the project ends.

This briefing relies on public reporting by The Hacker News and on the Wiz research that reporting describes. It does not include exploit procedures.