Identity and Secure Access

Qubole supply chain attack: vendor's trusted AWS roles abused to exfiltrate secrets and customer account data

On November 9, 2026, Wiz detailed compromises across AWS customer accounts of the Qubole platform. Between October 14 and 26, the threat actor assumed roles trusted by customers for Qubole integration, reading secrets – including AWS keys, Entra ID application credentials, and Okta credentials – and copying data from S3.

  • SourceWiz
  • Source publicationNovember 9, 2026
  • TypeThreats and incidents

What happened

Qubole, an Idera-owned data lake platform, operates in customer AWS accounts via IAM roles that trust the vendor’s account. According to Wiz, the attacker possessed credentials to Qubole’s own AWS account and used it to assume customer roles (AssumeRole). Every request included a valid External ID and succeeded. Most compromised roles were dormant yet still trusted Qubole’s account. How the attacker initially accessed the vendor’s account was not disclosed.

Across investigated accounts, the attacker accessed Lambda environment variables, Secrets Manager, and Parameter Store, validating retrieved credentials with TruffleHog. Harvested credentials included AWS user access keys, Entra ID app secrets, and Okta app credentials – belonging to the victim organizations, not the vendor. S3 buckets accessible to the roles were exfiltrated, occasionally copying entire buckets in a single session.

Activity was uncovered by Sentra across several customer environments. Separately, between October 8 and 11, an actor leveraged AWS access keys that researchers assess customers had created for Qubole – Wiz did not correlate this with the role-assumption activity. According to The Hacker News, neither Qubole nor Idera had issued a public statement by publication time. The number of affected customers remains undisclosed.

Key findings

  • Role assumption: October 14–26, 2026; separate access-key use: October 8–11, 2026.
  • External ID did not prevent exploitation – AWS does not treat it as a secret, and CloudTrail logs it in plaintext.
  • Exfiltrated: Secrets from Lambda, Secrets Manager, and Parameter Store, along with S3 data; secrets included AWS keys, Entra ID app secrets, and Okta credentials.
  • According to Wiz, a simple source-IP condition in the trust policy would have stopped every observed role assumption.
  • No attribution; Wiz released IOCs to query logs back to October 1.

Why it matters

SafeWave CommentaryThe attacker did not break through customer defenses – they entered through doors customers opened for a vendor and neglected to close when no longer needed. Trusted integration roles, keys in environment variables, and app secrets are machine identities unshielded by MFA, and in this campaign, they pivoted deeper into Entra ID, Okta, and S3 data. Under NIS2 and Poland’s KSC Act, this is also a supply chain security matter. Recommended actions: Inventory all IAM roles trusting external accounts and revoke dormant ones; scope trust to specific vendor principals and enforce source-IP or VPC-endpoint conditions; strip integration roles of read access to secrets, parameters, and broad S3 resources; rotate secrets and revoke active sessions immediately after a vendor incident; mandate organization-wide CloudTrail and S3 data events for sensitive buckets. We covered a similar workload identity theft pattern in the Hugging Face attack. Explore more under Identity and Secure Access.