If You Ever Connected Qubole to AWS, Check CloudTrail From October 1. Someone Used Qubole's Own AWS Account to Assume Customer Roles and Read Secrets and S3 Data
If you have ever connected Qubole to an AWS account, even if you no longer use it, search CloudTrail in that account from October 1, 2026 onward for AssumeRole calls made by AWS account 805246085872 that came from an address outside AWS. Wiz reports that an attacker used the account Qubole's platform uses to reach customers, and that the requests succeeded because the customer roles still trusted it.
What has been reported
The primary source is Wiz's analysis, "Qubole cross-account access abused in the wild." The Hacker News reported it on November 9, 2026. Wiz says Sentra saw the same activity in customer environments and alerted them.
Between October 14 and October 26 an attacker assumed integration roles in multiple customer AWS accounts. Wiz does not give a count of victims.
The roles trust the vendor's account root, gated only by an External ID. Every request carried a valid External ID, and every one was accepted. Most of the abused roles were unused but still trusted Qubole.
Inside accounts Wiz examined, the attacker listed storage, compute, databases and identity services, then read Lambda environment variables, Secrets Manager secrets and SSM Parameter Store values. It tested the credentials it found with TruffleHog. Those included AWS access keys, Entra ID client secrets and Okta client credentials.
The attacker also read and copied S3 data, in some cases whole buckets.
Separately, from October 8 to 11, someone tested customers' own AWS access keys that Wiz believes were created for Qubole integrations. All were tried within one hour on October 8. Wiz has not linked this to the role abuse.
Wiz does not tie the activity to a known group. How the attacker obtained credentials for Qubole's account has not been disclosed. Wiz's page contains no statement from Qubole or its owner Idera, and The Hacker News says none had been published when it checked. We have not found one either, and we do not know whether the credentials have been disabled.
Why the usual control did not stop it
External ID is meant to prevent one customer's confusion from being used against another. It is not a secret. It appears in plain text in CloudTrail and is often kept in vendor tools and infrastructure-as-code files. Wiz's point is that when the vendor's own account is the thing that is compromised, a trust policy that says "this whole account may assume this role" will accept the attacker. Wiz says a source IP condition alone would have blocked every role assumption it saw, because the attacker came from VPN and VPS addresses rather than Qubole's usual ranges.
What to do
In every AWS account that has a Qubole role, search CloudTrail from October 1 for AssumeRole calls from account 805246085872 that come from non-AWS source addresses. Also search for the IAM principal ID AIDA3W7DIFLYOLTK63SFS, which Wiz says only the attacker used in the accounts it examined, and for role session names that start with quiam-, such as quiam-enum.
A second principal, AIDAJYRRH5Y3A7AAJM2HW, was used by the attacker from October 18 but also appears in normal Qubole traffic. Investigate it only when the source is outside AWS.
If a suspicious session happened, rotate every secret, parameter and Lambda environment variable that role could read, and revoke its active sessions. Rotating a credential does not end sessions already issued.
Review what each suspicious session did afterward: Secrets Manager, SSM, Lambda and S3 first. Check your identity provider sign-in logs for the Entra ID and Okta credentials the role could reach.
Remove roles you do not use. For ones you keep, replace the account-wide :root principal with the specific principal the vendor documents, and add an aws:SourceIp or aws:SourceVpce condition limited to the vendor's published ranges.
Treat External ID as non-secret. Rotate it with the vendor after any incident and use a different value per role where the vendor supports it.
Turn on an organization-wide trail across all accounts and regions, and enable S3 data events for sensitive buckets. The Hacker News reports that several victims lacked the logs needed to investigate.
Do the same inventory for every other vendor with a role in your accounts. This pattern is not specific to Qubole.
Indicators, with the caveats Wiz gives
Wiz lists 57.129.54[.]120 and 2001:41d0:70d:7800:: (OVH hosting), and 45.83.220[.]211, 185.209.199[.]73 and 89.37.63[.]175, which Wiz places with Mullvad VPN. The VPN addresses are shared by other users, so a match alone is not proof. Wiz also lists a file, sso_agent.iso, hosted on the main OVH address, with SHA-256 65f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4. Wiz says it appears designed for remote booting and that Wiz has not seen it deployed. The user agents Wiz names (several Boto3 and AWS CLI versions, TruffleHog) are suspicious only alongside the other indicators.
What is not known
The number of victims. How the vendor account's credentials were obtained. Whether the activity has stopped. What Qubole and Idera have told their customers. Whether the October 8 to 11 key testing is related.
How we know, and how we checked
We read the Wiz analysis and The Hacker News report in full. They agree on the dates, the trust policy details and the indicators. They are not independent: the news report is built on the Wiz research. We did not read Qubole's or AWS's documentation pages directly. We add nothing to our feed from this post. The addresses are VPN and VPS ranges that other people use, and we do not block on a shared VPN address from a single vendor report.
Sources
Wiz, "Qubole cross-account access abused in the wild." The Hacker News, "Hackers Exploit Qubole's Trusted AWS Access to Breach Customer Accounts and Steal Data," November 9, 2026.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Comments