Qubole AWS Cross-Account Trust Abuse: Attacker Assumed Customer Roles — Prepare Now

Wiz, working with Sentra and Mandiant, reported on 9 November 2026 that a threat actor used IAM credentials from an AWS account associated with Qubole between 14 October and 26 October 2026 to assume IAM roles that customers had created to trust Qubole. Once inside multiple victim AWS environments, Wiz says, the actor enumerated resources, collected stored secrets, copied S3 data, and tested additional credentials it found.

Qubole, described on its About page as "an Idera Inc company," is a data lake platform. The access came through a vendor account that customer roles were configured to trust. Wiz has not disclosed how those credentials were obtained, whether they have been disabled, or whether the activity has stopped. There is no CVE or vendor patch, and unused or deprecated Qubole trust remains in scope. As of a recheck on 11 November 2026 at 07:38 Asia/Jerusalem UTC+2, Qubole and Idera had published no statement on the websites checked, and AWS had published no security bulletin on this activity. In a statement added to The Register's article on 10 November at 18:17 Asia/Jerusalem UTC+2, an AWS spokesperson said that "AWS services were not compromised by this issue and operated as designed," and that threat actors "used credentials associated with a third-party provider to access some AWS customers’ accounts by assuming IAM roles those customers had configured to trust that provider."

Technical Information

Wiz says the malicious sts:AssumeRole calls came from account 805246085872, which it observes Qubole's platform using after customers created a trusting IAM role, usually gated by an External ID. Every request Wiz attributed to the actor included an External ID and succeeded. An External ID is not a secret — AWS and Wiz note it is often visible in the role and logged in plaintext in CloudTrail — and it did not by itself stop this activity.

Wiz says the actor then collected credentials from Lambda environment variables, Secrets Manager, and SSM Parameter Store, and used TruffleHog to test the victims' own AWS keys, Entra ID client secrets, and Okta client credentials. It also listed S3 buckets and downloaded objects, sometimes entire buckets in one session. CloudTrail management events record role assumption and bucket listing, not object reads, which need S3 data events or server access logs; Wiz says several affected environments lacked them.

Most roles the actor assumed were not otherwise in use: in a majority of environments Wiz observed, those were the only October AssumeRole calls from the vendor account. Wiz told The Register that many organizations had left trust policies active after deprecating the platform.

Wiz declined to tell The Register how many organizations were affected. Sentra, which spotted the activity, said more than a dozen were impacted in the campaign it investigated and elsewhere that "dozens of Qubole customers were impacted"; those are Sentra's figures, not an independently confirmed total. Sentra reported zero write actions in the activity it investigated. Wiz does not make a "no writes" claim or attribute a motive.

Wiz also described separate 8–11 October 2026 activity using customer-owned AWS access keys it believes were created for Qubole integrations. In a small number of cases, Wiz says that actor compromised the victim's cloud environment. Wiz has not linked that activity to the AssumeRole campaign; review any such long-lived keys as well. Wiz identified an ISO hosted on an actor-used OVH address but has not identified any deployments and cannot confirm if or how it has been used.

Affected Product Versions

Check any AWS account that has or had a Qubole integration role.

Workaround and Mitigation

There is no official Qubole fix. Review CloudTrail from 1 October 2026 in every account that holds a Qubole integration role, using the Wiz indicators below — especially AssumeRole from account 805246085872 with a non-AWS source address (legitimate platform traffic Wiz observed came from AWS infrastructure) and later Secrets Manager, SSM, Lambda, and S3 activity.

If a role was assumed, rotate every secret, parameter, and Lambda environment variable that role could read, and revoke the role's active sessions. Rotating a credential does not end temporary sessions already issued.

Remove unused Qubole roles, or drop Qubole's account from their trust policies. Where supported, replace account-wide :root with the specific principal Qubole uses, and add aws:SourceIp or aws:SourceVpce conditions limited to the vendor's documented ranges. Wiz said a source IP condition alone would have blocked every role assumption it observed. Rotate the External ID with the vendor and do not treat it as the only control. Enable an organization trail plus S3 data events or server access logs for sensitive buckets. AWS's statement to The Register recommends regularly reviewing cross-account IAM roles, removing access for integrations no longer in use, granting least-privilege permissions, and adding conditions such as source IP restrictions to role trust policies. Do not assume the vendor credentials have been disabled until Qubole or Idera says so publicly.

Indicators of Compromise

The indicators below are published by Wiz as hunting leads, not standalone proof. Mullvad addresses are shared VPN exits, and principal AIDAJYRRH5Y3A7AAJM2HW also carries legitimate Qubole traffic from AWS infrastructure, so treat it as suspicious only from a non-AWS source address.

What to Ask Your Suppliers Today

This is a third-party trust problem: roles customers configured to trust a provider stayed usable after the provider's credentials were misused. Ask any supplier, managed service provider, or data-platform partner that runs AWS workloads for you, including former Qubole users:

1. Do you use Qubole now, or did you in the past? Include roles left after the platform was deprecated.
2. Do any IAM roles still trust AWS account 805246085872? Owner, roles, and whether unused trust has been removed.
3. Have you reviewed CloudTrail from 1 October 2026 for AssumeRole activity from that account? Non-AWS addresses, Wiz principal IDs, quiam- session names, and follow-on secrets and S3 activity. Was a role assumed?
4. If a role was assumed, have you rotated every secret, parameter, and Lambda environment variable that role could read, and revoked active sessions? Also review long-lived AWS keys issued for Qubole (separate 8–11 October finding).
5. Have you tightened remaining vendor trust? :root narrowed, source-IP or VPC-endpoint condition in place, External ID rotated with the vendor.

Track incomplete answers to closure. These are qualitative TPRM follow-ups, not an internet-scale prevalence claim.

Need help identifying which suppliers still trust Qubole in AWS, reviewing whether those roles were assumed, and tracking removal and rotation plans? Our team can help you prioritize them and track their answers. Talk to an expert

Sources

• Wiz, 9 November 2026 — published 09:56:32-05:00 (18:56 Asia/Jerusalem UTC+2).
• Sentra — published 9 November; victim and write-action figures are Sentra's.
• The Hacker News, 9 November 2026 — credential origin undisclosed; no vendor website statement when THN checked.
• The Register, 9 November 2026 — published 21:59 Asia/Jerusalem UTC+2, 9 November; updated 10 November at 18:17 Asia/Jerusalem UTC+2 with the AWS statement quoted above. Wiz declined a victim count.
• Qubole: About Us and Idera homepage — "an Idera Inc company"; Idera's product nav lists Qubole. Checked 10 November 2026, 10:02 and rechecked 11 November 2026, 07:38 Asia/Jerusalem UTC+2; no incident statement.
• AWS Security Bulletins — same check; no Qubole bulletin found.
• AWS Security Blog: External ID — confused-deputy control, not a secret.