NEWS

Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data

Wiz says an attacker used Qubole's AWS credentials to assume roles in multiple customer accounts between Oct 14 and 26, stealing secrets and S3 data.

Dylan H.

News Desk

November 9, 2026
3 min read
Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data

Overview

An attacker broke into AWS accounts belonging to multiple customers of Qubole, a data lake platform owned by Idera, between October 14 and October 26, and stole stored secrets and data, cloud security company Wiz reported. The attacker used credentials for the AWS account that Qubole's platform uses to reach customers. How those credentials were obtained has not been disclosed.

How the Attack Worked

Qubole runs inside customers' AWS accounts through IAM roles that trust Qubole's AWS account. Each role assumption requires an External ID, but that ID is not secret and can be seen by anyone with access to the role.

  • Every malicious AssumeRole request carried a valid External ID and was accepted.
  • Most of the assumed roles were unused, but they still trusted Qubole's account.
  • In the accounts Wiz examined, the attacker read Lambda environment variables, Secrets Manager secrets, and SSM Parameter Store values, then tested stolen credentials with TruffleHog.
  • The attacker copied S3 data, sometimes downloading an entire bucket in one session.
  • From October 18 the attacker used one IAM user that Qubole's normal traffic also uses.

Separately, an attacker used customers' own AWS access keys to compromise some victims between October 8 and 11. Wiz has not linked that to the AssumeRole abuse. Wiz has not attributed the campaign to a known group and says the targeting does not match typical state-backed activity. Sentra spotted the activity in several customer environments and alerted the researchers.

Impact

Stolen material includes AWS keys, Entra ID client secrets, and Okta client credentials. Some victims lacked the S3 data event or server access logs needed to tell which objects were read. It is unclear whether the stolen credentials have been disabled or the activity has stopped. Qubole and Idera had not published a statement when The Hacker News checked.

Recommendations from Researchers

  1. Rotate every secret, parameter, and Lambda variable the affected role could reach, and revoke active sessions.
  2. Remove unneeded Qubole roles, or remove Qubole's account from trust policies.
  3. Replace the account-wide root principal in trust policies with Qubole's specific IAM principal where supported.
  4. Add an aws:SourceIp or aws:SourceVpce condition. Wiz said a source IP condition alone would have blocked every observed role assumption.
  5. Do not rely on the External ID as a control; change it and use unique values per role.
  6. Limit vendor-role access to Lambda, Secrets Manager, SSM, and broad S3 read.
  7. Alert on AssumeRole calls from vendor accounts arriving via VPNs or unfamiliar hosting providers.
  8. Use organization-wide CloudTrail and enable S3 data events or server access logs for sensitive buckets. Wiz suggests reviewing logs from October 1.

Sources