Global News | November 10, 2026

Cloud security researchers have uncovered a serious supply-chain incident involving Qubole-associated Amazon Web Services (AWS) credentials that were abused to access multiple customer cloud environments. The Qubole AWS supply-chain attack allowed a threat actor to exploit trusted third-party access relationships, enumerate cloud resources, collect sensitive credentials and download information stored in Amazon S3 buckets.

The investigation, published by cybersecurity company Wiz on November 9, 2026, describes suspicious activity observed between October 14 and October 26. Wiz conducted the investigation alongside data security company Sentra and cybersecurity firm Mandiant after Sentra identified suspicious activity across several customer environments.

According to the findings, the attacker used credentials belonging to an AWS account associated with Qubole to assume IAM roles that customers had previously configured to trust the vendor’s account. Once those requests succeeded, the attacker gained access to resources within multiple customer AWS environments.

The compromised access relationships enabled the attacker to investigate cloud infrastructure, retrieve secrets from storage services, inspect application configuration and access customer S3 data. In some cases, entire storage buckets were downloaded during individual sessions.

The investigation raises important questions about third-party cloud integrations, dormant permissions and the security risks associated with granting vendors continuing access to customer infrastructure.

Although the researchers documented successful access and data downloads, the total number of affected organizations, the quantity of information taken and the original method used to obtain the vendor-associated credentials remain undisclosed.

1. How the Qubole AWS Supply-Chain Attack Was Discovered

The incident came to light after Sentra identified suspicious activity across several customer environments. The company shared its findings with Wiz, which subsequently conducted a wider investigation with assistance from Mandiant.

Wiz reported that the first activity associated with the campaign was observed on October 14, 2026. The attacker was using IAM credentials from an AWS account associated with Qubole to request access to customer-created integration roles.

The activity continued through October 26, according to the investigation.

Rather than exploiting a publicly disclosed software vulnerability, the attacker abused an existing relationship of trust between the vendor’s AWS account and customer environments.

This distinction is important. The reported incident was not described as a conventional vulnerability-based intrusion. Instead, the attacker used valid credentials and existing authorization arrangements to gain access that the customer environments had already permitted under their integration configurations.

Wiz identified AWS account number 805246085872 as the account associated with the observed Qubole integration activity.

The researchers also identified suspicious IAM user principal IDs, unusual network sources and consistent role-session naming patterns.

The findings establish that unauthorized access occurred across multiple customer environments. However, the public investigation does not provide a confirmed total of affected organizations or identify the customers involved.

2. Why Trusted AWS Integration Roles Became an Attack Path

Understanding the Qubole AWS supply-chain attack requires examining how third-party AWS integrations normally operate.

Cloud platforms frequently need permission to access resources within customer environments. Instead of giving vendors unrestricted access to customer accounts, AWS supports cross-account IAM role arrangements.

Under this model, a customer creates an IAM role inside its own AWS account. The role’s trust policy permits an external vendor account to assume that role under specified conditions.

The vendor can then request temporary credentials that allow it to perform the activities authorized by the customer.

An External ID is commonly included in this arrangement to help protect against certain confused-deputy scenarios. However, it is not a substitute for strong identity controls or restrictions on the trusted principal.

According to Wiz, the attacker successfully assumed customer-created roles using credentials associated with Qubole’s AWS account. Every role-assumption request attributed to the attacker included an External ID, and every observed request succeeded.

A particularly concerning finding involved dormant integrations.

Wiz reported that most of the roles accessed by the attacker were not otherwise in use. In a majority of the environments examined, the attacker’s requests were the only role-assumption activity from the vendor account during October.

In other words, customers had retained trust relationships that were no longer being actively used but still allowed access.

This illustrates a major cloud-security weakness: organizations can unintentionally preserve third-party permissions long after a service or integration stops being operationally necessary.

The Qubole AWS supply-chain attack demonstrates how those forgotten permissions can become an entry point when credentials associated with a trusted vendor account are abused.

3. What the Attacker Accessed Inside Customer AWS Environments

