MAG212 CYBER ORIGINAL ARTICLE

When the Vendor’s Identity Is the Attacker: Qubole’s AWS Roles, Railway’s Build Escape and AntiFox

November 14, 2026 · El Mostafa Ouchen

The vendor is the attacker: Qubole's compromised AWS account assuming dormant integration roles in several customer accounts with valid External IDs to read secrets and S3 data, beside a smaller Railway panel showing a build-container escape leading

From the MAG212 CYBER Weekly, 14 November 2026. Status labels: confirmed by vendor, reported by researchers, or unverified. Every command below is copied from official documentation and was not tested by MAG212; run it only on systems you are authorised to administer.

Status:

  • Qubole: reported by researchers (Wiz, Sentra, Mandiant) via BleepingComputer and CSO [40][41]. AWS says its services were “not compromised… operated as designed” [40]. BleepingComputer found no Qubole statement. MAG212 did not fetch the primary Wiz and Sentra blogs [42][43].
  • Railway: based on Railway’s incident report as reported by BleepingComputer (10 Nov); the report itself was not fetched [44].
  • AntiFox: single secondary source (BleepingComputer, citing Arctic Wolf) [45].

What happened — Qubole

Why this matters

Cross-account roles are designed to let vendors in. When the vendor's own account is compromised, the External ID check passes and the activity looks legitimate. Dormant integrations nobody remembers are the gap, so inventory and revocation beat detection alone. (MAG212 analysis)

Qubole's compromised AWS account assuming dormant integration roles in several customer accounts with valid External IDs to read secrets and S3 data, beside a smaller Railway panel showing a build-container escape leading to decrypted environment variables.
Diagram: MAG212 CYBER. Solid red = observed or vendor-confirmed; dashed amber = reported or unverified; green = recommended control.

From 14 to 26 October, an attacker used IAM credentials from Qubole’s AWS account (805246085872) to call STS AssumeRole into customers’ Qubole integration roles. Every request carried the correct External ID. Many of the roles were dormant, or left over after the customer had stopped using Qubole [40]. The timeline [40]:

  • 14 Oct: first attempts, from a Mullvad VPN address.
  • 18 Oct: a second Qubole IAM identity comes into use.
  • 14–26 Oct: most of the activity comes from an OVH VPS at 57.129.54[.]120.

Inside customer accounts, the attacker [40][41]:

  • enumerated resources
  • read Secrets Manager, SSM Parameter Store and Lambda environment variables
  • downloaded S3 data, sometimes whole buckets
  • validated the harvested AWS keys, Entra ID client secrets and Okta client credentials with TruffleHog

Sentra counted more than 100 passwords and keys taken in about 7 minutes, and reports no write operations. Dozens of organisations were affected [40].

What happened — Railway

In its new 10 November incident report, Railway said that on 20 October an unknown flaw in its build infrastructure let attackers escape filesystem isolation. From there [44]:

  1. They obtained an internal credential.
  2. That gave access to build histories and source code.
  3. A misconfigured trust relationship then gave them credentials able to decrypt customer environment variables.

The attackers were removed on 21 October [44]. The impact [44]:

  • up to about 100,000 workspaces (1.85%) potentially affected; Railway gives this as a maximum, not a confirmed count
  • 1,852 users’ linked-account tokens exposed and reset, including GitHub OAuth tokens and AI agent keys
  • about $740,000 in fraudulent AI usage, with the attackers using AI agents
  • the activity is linked to the Wiz-described “Black October” campaign against AI developer platforms

What happened — AntiFox

Arctic Wolf reported attackers using AntiFox, an open-source agentic pentest platform forked from ARTEX and self-hosted on Alibaba Cloud. Three intrusions were described [45]:

  1. An IIS webshell harvested connection strings, then probed AWS.
  2. Hundreds of API calls in about 30 minutes cycled through identities. Some succeeded and exposed production secrets.
  3. Attackers read, copied and deleted S3 data.

The report does not say which steps the AI agents performed [45].

Who is affected

  • Qubole: any AWS account that ever created a Qubole cross-account role and did not delete it [40].
  • Railway: workspaces notified by Railway, and the 1,852 users whose tokens were reset [44].

How the Qubole attack works:

  1. The vendor’s IAM identity is compromised. How is unknown.
  2. The attacker calls sts:AssumeRole into the customer role with a valid External ID.
  3. They read secrets stores and S3.
  4. They validate the stolen secrets offline.
  5. Unknown: any use of the harvested Entra and Okta secrets afterwards.

What defenders should look for

  • Qubole IOCs:
    • IAM user ID AIDA3W7DIFLYOLTK63SFS
    • source IP 57.129.54[.]120
    • sso_agent.iso on attacker infrastructure (TCP 23458; deployment not confirmed)
  • CloudTrail events to review from 1 October (named by Wiz): AssumeRole, ListBuckets, ListObjects, HeadObject, GetObject [40].
  • AntiFox: successful calls hidden inside bursts of AccessDenied [45].

False positives: legitimate Qubole jobs, if you still use the service. Compare against job schedules.

How to investigate

Filter CloudTrail for AssumeRole events where the caller’s account is 805246085872. Then follow each assumed-role session’s activity. Inventory every secret readable by that role and treat it as exposed. AWS CLI and CloudTrail query syntax was not verified this week, so MAG212 prints no commands.

Contain and remediate (in order) [40][45]:

  1. Revoke the role’s active sessions.
  2. Rotate every secret the role could read, including the Entra service-principal secrets and Okta OAuth client secrets stored in AWS.
  3. Delete unused vendor integrations.
  4. Narrow trust policies to specific vendor principals, and add source-IP or VPC-endpoint conditions.
  5. Require IMDSv2 and enable GuardDuty.
  6. Railway users: rotate every environment variable stored on the platform, and re-link the GitHub and AI-provider tokens.

Verify recovery

Confirm no cross-account roles trust departed vendors. Confirm old secrets fail. Check for unexpected Entra or Okta sign-ins by the rotated clients.

Prevention and awareness

An External ID protects against the confused-deputy problem, not against a compromised vendor. Treat every vendor role as standing access: review it quarterly and delete it the day the contract ends.

No command panels.

Related on MAG212 CYBER

Sources

  1. [40] BleepingComputer, “Hackers exploit trusted AWS access to breach multiple cloud environments”, 10 Nov 2026 (AWS statement added 11 Nov). link
  2. [41] CSO Online, “Qubole supply chain attack exposed AWS, Entra ID and Okta credentials”, 10 Nov 2026. link
  3. [42] Wiz, “Qubole cross-account access abused in the wild (not fetched)”, Nov 2026. link
  4. [43] Sentra, “Inside the Qubole supply chain attack (not fetched)”, Nov 2026. link
  5. [44] BleepingComputer, “Railway breach leads to $740,000 in fraudulent AI charges”, 10 Nov 2026. link
  6. [45] BleepingComputer, “Hackers use AntiFox AI agents in AWS credential theft attacks”, 11 Nov 2026. link

Written and edited by El Mostafa Ouchen for MAG212 CYBER. Facts checked against the sources above as of 14 November 2026, 10:05 AM PST. Diagrams are original MAG212 CYBER illustrations.