- Wiz found an intruder using credentials from a Qubole-linked AWS account to enter customer environments between October 14 and 26, 2026. Most roles used were otherwise unused that month.
- The External ID in these role setups guards against one misuse. It does not stop a compromised vendor identity, and Wiz says it is not a secret.
- Wiz advises customers to pin trusted principals and source networks and to remove unused trust. It tells vendors to use short-lived credentials and publish egress ranges.
The safeguard that was never a lock
Companies give software vendors a way into their cloud, and the setup includes a safeguard called an External ID. A new Wiz investigation shows what that safeguard does and what it does not do.
Our argument is this. The External ID guards against one specific misuse. It does not guard against a compromised vendor identity. The control that matters is who may use the role, and from which network.
What Wiz found
Wiz worked with Sentra and Mandiant. Between October 14 and 26, 2026, it saw an intruder using credentials from an AWS account linked to Qubole, a data processing platform. These were IAM credentials, which AWS uses to decide who may do what.
The intruder used them to take on roles that Qubole's customers had built to trust Qubole's account. Inside several victim environments, Wiz says, the intruder listed resources, gathered secrets and read S3 storage. It also tested credentials it found along the way.
Sentra noticed odd activity in several of its customers' environments and alerted Wiz. BleepingComputer reports that Sentra confirmed dozens of victims. It also reports that millions of files were taken from one customer alone.
BleepingComputer's account of the Wiz report says the intruder held two Qubole IAM users. How they were compromised is not stated. BleepingComputer found no public statement from Qubole and has asked the company for comment.
A person calling themselves "n0n" has claimed responsibility, per the Risky Business newsletter. Wiz has found no link to other public activity. It says it cannot see the intruder's motive.
Wiz also saw a separate set of Qubole-integration activity from October 8 to 11. It used customer-owned access keys, and Wiz could not link it to the role-assumption campaign described here.
Why the External ID did not help
Many software tools work inside a customer's AWS account through a cross-account role. The customer creates the role. A trust policy on it names the vendor's account as allowed to use it.
The External ID is a shared value sent with each request. Its job is to stop a vendor being tricked into acting for the wrong customer. It was not built to prove who is calling.
Wiz says it is not a secret. CloudTrail, AWS's activity log, records it in plain text. Vendors and infrastructure-as-code files often store it too. Wiz says every request it tied to the intruder carried a valid External ID. Every one worked.
Unused roles made up most, not all
Wiz says most of the roles the intruder opened had no other use. In a majority of the environments it observed, the intruder's requests were the only AssumeRole calls from the vendor account in October. Not every environment fit that pattern.
Wiz adds that many victims had no legitimate vendor traffic during the attack. Their trust policies still accepted the intruder's requests.
Unused roles are worth removing. But idleness did not cause this. The trust policy and a valid External ID were enough, and they would be enough on a busy role too. That is our reading, not a finding in the report.
What the intruder did with the access
The intruder hunted for more credentials. Wiz says it read Lambda function settings, which can hold environment variables. It also pulled values from Secrets Manager and SSM Parameter Store. Sentra says it gathered 100 passwords and keys in seven minutes.
It then ran TruffleHog, a tool that checks whether found credentials work. It tried keys for AWS, plus secrets for Microsoft Entra ID service accounts and login details for Okta. Wiz says all of these belonged to the victims, not the vendor.
The data theft looked opportunistic. Wiz says the intruder took what each role could reach. Sometimes that meant a whole bucket in one session.
Logging set the limit on what responders could learn. Wiz says CloudTrail management events record the role being assumed and the buckets listed. They do not record files being read. Wiz says missing logs left responders unable to tell which S3 objects were read in several environments.
Shared exposure, not a single owner
AWS told BleepingComputer its services "were not compromised" and worked as designed. It said threat actors used a third-party provider's credentials to take on roles that customers had set up. That is AWS's position.
Wiz describes a split. The way in was a vendor identity. Customer settings decided how far the intruder got. Wiz also says those vendor identities act as credentials to every customer environment at once.
So both sides hold part of the risk. Compromised vendor credentials opened many companies. Each company's trust and permission choices set the damage inside its own account.
What to ask your own team
Start with an inventory. List every IAM role whose trust policy lets an outside account in. Then remove the trust for integrations you no longer use.
For the rest, name the specific vendor identity, not the whole account. Add a condition that limits the network the request may come from. Wiz says a source IP condition alone would have stopped every role assumption it saw.
Check what each vendor role can read. Wiz notes that access to Lambda settings, Secrets Manager and wide S3 reading is often granted for convenience. Turn on S3 data events for sensitive buckets.
If you used Qubole, Wiz suggests reviewing CloudTrail from October 1, 2026 in every account holding an integration role. Look for AssumeRole calls from account 805246085872 that did not come from AWS addresses. If a role was assumed, rotate what it could read and revoke its sessions. Rotating a credential does not end sessions already issued.
What to ask your vendors
Wiz also lists duties for software providers. Ask each vendor whether it uses short-lived credentials instead of long-lived IAM user keys. Ask whether it limits where its identities can be used from.
Ask whether it publishes its network ranges so you can pin your trust policies to them. Ask whether it watches its own logs for calls into customer accounts from unexpected networks.
A vendor that cannot answer those questions leaves you with only the External ID. That value is not a secret, so it cannot be the only thing standing between your account and a compromised vendor identity.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Wiz.