After successfully assuming the customer roles, the attacker began examining the available cloud resources.

Wiz identified activity involving storage, computing infrastructure, databases, identity services and encryption-related resources.

The attacker used AWS API calls to identify available resources and determine what the assumed roles could access.

The investigation also identified attempts to locate sensitive information in several common cloud storage locations.

AWS Lambda environment variables: The attacker listed Lambda functions and retrieved their configurations. These configurations can contain environment variables that applications use to store operational settings and, in some cases, credentials.

AWS Secrets Manager: The attacker listed available secrets and retrieved their values where permissions allowed.

AWS Systems Manager Parameter Store: The attacker investigated stored parameters and retrieved values that could contain sensitive application configuration or credentials.

These activities are significant because cloud environments often contain information that connects multiple systems.

For example, a credential stored in a Lambda environment variable or Secrets Manager could potentially provide access to another cloud service, application or identity platform.

Wiz reported that the attacker used TruffleHog to validate credentials discovered in customer environments.

The credentials included AWS access keys, Microsoft Entra ID service-principal client secrets and Okta client credentials.

Importantly, these were credentials belonging to affected organizations rather than Qubole itself.

This means the potential consequences of the Qubole AWS supply-chain attack extended beyond the initial trusted integration relationship. Exposed credentials could potentially create additional access opportunities across the affected organizations’ technology environments.

However, the public investigation does not establish that every discovered credential was successfully used to compromise another system.

4. S3 Data Theft and the Challenge of Measuring the Exposure

One of the most serious findings involved unauthorized access to information stored in Amazon S3.

According to Wiz, the attacker followed a repeated sequence after assuming customer integration roles.

First, the attacker identified accessible storage buckets using the ListBuckets API call.

Next, ListObjects and HeadObject were used to enumerate and inspect the contents of available storage.

Finally, GetObject requests were used to download information from the accessible buckets.

The researchers described the activity as opportunistic. Rather than concentrating exclusively on particular types of information, the attacker accessed data that the assumed roles were authorized to reach.

In some cases, Wiz observed entire buckets being downloaded during individual sessions.

However, the research did not provide a complete account of the information contained in those buckets or the total quantity of customer data successfully transferred.

Another important issue involved security logging.

Wiz explained that CloudTrail management events can record role-assumption activity and bucket listings, but they do not necessarily record the individual S3 object reads involved in data downloads.

Organizations require appropriate S3 data-event logging or S3 server access logs to obtain visibility into those object-level activities.

In several affected environments, missing logs prevented investigators from determining exactly which S3 objects the attacker had accessed.

This creates a serious incident-response challenge.

An organization may be able to confirm that an unauthorized actor entered its cloud environment without having enough historical logging to identify every file or object that was downloaded.

The Qubole AWS supply-chain attack therefore highlights two separate security failures that organizations need to address: excessive third-party permissions and insufficient visibility into sensitive cloud data access.

5. Suspicious Indicators and the Unresolved Entry Method

Wiz published several technical indicators that security teams can use to investigate possible exposure.

One notable indicator was the use of role-session names beginning with the prefix quiam-. Examples included quiam-enum and quiam-scope-full.

The researchers also identified two IAM user principal IDs associated with the activity:

• AIDA3W7DIFLYOLTK63SFS
• AIDAJYRRH5Y3A7AAJM2HW

Wiz said the first identity was not observed in other activity across the affected environments examined. The second also carried legitimate Qubole platform traffic, meaning investigators need to consider its source network when evaluating suspicious activity.

The investigation additionally identified activity originating from Mullvad VPN addresses and an OVH-hosted virtual private server.

These indicators should be evaluated together rather than treated as definitive proof when seen individually. In particular, VPN addresses may be shared by unrelated users.

Despite the technical findings, one central question remains unanswered: how did the attacker originally obtain credentials associated with the Qubole AWS account?

Wiz’s public report does not establish whether the credentials came from a compromise of Qubole’s infrastructure, an exposed access key, another credential-management failure or a different route.

It would therefore be premature to describe the incident as a confirmed breach of Qubole’s entire production platform.

