Qubole Breach Explained, How Hackers Used Trusted AWS Access to Steal Customer Data

A trusted connection between a software vendor and its customers has been turned into a weapon. According to cloud security company Wiz, an attacker used credentials tied to an AWS account associated with Qubole to enter the cloud accounts of multiple customers and steal stored secrets and data. The Qubole breach ran from October 14 to October 26, 2026.

This guide explains what happened in plain language, why the attack worked, and what any company that has ever connected a vendor to AWS should do now. For more security coverage, explore our Cybersecurity and Technology sections at Jantarax Tech.

What Is Qubole?

Qubole is a data lake platform owned by Idera. A data lake is a large storage space where companies keep raw data from many sources so they can analyze it later. Qubole helps customers manage that data and run big data jobs.

The important detail is where Qubole works. It operates inside its customers’ own AWS accounts. That design is common for data tools, because the data stays in the customer’s cloud. But it also means Qubole must be given a way in.

What Happened in the Qubole Breach?

Wiz, working with security firms Sentra and Mandiant, saw a threat actor use IAM credentials from an AWS account associated with Qubole between October 14 and October 26, 2026. With those credentials, the attacker got into the AWS environments of multiple customers.

In short, the Qubole breach was not a break-in through the front door. The attacker used an entrance that customers had already opened for a trusted vendor.

Wiz says the first activity it observed was on October 14, from an IP address belonging to a VPN service, which began requesting access to roles in customer environments. Once inside, the attacker hunted for stored credentials.

A few important facts remain unknown:

• How the credentials were stolen. This has not been disclosed.
• How many organizations were affected. Wiz has not said.
• What Qubole and Idera plan to do. Neither company had posted a statement on its website when The Hacker News checked, and AWS and Qubole did not respond to The Register. 

How the Qubole Breach Worked

To understand the Qubole breach, you need to know a few AWS basics. Here they are in simple terms.

IAM role. In AWS, an IAM role is an identity with a set of permissions. Think of it as a keycard that opens certain doors.

Cross-account access. When a vendor like Qubole needs to work inside your cloud, you create a role and tell AWS to let the vendor’s AWS account use it. This is called a trust relationship.

Assuming a role. The vendor’s account asks AWS for temporary credentials to use that role. This step is called AssumeRole.

External ID. Vendors often add a code called an External ID to protect against misuse. Wiz’s analysts noted that this code is not treated as a secret and can be viewed by anyone with access to the role. So it is not a strong lock by itself.

Here is what Wiz says the attacker did:

1. Used credentials from an AWS account associated with Qubole.
2. Asked AWS for temporary access to integration roles in customer accounts.
3. Moved through customer environments and searched for stored secrets.
4. Copied data and credentials out.

This is why researchers call it abusing trust. The customers had set up legitimate roles. The problem was that someone else got hold of the key to use them.

What Did the Attacker Steal?

In the accounts the researchers examined, the attacker looked for stored credentials, including the victims’ own AWS access keys, Entra ID client secrets, and Okta client credentials. Entra ID connects to Microsoft identity services, and Okta is another widely used identity provider.

The attacker also copied data from cloud storage. Stolen secrets are especially dangerous because they can open doors beyond the first account. A leaked key for one service can lead to access in other systems, which is why checking logs for follow-on activity matters.

Wiz also says the attacker used an open-source secret-scanning tool to test the keys it discovered. These tools are meant to help defenders, but attackers can use them too.

A Separate Earlier Episode

Wiz also found a different set of suspicious activity tied to Qubole integrations. From October 8 to October 11, an actor tested customer-owned AWS keys believed to have been created for Qubole and compromised a small number of environments.

Wiz has not linked this earlier activity to the October 14 to 26 attack. They may be unrelated, or they may be connected. For now, they are best treated as two separate events.

Why Dormant Access Is So Dangerous

One of the most useful findings came from Sentra and Wiz. They report that most of the roles the attacker used were not otherwise in use. In other words, many were dormant.

That matters because it shows a common problem. When a company connects a vendor to AWS, it creates a role. Years later, the contract may have ended, the project may be finished, or the team may have moved on. But the role often stays in place, still trusting the vendor’s AWS account.

The Qubole breach shows what that leftover trust can mean. If one vendor credential is stolen, it can become valid access into many customer accounts at once. That can include accounts where the product was retired long ago.

Who Might Be Affected?

Any organization that has ever connected Qubole to AWS could be affected, even if it no longer uses the product. That includes:

• Companies using Qubole today.
• Companies that stopped using Qubole but never deleted the roles or keys.
• Teams that created AWS access keys for Qubole instead of using roles.

