As reported by The Hacker News, attackers obtained credentials for Qubole's AWS platform account and used them to assume IAM roles across multiple customer environments between October 14 and October 26, 2026. The breach — investigated by Wiz with initial detection by Sentra — exposes a systemic weakness in how SaaS-to-customer trust relationships are managed in the cloud.

Cloud Security Alert: As reported by The Hacker News, attackers obtained credentials for Qubole's AWS platform account and used them to assume IAM roles across multiple customer environments between October 14 and October 26, 2026.

The Core Problem: Trust Without Lifecycle Management

The attack didn't exploit a software vulnerability. It exploited a trust architecture pattern that thousands of SaaS integrations depend on daily. Qubole's data lake platform requires customers to create IAM roles that trust Qubole's AWS account (805246085872), allowing Qubole to assume those roles via AssumeRole with a matching External ID. This is standard AWS cross-account access design.

What made this dangerous was that many of the assumed roles were unused — customers had stopped using Qubole but never revoked the trust policy. The roles sat dormant, still trusting Qubole's account, still carrying whatever permissions they'd been granted. When the attacker obtained Qubole's credentials, every one of those stale roles became an open door.

The External ID is not a secret. AWS's own documentation states that anyone with access to the role can view it. The security model relies entirely on the confidentiality of the trusted account's credentials — a single point of failure.

What the Attacker Did

Once inside customer environments, the attacker followed a methodical credential harvesting playbook:

The Core Problem: Trust Without Lifecycle Management
Read environment variables from Lambda functions
Pulled secrets from AWS Secrets Manager
Read values from SSM Parameter Store
Ran discovered credentials through TruffleHog for validation
Exfiltrated S3 bucket data — sometimes downloading entire buckets in a single session

Compromised credentials included AWS access keys, Entra ID client secrets, and Okta client credentials — meaning the blast radius potentially extends well beyond the initial AWS accounts into identity providers and downstream SaaS systems.

Why This Matters Beyond Qubole

This isn't a Qubole-specific problem. Any SaaS vendor that uses AWS cross-account trust is subject to the same risk surface. The pattern is ubiquitous: data platforms, observability tools, security scanners, and CI/CD services all frequently require customers to create IAM roles that trust the vendor's AWS account. If that vendor is compromised, every customer role that still trusts them becomes a pivot point.

The industry has been slow to adopt the principle of least trust in SaaS integrations. Organizations provision roles, grant broad permissions, and then forget them. There is no automatic expiration on IAM trust policies. No nudge to review. No alert when a role hasn't been assumed by its intended principal in 90 days.

Shield53 Recommendations

Immediate Actions

  • Audit CloudTrail logs from October 1 onward for AssumeRole calls sourced from AWS account 805246085872 (Qubole's platform account). Flag any requests originating from IP addresses outside AWS's known ranges.
  • Revoke and rotate all secrets that may have been exposed: Lambda environment variables, Secrets Manager entries, SSM Parameter Store values, AWS access keys, and any third-party credentials (Entra ID, Okta) stored in those locations.
  • Review all IAM roles with trust policies referencing Qubole's account. If Qubole is no longer in use, delete the role entirely. If it is in use, narrow permissions to the minimum required and consider adding session policy conditions.

Strategic Hardening

  • Implement automated IAM role lifecycle management. Use tools like AWS IAM Access Analyzer or open-source alternatives to detect roles with active trust policies that haven't been assumed in a defined period. Quarantine or auto-delete stale roles.
  • Apply permission boundaries to SaaS-trusted roles that restrict access to specific resources, preventing broad S3 enumeration or secrets store access even if the role is compromised.
  • Deploy CloudTrail anomaly detection that alerts on AssumeRole calls from known SaaS vendor accounts originating from unexpected IP ranges or geographies.
  • Inventory all third-party SaaS trust relationships in your AWS environment. For each, document the vendor, the account ID trusted, the External ID, the permissions granted, and the business owner. Review quarterly.
  • Segregate SaaS-accessible roles into dedicated AWS accounts with minimal blast radius, rather than granting access within production accounts containing sensitive data.

Qubole and Idera had not issued public statements at the time of reporting. The question of how the platform account credentials were obtained remains unanswered — but for defenders, the origin matters less than the exposure. The trust was there. The roles were waiting. The attacker simply used what was already available.