Attackers used compromised credentials associated with Qubole’s AWS account to assume customer-managed integration roles, inspect cloud environments and steal secrets and data, according to findings published by Wiz on November 9, 2026. The activity exploited a trusted cross-account access arrangement used by the cloud data processing platform.
Qubole integrations use cross-account AWS Identity and Access Management (IAM) roles to access compute and storage in customer environments. This approach avoids requiring customers to provide Qubole with long-lived AWS access keys. But organizations that left integration roles and their trust policies active after they stopped using the platform remained exposed to access through those roles, Wiz said.
Wiz described the incident as a broad, opportunistic supply-chain campaign affecting multiple customer environments. The company did not disclose how many organizations were affected. Its researchers said attackers enumerated resources, harvested secrets and transferred data after successfully assuming integration roles. They have not attributed the campaign to a particular threat group or said how the stolen information was used.
Activity began with role assumption
Wiz traced the malicious activity to October 14, when credentials linked to Qubole’s AWS account were used to call AWS Security Token Service’s
API. The call obtained temporary credentials for customer-managed integration roles. The requests came from AWS account 805246085872 and used IAM user ID AIDA3W7DIFLYOLTK63SFS, according to Wiz analysts Zack Morrow, Sean Johnstone and Benjamin Read.
The researchers said the activity continued on October 15. On October 18, the attackers began using a second IAM user from the same Qubole account. Wiz’s incident response team had not observed the first identified IAM user being used for activity unrelated to this threat actor in the affected environments.
After gaining access, the attackers probed AWS services and searched for credentials and other sensitive values. Wiz said they targeted secrets stored in AWS Lambda, AWS Secrets Manager and AWS Systems Manager Parameter Store. They also used TruffleHog to test AWS credentials belonging to victims, looked for Microsoft Entra ID secrets and sought OAuth tokens using Okta client credentials discovered in customer environments.
The compromised roles also provided access to customers’ Amazon S3 storage. In some cases, the attackers downloaded entire buckets, indicating broad collection rather than a focus on particular files, according to Wiz. The researchers did not identify a specific motive or determine what happened to the stolen data.
Separate activity remains unlinked
Wiz’s investigation also uncovered another campaign, dated October 8 to October 11, that used customer-owned AWS access keys associated with Qubole integrations. A small number of those cases led to compromises of customer AWS environments. Wiz said it could not definitively connect that activity to the later use of credentials from Qubole’s AWS account, so the two sets of activity should not be treated as a confirmed single operation.
Google’s Mandiant incident responders worked with Wiz during the investigation after AI data security company Sentra flagged suspicious activity. The reported findings underscore a risk inherent in third-party integrations: access can persist when an organization no longer uses a service but has not removed the role or updated its trust policy. In that situation, a compromise of the provider’s credentials may create a route into customer environments.
Wiz recommends reviewing role activity
Wiz advised organizations that integrated with Qubole to rotate relevant credentials and investigate AWS CloudTrail logs from October 1 onward. The company recommended looking for
events where the caller’s account ID is 805246085872, with particular attention to requests originating from non-AWS IP addresses.
Credential rotation alone may not terminate temporary sessions that were already issued. For each role session identified, Wiz recommended reviewing subsequent actions, especially activity involving Secrets Manager, Systems Manager Parameter Store, Lambda and S3. If an attacker assumed an integration role, organizations should rotate every secret, parameter and Lambda environment variable that role could access, and revoke active sessions for the role.