You do not need to be a large enterprise. Data teams at small and mid-size companies often set up these connections and then forget about them.

What Should Customers Do Now?

Here is a practical plan to respond to the Qubole breach. The first steps follow guidance from Wiz and Sentra. The rest is general good practice.

1. Find every Qubole connection. Search your AWS accounts for roles that trust an external AWS account, and look for access keys that were created for Qubole.
2. Check your logs. Wiz’s hunting guidance covers CloudTrail logs from October 1 onward in every AWS account that holds a Qubole role. Look for unfamiliar role assumptions and unusual data access.
3. Use Wiz’s published details. Wiz has released the AWS account ID, IP addresses, and queries to help you hunt. 
4. Remove unused trust. If you no longer use Qubole, delete the roles and keys. If you do use it, confirm each role is still needed.
5. Limit where access can come from. Where possible, restrict roles to known networks.
6. Rotate secrets. Replace AWS access keys, Entra ID client secrets, and Okta client credentials that were stored in affected accounts.
7. Review data access. Check which storage buckets the roles could reach, and look for large or unusual downloads.
8. Tighten permissions. Give each role only the access it needs.
9. Ask the vendor. Contact Qubole or Idera for guidance and updates.
10. Prepare for the worst. If you find signs of misuse, follow your incident plan and consider bringing in a security professional.

If you are not sure where to start, begin with step 1. You cannot protect connections you do not know about.

What the Qubole Breach Means for Cloud Security

The Qubole breach is a textbook example of supply chain risk. Your security is only as strong as the weakest vendor you trust. A company can do many things right and still be exposed through a partner.

Several lessons stand out.

Shared responsibility is real. Cloud providers secure the underlying platform, but customers are responsible for who they give access to. Roles and keys are part of your security, not just your vendor’s.

Trust should expire. Access granted for a project should end when the project ends.

Secrets spread. Stored keys and client secrets are easy to forget and easy to steal. The fewer you keep, the better.

Logs are your safety net. Without logging, you cannot tell whether a trusted role was misused.

This pattern is not new. Chainstack recently reported a breach in which an attacker got in through a third-party component, and our report on the Revolut data breach caused by fake government requests shows how outside parties can become the weak link. Defenders are also using new tools, such as Anthropic’s free AI vulnerability scanner for open-source projects.

Lessons for Every Company

You do not need to use Qubole to learn from this incident. Whatever tools you use, the Qubole breach teaches a few habits worth adopting:

• Keep an inventory of vendor access. List every outside service that can reach your cloud, who owns it, and why it exists.
• Review it on a schedule. Check quarterly and remove what is no longer needed.
• Prefer roles over long-lived keys. Temporary credentials are safer than keys that never expire.
• Add conditions to trust. Limit access by network, time, or other rules where possible.
• Monitor vendor activity. Alert on unusual use of vendor roles.
• Include vendors in your incident plan. Know how to cut off a vendor quickly.
• Ask vendors hard questions. How do they protect the credentials that reach your cloud?

What Happens Next?

As the investigation continues, more details are likely to come out. Further details about the Qubole breach may include how the credentials were stolen, how many customers were hit, and what Qubole and Idera will change.

Customers may also need to reassess their own security measures, especially around access management and credential storage. Things to watch include:

• An official statement from Qubole and Idera.
• Updates from Wiz and its partners as the investigation develops.
• Guidance from AWS on protecting vendor integrations.
• Reports from affected companies about what was taken.
• Changes to how vendors connect to customer clouds across the industry.

Frequently Asked Questions

What is Qubole?
A data lake platform owned by Idera that runs inside customers’ AWS accounts.

When did the attack happen?
Between October 14 and October 26, 2026, according to Wiz. A separate episode involving customer-owned keys happened between October 8 and 11.

What was stolen?
Stored secrets and data, including AWS access keys, Entra ID client secrets, and Okta client credentials.

How did the attacker get in?
They used credentials for an AWS account that Qubole’s platform uses to reach customers. How they got those credentials has not been disclosed.

Am I affected if I no longer use Qubole?
Possibly. Old roles and keys may still exist. Check your AWS accounts.

How many companies were hit?
Wiz has not said.

What is the first thing I should do?
Find every Qubole role and key in your AWS accounts, and review CloudTrail logs from October 1 onward.

Conclusion

The Qubole breach is a reminder of how much trust we place in vendors and how quickly that trust can be abused. Cloud computing makes sharing access easy, and that makes careful housekeeping essential. Audit your connections, remove what you do not need, and watch your logs. The companies that treat vendor access as part of their own security will be best prepared for the next incident.

For more updates, learn about Jantarax Tech or contact our team with tips and feedback.