A PaaS breach that turned stored API keys into a $740,000 LLMjacking invoice. A big-data platform whose trusted AWS IAM roles became a bridge into customer clouds. A hypervisor management console where an empty JSON token grants full admin. Today’s stories share a common thread: non-human identities - API keys, cross-account roles, session tokens - remain the softest targets in most environments.

In the News

Railway Breach: Stolen Customer API Keys Drive $740K in Fraudulent AI Charges

PaaS provider Railway confirmed that an October breach exposed customer secrets stored in platform configuration variables - API keys, database passwords, and service credentials. Attackers took the stolen AI provider API keys and used them for LLMjacking: running unauthorized inference workloads that generated $740,000 in charges across multiple AI providers. Railway is absorbing the costs where providers refuse refunds.

The mechanism is straightforward and common. Customers embedded long-lived API keys as environment variables in Railway’s platform configuration. When the platform itself was compromised, every stored secret was exposed in a single event. There was no vault indirection, no automatic rotation, no scope restriction on the keys. The blast radius of a single platform breach extended to every third-party service those keys could authenticate to.

This is the secrets-sprawl problem at scale. The question is not whether a PaaS provider will be breached - it is whether the secrets stored there are resilient to that breach. Short-lived tokens, vault-backed secret injection, and automated rotation reduce the window of exploitation. Long-lived API keys stored in plaintext config variables do not survive a platform compromise.

What defenders should do: Audit where AI provider API keys (OpenAI, Anthropic, Cohere, etc.) are stored across your organization. Migrate from static environment variables to secrets management vaults with automated rotation. Scope API keys to minimum required permissions and set usage alerts that trigger on anomalous inference volume. (MITRE ATT&CK: T1552.001 - Unsecured Credentials: Credentials In Files)

Attackers Pivot Through Qubole’s Trusted AWS IAM Roles to Breach Customer Clouds

Wiz disclosed that attackers compromised Qubole’s AWS IAM credentials and used the big-data platform’s trusted cross-account IAM roles to access multiple customer AWS environments. The breach window spanned October 14 through October 26 - 12 days of access before detection. Data exfiltration was confirmed across affected customer accounts.

The attack path exploits a fundamental design pattern in cloud identity. Customers grant third-party SaaS vendors cross-account IAM roles so those vendors can operate within the customer’s AWS environment. The trust is transitive: if the vendor’s account is compromised, every customer environment that trusts that account is exposed. Qubole’s compromised credentials carried the permissions of every cross-account role that trusted Qubole’s AWS account ID.

This is not a novel technique, but the scale is instructive. Most organizations cannot enumerate which third-party vendors hold cross-account trust in their cloud environments without running a dedicated CSPM scan. The remediation is scoping cross-account roles to minimum required permissions, requiring external ID conditions, and implementing just-in-time access elevation rather than persistent trust. (MITRE ATT&CK: T1199 - Trusted Relationship, T1078.004 - Valid Accounts: Cloud Accounts)

What defenders should do: Run a cross-account trust audit in AWS IAM. Enumerate all roles with sts:AssumeRole trust policies pointing to external account IDs. Scope permissions to minimum required actions and resources. Require ExternalId conditions. Implement CloudTrail alerting on cross-account AssumeRole events from vendor accounts.

Xen Orchestra Auth Bypass Exploited in the Wild - Empty JSON Grants Admin

Vates VMS warned of active exploitation of a critical authentication bypass in Xen Orchestra, the web-based management console for XCP-ng virtualization. The flaw is in REST API cookie parsing: submitting an authentication token value of %7B%7D (URL-encoded {}, an empty JSON object) bypasses all authentication checks and grants full administrator access to the hypervisor management plane.

No CVE has been assigned yet, which complicates patch tracking and automated vulnerability scanning. The advisory from Vates recommends immediate update to the latest Xen Orchestra build. Organizations running XCP-ng should verify whether Xen Orchestra management interfaces are accessible from networks beyond the hypervisor management VLAN.

The pattern is familiar: a management console for critical infrastructure - in this case, the hypervisor layer - exposed with a trivially exploitable authentication flaw. Authentication bypass on management interfaces is consistently among the highest-impact vulnerability classes because it grants immediate administrative control with no credential requirement. (MITRE ATT&CK: T1190 - Exploit Public-Facing Application)

What defenders should do: Update Xen Orchestra immediately. Verify that Xen Orchestra management interfaces are network-segmented and accessible only from dedicated management VLANs. Enforce MFA on all hypervisor management consoles. Monitor for unexpected admin session creation in Xen Orchestra logs.

Microsoft Research: AI Agents Backdoored by Editing Fewer Than 10 Neurons

Microsoft Research published a demonstration that capable AI agent models can be turned into “sleeper agents” by editing fewer than 10 neurons - with no retraining required. When a specific trigger string appears in the model’s input, the backdoored agent executes attacker-controlled commands using its own delegated privileges - API tokens, OAuth scopes, cloud credentials.

The attack requires only inference-level compute. Any machine capable of running the model can also backdoor it. During testing, Claude Code with Opus 4.5 detected most of the anomalous weight edits, suggesting that weight-integrity monitoring is technically feasible but far from standard practice in production deployments.

The identity implication is direct. AI agents operate with delegated non-human identities - service accounts, API keys, OAuth tokens. A backdoored model exercising those privileges is indistinguishable from a legitimate agent request unless behavioral monitoring is in place. This is model integrity as an identity security problem: the agent’s identity is only as trustworthy as the model driving its decisions.

What defenders should do: Implement model provenance verification (hash-based integrity checks on model weights before deployment). Scope agent service accounts to minimum required permissions. Monitor agent API call patterns for anomalous behavior - sudden changes in accessed resources or call volume. Treat AI agent identities with the same lifecycle governance as human privileged accounts.

Defender Action Items

  • Audit all AI provider API keys for storage location; migrate from plaintext config variables to secrets vaults with automated rotation and usage alerting
  • Enumerate cross-account IAM trust relationships in AWS; scope to minimum permissions, require ExternalId, alert on cross-account AssumeRole events
  • Verify Xen Orchestra management consoles are network-segmented and MFA-enforced; update to latest build immediately
  • Implement model weight integrity checks for AI agents in production; scope agent service account permissions to least privilege
  • Apply Microsoft November Patch Tuesday updates - CVE-2026-124194 (Outlook spoofing, CVSS 6.5) is actively exploited
  • Patch Cisco BroadWorks CVE-2026-20320 (XXE, CVSS 7.5) - added to CISA KEV

Detection Queries

Cross-account IAM role assumption from unexpected external accounts (AWS CloudTrail via Splunk SPL):

index=aws sourcetype="aws:cloudtrail" eventName="AssumeRole"
| spath output=assumedRoleArn path=requestParameters.roleArn
| spath output=sourceAccountId path=userIdentity.accountId
| where sourceAccountId != "YOUR_ACCOUNT_ID"
| stats count earliest(_time) as first_seen latest(_time) as last_seen values(assumedRoleArn) as roles_assumed by sourceAccountId, sourceIPAddress
| where count > 5
| sort - count

This query surfaces cross-account role assumptions originating from external AWS accounts. Filter sourceAccountId against your known vendor account list. Unexpected account IDs assuming roles in your environment - especially with high frequency or access to data-plane roles - warrant immediate investigation. False positive rate is low in environments that maintain an allow-list of trusted vendor account IDs.

References

Subscribe to The Identity Brief

Get The Identity Brief in your inbox (Mon/Wed/Fri) - Human, machine, and AI identity security — NHI, ITDR, and the IAM market.