Qubole Cross-Account IAM Role Abuse Enables Multi-Tenant Cloud Secret Harvesting

Between October 14 and October 26, 2026, threat actors compromised Qubole's AWS management account credentials and abused pre-configured cross-account IAM trust policies to assume roles in multiple customer AWS environments via AWS STS AssumeRole. The actor harvested secrets from AWS Secrets Manager and Systems Manager Parameter Store and exfiltrated customer data. This supply-chain incident demonstrates how a single SaaS provider identity compromise can grant persistent, high-privilege access across disparate customer cloud estates through trusted IAM role relationships.

• Incident Overview: Qubole Supply-Chain Breach

  • Qubole, owned by Idera, maintained cross-account IAM roles in customer AWS accounts.
  • Attacker compromised Qubole's AWS management account credentials between Oct 14–26, 2026.
  • Abused STS AssumeRole to pivot into multiple customer environments.
  • Breach disclosed by Wiz Cloud Security Research Team.

• Attack Vector: Cross-Account IAM Role Abuse

  • Leveraged long-term AWS access keys from Qubole's management account.
  • Exploited trust policies permitting Qubole account to assume customer roles.
  • Executed AWS STS AssumeRole API calls for lateral movement.
  • Targeted AWS Secrets Manager and Systems Manager Parameter Store.
  • Utilized overly permissive IAM policies attached to assumed roles.

• Impact: Multi-Tenant Secret Harvesting

  • Multiple Qubole customer AWS accounts affected; exact count undisclosed.
  • Stored cloud secrets and customer data exfiltrated.
  • Initial vector: undisclosed compromise of Qubole AWS credentials.
  • Single provider identity breach enabled access to disparate customer estates.

• Detection: CloudTrail and Identity Monitoring

  • Review AWS CloudTrail logs for AssumeRole, GetSecretValue, and GetParameter events.
  • Monitor console authentication events originating from Qubole management account.
  • Detect anomalous STS role assumption from external SaaS provider accounts.
  • Audit cross-account trust policies referencing third-party AWS account IDs.

• Remediation: Reduce Cross-Account Blast Radius

  • Rotate all long-term AWS credentials and IAM keys for SaaS provider accounts.
  • Enforce least privilege on cross-account role trust policies and attached permissions.
  • Implement external ID and condition keys to restrict role assumption.
  • Regularly audit and remove unused or overly permissive SaaS IAM roles.

• Conclusion: SaaS-to-Cloud Supply-Chain Risk

  • Incident highlights persistent IAM access as a critical supply-chain vector.
  • CISOs must inventory all third-party cross-account role relationships.
  • Continuous monitoring of STS and secret access APIs is essential for early detection.