Qubole supply chain attack exposes AWS secrets via trusted IAM roles

Between October 14 and October 26, 2026, an attacker compromised multiple AWS accounts belonging to customers of Qubole, a data lake platform owned by Idera. Cloud security firm Wiz reported that the intruder used stolen credentials from Qubole’s own AWS account to bypass security controls and access customer environments.

The breach highlights a critical vulnerability in how third-party vendors are granted access to cloud infrastructure. By leveraging trusted Identity and Access Management (IAM) roles, the attacker was able to extract sensitive secrets and copy large volumes of data without needing to crack individual user passwords or exploit application-level bugs.

What happened

Qubole operates within its customers' AWS accounts by assuming IAM roles that customers create specifically for the platform. These roles include a trust policy that allows Qubole’s AWS account to take on the role’s permissions. To validate these requests, AWS requires an External ID, a code provided by Qubole. The attacker obtained credentials for Qubole’s central AWS account and used them to send AssumeRole requests to customer accounts.

Wiz researchers noted that many of the compromised roles were unused by the customers but remained active in their configurations. Because the trust relationship was still in place, the attacker’s requests were accepted as long as they included the correct External ID. This allowed the intruder to move laterally across multiple customer environments during the two-week window.

In addition to the role-based intrusion, a separate but unlinked activity occurred between October 8 and October 11. During this period, an attacker used AWS access keys believed to be set up for Qubole to compromise a few cloud environments. Wiz has not connected this earlier event to the main campaign involving the AssumeRole abuse.

How it works

The core mechanism of this attack relied on the standard AWS cross-account access pattern. When a vendor like Qubole needs to manage resources in a customer’s account, the customer creates an IAM role with a trust policy pointing to the vendor’s account ID. The vendor then uses the AssumeRole API call to temporarily gain those permissions. The External ID is intended to prevent confused deputy problems, but it is not a secret. It is visible in CloudTrail logs and often stored in infrastructure-as-code files.

Once inside, the attacker did not need to guess passwords. They immediately began harvesting existing credentials. The intruder read environment variables from Lambda functions, pulled secrets from AWS Secrets Manager, and accessed values in the SSM Parameter Store. To verify which credentials were valid, the attacker used TruffleHog, an open-source tool for detecting secrets, to test AWS access keys, Entra ID client secrets, and Okta client credentials.

Data exfiltration was broad rather than targeted. The attacker copied data from any S3 bucket the assumed role could access. In some cases, entire buckets were downloaded in a single session. Because the roles often had broad read permissions for convenience, the attacker could access significant amounts of stored information without needing to escalate privileges further.

Key details

• Attacker Account: The malicious AssumeRole requests originated from AWS account ID 805246085872, which belongs to Qubole.
• Timeframe: The primary role-based attack occurred between October 14 and October 26, 2026.
• Indicators of Compromise: Look for AssumeRole requests from account 805246085872 with source IP addresses outside of AWS, particularly from OVH or Mullvad VPN ranges.
• Specific IAM Users: Investigate activity from IAM principal IDs AIDA3W7DIFLYOLTK63SFS and AIDAJYRRH5Y3A7AAJM2HW if sourced from non-AWS IPs.
• Tooling: The attacker used TruffleHog to validate stolen credentials, identifiable by its user agent in GetCallerIdentity calls.
• Logging Gaps: Many victims lacked S3 data events or server access logs, making it impossible to determine exactly which objects were read.

Why it matters

For engineering teams, this incident underscores the risk of dormant vendor access. Even if a service is no longer actively used, the IAM roles and trust policies often remain in place. These forgotten connections create a wide attack surface that attackers can exploit if the vendor’s central credentials are compromised. It shifts the security burden from just protecting your own perimeter to verifying the hygiene of every third-party integration.

The attack also demonstrates the limitations of External IDs as a security control. Because they are not secrets, they cannot prevent unauthorized access if the trusting account’s credentials are stolen. Engineers must treat vendor roles with the same scrutiny as internal admin roles, applying strict network conditions and least-privilege principles. Relying on default setup guides, which often grant broad S3 read access, can lead to catastrophic data loss when those roles are abused.

What you can do

• Audit CloudTrail logs from October 1, 2026, onward for AssumeRole requests from account 805246085872 originating from non-AWS IP addresses.
• Rotate all secrets, parameters, and Lambda environment variables accessible by any Qubole role that shows signs of compromise, and revoke active sessions.
• Remove any Qubole IAM roles that are no longer needed or update the trust policy to remove Qubole’s account ID if the service is discontinued.
• Add aws:SourceIp or aws:SourceVpce conditions to vendor role trust policies to restrict access to the vendor’s documented network ranges.
• Enable S3 data events or server access logs for all buckets containing sensitive data to ensure future visibility into object-level access.
• Replace the account-wide :root principal in trust policies with specific IAM principals where supported, and use unique External IDs for each role.