Facts checked Nov 9, 2026
An attacker used credentials from an AWS account associated with Qubole to assume customers' Qubole roles and download S3 data, Wiz said. A valid External ID did not stop it: Qubole customers should hunt CloudTrail and cut or pin that trust today; every AWS customer should delete idle vendor roles and pin the rest.
What happened
The activity ran between Oct. 14 and Oct. 26, 2026, using credentials from account 805246085872, which Wiz observes Qubole's platform using. Sentra spotted it across several of its customers and told Wiz; Mandiant also worked on it. Wiz gives no count. Sentra says more than a dozen organizations were hit, and elsewhere "dozens". No source says how the attacker got the credentials, and Qubole has not said whether its own systems were compromised.
The attacker enumerated storage, compute, databases, KMS and IAM, then collected secrets from Lambda environment variables (GetFunctionConfiguration), Secrets Manager and SSM Parameter Store. Sentra adds EC2 user data. The attacker tested found keys with TruffleHog: AWS keys, Entra ID and Okta secrets. It also read S3 objects, sometimes whole buckets in one session.
Wiz said every AssumeRole request it attributed to the attacker included an External ID, and every one succeeded. AWS says the External ID is not a secret; it exists to prevent the confused-deputy problem, so it cannot stop a vendor's stolen keys. Most of the roles were not otherwise in use: the trust, we infer, outlived the integration.
Who is affected
Customers with a Qubole IAM role, including unused ones. Wiz also said customer-owned access keys it believes were made for Qubole integrations were all tested within one hour on Oct. 8, and a few environments were compromised. Wiz has not linked it to the role activity; access-key users should check too.
What to do now
Cloud security, today: hunt CloudTrail from Oct. 1, 2026 in every account holding a Qubole role for:
- AssumeRole from 805246085872 with a non-AWS sourceIPAddress
- any activity by principal AIDA3W7DIFLYOLTK63SFS
- activity by AIDAJYRRH5Y3A7AAJM2HW only from non-AWS IPs, which also carries legitimate traffic
- session names starting "quiam-"
- the TruffleHog user agent alongside the IPs below, in CloudTrail and Entra or Okta sign-in logs
From Oct. 15, most activity came from OVH 57.129.54[.]120. Wiz also lists Mullvad exits such as 45.83.220[.]211; shared VPN exits prove nothing alone. Wiz's post has the full IOC and user-agent tables.
If a role was assumed, same day: Preserve logs, then, in our recommended order: cut or pin the trust first, because AWS says session revocation only denies credentials issued before it and a fresh AssumeRole still works. Then revoke sessions, then rotate every secret, parameter, Lambda variable and EC2 user-data credential the role could read.
CloudTrail management events show the role assumption and bucket listing but not which objects were read. For that, use S3 data events or server access logs. Without them, Sentra says each unlock of an encrypted file is logged with the file's name. We read that as KMS Decrypt events in CloudTrail, which AWS says log the bucket, not the object, when S3 Bucket Keys are on. SSE-S3-only objects leave no such trail.
Platform team, this week: delete idle roles; replace the :root principal with the vendor's specific principal; add aws:SourceIp or aws:SourceVpce limits to the vendor's published ranges (aws:SourceIp is absent on VPC endpoint calls) and ask vendors that publish none; remove Lambda, Secrets Manager, SSM and broad S3 read; rotate the External ID with the vendor. Wiz said a source IP condition alone would have blocked every assumption it saw. Ensure an organization trail covers every account and region, with data events on sensitive buckets.
What is not known yet
As of 22:47 UTC on Nov. 9, we found no statement from Qubole or Idera on qubole.com, status.qubole.com or idera.com/news, and neither did The Hacker News. It is unknown whether the two IAM users are disabled, so do not assume the trust is safe.