The researchers also identified a separate period of suspicious activity between October 8 and October 11 involving customer-owned AWS access keys believed to have been created for Qubole integrations.

Wiz explicitly stated that it could not link this earlier activity to the October 14–26 role-assumption campaign.

That distinction matters because the two activities should not be combined into one confirmed attack sequence without additional evidence.

6. What Organizations Should Do to Protect Their AWS Environments

The findings provide several practical lessons for organizations that use third-party services connected to AWS.

Wiz recommends reviewing CloudTrail records from October 1, 2026 onward in every account containing a Qubole integration role.

Security teams should investigate role-assumption requests originating from AWS account 805246085872, especially when the source address does not belong to expected AWS infrastructure.

They should also examine the identified IAM principal IDs, suspicious network indicators and role-session names beginning with quiam-.

Where suspicious sessions are identified, organizations should review subsequent activity involving Lambda, Secrets Manager, Systems Manager Parameter Store and S3.

If a role was accessed by the attacker, potentially exposed secrets, parameters and Lambda environment variables should be rotated. Existing temporary sessions associated with compromised roles should also be revoked.

Beyond immediate investigation, organizations should reconsider how they manage third-party access.

Unused integration roles should be removed, and the permissions granted to active vendor integrations should be limited to what is genuinely required.

Where supported, customers should narrow trusted IAM principals instead of allowing an entire external AWS account to assume a role. Source IP or VPC endpoint restrictions can also provide additional protection.

Another important measure is enabling appropriate logging across all AWS accounts and regions, including S3 data events for sensitive storage buckets.

Finally, organizations should regularly review vendor relationships instead of assuming that an integration is safe simply because it was approved during an earlier onboarding process.

7. What Remains Unknown About the Qubole Incident?

Despite the detailed technical investigation, several important questions remain unanswered.

Wiz has not disclosed the exact number of affected customer organizations or AWS accounts.

The full volume of downloaded S3 information has also not been established publicly. Although entire buckets were reportedly downloaded in some sessions, the contents and sensitivity of those buckets have not been comprehensively identified.

The initial method through which the attacker obtained the Qubole-associated credentials remains unknown.

The investigation has also not established the identity of the attacker or the ultimate use of the stolen information.

Wiz reported that it had not identified connections between the campaign and other publicly reported activity. It also described the targeting and data theft as apparently opportunistic, while acknowledging that it had no direct insight into the attacker’s motivation.

At the time of The Hacker News’ November 9 reporting, neither Qubole nor its parent company Idera had published a statement about the incident on their websites.

These gaps should remain visible in any assessment of the incident. Successful unauthorized access and data downloads are established findings in Wiz’s investigation, but the total impact cannot yet be quantified.

Conclusion

The Qubole AWS supply-chain attack demonstrates how trusted third-party integrations can become serious security risks when vendor-associated credentials are abused.

The attacker did not need to exploit a newly disclosed software vulnerability to gain access to the customer environments examined by Wiz. Existing IAM trust relationships provided a route into multiple organizations, including environments where integration roles were no longer actively being used.

The investigation documented resource enumeration, credential collection, validation of additional credentials and downloads from customer S3 storage.

For organizations using cloud-based data platforms and other third-party integrations, the incident is a reminder that access permissions must be continuously reviewed rather than treated as permanent arrangements.

Removing unused trust relationships, limiting vendor permissions, monitoring role assumptions and maintaining comprehensive data-access logs are essential steps in reducing the risk of similar incidents.

The investigation’s unanswered questions also reinforce the importance of transparent incident reporting. Until more information becomes available, the number of affected organizations, the full quantity of stolen information and the original credential-compromise method remain unconfirmed.

Source note: This report draws primarily on the November 9, 2026 investigation published by Wiz, conducted in collaboration with Sentra and Mandiant, together with reporting by The Hacker News. The reported activity and data-access findings are attributed to the researchers. The initial credential-compromise method, total affected customer count and full volume of stolen data have not been publicly established.

NewsFlayer — Bringing You the Latest Cybersecurity News from Around the World.