Two reports landed within days of each other in August 2026, and together they paint a rough picture for anyone running workloads on AWS, Azure, or Google Cloud. The first, Intruder’s 2026 Cloud Security Index, scanned misconfiguration data from roughly 3,000 organizations and found weak identity and access management (IAM) controls or missing logging in 80% to 98% of cloud accounts, depending on the provider. The second, from threat intelligence firm CloudSEK, traced a supply chain attack through a popular AI gateway library that exposed cloud credentials, SSH keys, and Kubernetes tokens across more than 2,500 organizations and roughly 434,000 CI/CD pipelines.

Neither story is really new on its own. Misconfigured S3 buckets and over-permissioned IAM roles have been showing up in breach reports for a decade. What makes August 2026 different is the scale and the speed: a single compromised package sat on PyPI for about 40 minutes and still managed to touch nearly half a million automated pipelines before anyone caught it. That combination, chronic IAM neglect plus a fast-moving AI supply chain attack, is why cloud IAM misconfiguration has become the topic security teams can’t stop talking about this month.

A Fractured Picture: What the 2026 Cloud Security Index Found

Intruder’s 2026 Cloud Security Index is the most detailed cross-cloud misconfiguration study published this year. The company analyzed data from 3,000 organizations running workloads on AWS, Azure, and Google Cloud over the twelve months ending in July 2026, and it grouped findings into six categories: weak IAM controls, missing logging and alerting, misconfigured services, permissive firewalls, exposed services, and weak encryption.

The headline number, cited by Help Net Security, is stark: weak IAM controls and missing logging affect 80% to 98% of accounts, no matter which provider hosts them. But the report’s more useful finding is that the specific failures barely overlap between AWS, Azure, and Google Cloud. Each platform has its own set of default-on risks, which means a security team that hardens one cloud well can still walk into a completely different set of gaps on another. Average remediation time across the dataset stretched to 35 days, long enough for an exposed credential or an open port to sit there waiting for a scan.

AWS’s Misconfiguration Problem, By the Numbers

AWS came out of the Intruder study with the highest prevalence of misconfigurations in five of the six categories the report measured. Some 76% of AWS accounts had at least one publicly exposed service, well above Azure’s 64% and far above Google Cloud’s 8%. The single most common individual issue was S3 buckets that don’t enforce HTTPS, found in 87% of AWS accounts scanned. Close behind: permissive ingress to sensitive ports via network ACLs (84%), overly permissive network ACLs generally (83%), and IAM policies that allow privilege escalation (83%).

Other common AWS gaps included accounts where S3 block-public-access wasn’t enabled at the account level (81%), VPC subnets that auto-assign public IPs (72%), root access that isn’t centrally managed (72%), IAM policies attached directly to individual users instead of roles (71%), and IAM access keys that haven’t been rotated (71%). None of these are exotic bugs. They’re default settings and habits that accumulate quietly until a scanner, or an attacker, goes looking.

Azure’s Storage and Identity Gaps

Azure’s weak spots cluster around storage accounts and Entra ID (formerly Azure AD). Intruder found that 67% of Azure accounts hadn’t enabled storage account key rotation, 66% still had storage account access keys enabled rather than relying on Entra-based authentication, and 61% allowed public network access to storage accounts. On the identity side, 55% of Azure accounts had at least one Entra user without multi-factor authentication turned on, a gap that’s been on security checklists for years but clearly hasn’t closed.

Key Vault configuration showed up repeatedly too: 41% of accounts had Key Vault secrets set to never expire, another 41% hadn’t disabled public network access to Key Vault, and 38% had vaults that weren’t configured to be recoverable if deleted. Compared to AWS, Azure’s exposure numbers run lower across the board, but 64% of accounts with at least one publicly exposed service is still a large attack surface for any enterprise running production workloads.

Google Cloud’s Smaller, But Real, Exposure

Google Cloud posted by far the lowest public exposure rate in the study, at 8% of accounts, and outside observers have pointed to that gap as evidence of tighter default settings. That doesn’t mean GCP is clean. Intruder found that 77% of projects hadn’t enabled multi-factor authentication for OS Login, 76% hadn’t enabled OS Login at all (leaving SSH key management scattered across individual instances), and 75% had at least one unused service account still active.

Over-permissioned service accounts showed up in 53% of projects, and permissive ingress to sensitive ports appeared in 34%, notably lower than the equivalent AWS and Azure figures. Service account keys that hadn’t been rotated (31%) and unused service account keys (29%) rounded out the top issues. The pattern across all three clouds is consistent even where the specific numbers differ: identity hygiene lags behind network hygiene, and unused credentials rarely get cleaned up until an audit forces the issue.

Provider Comparison: Where Each Cloud Falls Short

The table below pulls the top misconfiguration and the public exposure rate for each provider directly from Intruder’s dataset, so security teams can see at a glance where their own environment is most likely to have drifted.

Cloud ProviderAccounts With Public ExposureTop MisconfigurationPrevalenceSecond IssuePrevalence
AWS76%S3 buckets not enforcing HTTPS87%IAM policy allows privilege escalation83%
Azure64%Storage account key rotation not enabled67%Entra ID users without MFA55%
Google Cloud8%OS Login MFA not enabled77%Unused service accounts75%

Source: Intruder 2026 Cloud Security Index, based on scans of 3,000 organizations across AWS, Azure, and Google Cloud.

The LiteLLM Breach: How One Package Hit 434,000 Pipelines

While the Intruder report describes chronic, slow-moving risk, the second story broke fast. In March 2026, a cybercriminal group tracked as Team PCP compromised the build pipeline for LiteLLM, an open-source AI gateway library used by companies to route requests across multiple LLM providers. They pushed two malicious versions of the package to PyPI. CloudSEK, which published its full technical writeup in August, calls it the largest AI infrastructure supply chain breach of the year.

The malicious packages were live for roughly 40 minutes before they were pulled, according to CloudSEK’s timeline and coverage from SecurityWeek. That’s a short window by most standards, but automated CI/CD systems don’t wait for a human to notice. Build pipelines pulled the poisoned package automatically, and the malicious code propagated across an estimated 434,000 CI/CD pipelines tied to more than 2,500 organizations before detection caught up.

Inside the Attack: TeamPCP, SANDCLOCK, and a 40-Minute Window

CloudSEK’s analysis describes a stealer component, tracked by Google as SANDCLOCK, bundled inside the compromised LiteLLM releases. Once a CI runner pulled the package, the stealer escalated privileges and began harvesting whatever secrets it could reach: SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, and environment files, including some values that platforms like GitHub Actions normally mask in logs, scraped directly from process memory. A related self-propagating component, referenced in some coverage as CanisterWorm, helped the exposure spread across connected pipelines.

This is the part that connects the two stories. A stolen Kubernetes token or an unrotated AWS access key, exactly the kind of gap Intruder’s index found sitting unaddressed in 71% to 83% of accounts, is what turns a 40-minute supply chain compromise into a foothold that can persist for months. The breach didn’t need to defeat strong security. It needed the weak IAM hygiene that’s already the norm.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

That kind of wildcard IAM policy, action “*” on resource “*”, is exactly the pattern Intruder’s scanners flag as “IAM policy allows privilege escalation.” It’s a common shortcut during initial setup that rarely gets tightened later, and it’s precisely the kind of credential a stealer like SANDCLOCK is built to find and exfiltrate.

What Attackers Actually Stole

DetailFigure / Description
Compromise windowMalicious packages live on PyPI for approximately 40 minutes
Original compromise dateMarch 2026
Public disclosureAugust 2026, via CloudSEK research
Organizations potentially impactedMore than 2,500
CI/CD pipelines affectedApproximately 434,000
Data types exfiltratedSSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, CI/CD secrets and .env files
AttributionCybercriminal group tracked as Team PCP; stealer component tracked by Google as SANDCLOCK

Source: CloudSEK and SecurityWeek reporting, August 2026.

Why IAM Keeps Failing at Scale

The recurring theme across both reports is that IAM is treated as a one-time setup task rather than an ongoing discipline. Teams provision a role with broad permissions to unblock a launch, mean to scope it down later, and never circle back. Multiply that habit across a company running hundreds of microservices and dozens of CI/CD pipelines, and you get exactly the picture Intruder found: unused access keys still active, IAM policies attached to individual users instead of managed roles, and root access that nobody is centrally tracking.

Multi-cloud environments make the problem worse, not better. Intruder’s report notes that misconfigurations barely overlap between AWS, Azure, and Google Cloud, which means the checklist a security team builds for one provider doesn’t transfer cleanly to the next. A DevOps engineer who’s fluent in tightening S3 bucket policies may have no instinct for Azure’s Entra ID quirks or GCP’s OS Login settings. That knowledge gap, multiplied across a growing number of companies running true multi-cloud stacks, is a big part of why the aggregate numbers stay stubbornly high year after year.

The Price Tag: IBM’s $4.99 Million Benchmark

None of this matters much until it turns into a bill. IBM’s 2026 Cost of a Data Breach report, covered by Help Net Security, puts the global average cost of a data breach at $4.99 million, a record high and a 12% jump over the prior year. IBM’s own X-Force analysis ties part of that increase to AI-powered adversaries moving faster than traditional detection and response cycles can keep up with.

That $4.99 million figure is an average across breach types, not a cloud-specific number, but the mechanics line up with what happened in the LiteLLM incident. A compromised credential sitting in a CI/CD pipeline for weeks or months, exactly the kind of exposure created when a stolen AWS key or Kubernetes token goes undetected, is the scenario that drives breach costs up. The longer an intrusion goes undiscovered, the more it costs to contain, and Intruder’s 35-day average remediation window for cloud misconfigurations gives attackers plenty of runway.

Historical Context: A Decade of “The Customer’s Fault”

Cloud misconfiguration has been flagged as a leading breach cause for years under the shared responsibility model, where the provider secures the underlying infrastructure and the customer is responsible for how they configure it. That framing dates back to warnings from analysts earlier in the decade that the overwhelming majority of cloud security failures would trace back to customer-side mistakes rather than provider outages or platform flaws.

What’s changed by 2026 isn’t the root cause, it’s the blast radius. A misconfigured S3 bucket in 2018 exposed one company’s data. A compromised open-source package sitting inside thousands of automated build pipelines in 2026 can expose 2,500 companies in the time it takes to grab coffee. The shared responsibility model hasn’t moved, but the automation layered on top of cloud infrastructure has made the consequences of a single lapse spread far wider and far faster than they used to.

Market Impact: CSPM Vendors, Insurers, and Vendor Silence

Cloud security posture management (CSPM) vendors, the tools built specifically to scan for exactly the kind of misconfigurations Intruder catalogued, are the most direct commercial beneficiaries of this news cycle. Expect procurement conversations at mid-size and enterprise companies to accelerate as security leaders use the 80-98% figure to justify budget for continuous scanning rather than periodic manual audits.

Cyber insurers are also likely to tighten underwriting questionnaires around IAM hygiene and software supply chain controls, following the same pattern seen after previous high-profile breaches. What’s notably absent so far is any on-record statement from AWS, Microsoft Azure, or Google Cloud security teams directly addressing either the Intruder index or the LiteLLM breach. Given that both stories point at customer-side configuration rather than platform vulnerabilities, providers have less incentive to comment quickly, but the silence leaves security teams without official guidance at the moment they most want it.

Competitive Comparison: AWS vs Azure vs GCP Security Posture

Read together, the numbers suggest a rough hierarchy, but not a simple one. Google Cloud’s 8% public exposure rate looks dramatically better than AWS’s 76% or Azure’s 64%, and outside coverage from outlets like Tech-Insider has framed it as evidence of stronger secure-by-default settings. But GCP’s own top issue, OS Login MFA not enabled at 77% of projects, shows that identity hygiene lags there too. It’s a smaller surface, not a solved problem.

AWS’s breadth of market share means its misconfiguration numbers carry more real-world weight simply by volume of deployments. Azure sits in the middle on exposure but shows a distinctive weakness around storage account keys and Entra ID MFA that doesn’t map cleanly onto either of its rivals. For teams running true multi-cloud stacks, as covered in our AWS vs Azure vs GCP comparison, the practical takeaway is that a single security checklist won’t cover all three platforms. Each one needs its own hardening pass.

What Security Teams Should Do Now

Neither report calls for exotic new tooling. The fixes map directly onto the misconfigurations found: enforce HTTPS on every S3 bucket, audit IAM policies for wildcard permissions, rotate access keys on a fixed schedule, enable MFA everywhere including service and admin accounts, and turn on centralized logging so unusual API calls get flagged instead of discovered 35 days later.

  • Run a cross-cloud IAM audit specifically for wildcard (“*:*”) policies and unused access keys older than 90 days
  • Pin dependency versions in CI/CD pipelines and enable package-signature verification for anything pulled from public registries like PyPI
  • Rotate CI/CD secrets on a fixed schedule rather than only after a suspected incident
  • Enable MFA on every account type, including service accounts and non-human identities where the provider supports it
  • Adopt least-privilege roles instead of attaching policies directly to individual IAM users, following guidance from Kubernetes’ own security documentation for cluster-level identity as well

Teams already running container security hardening programs have a head start, since much of the discipline required to lock down Kubernetes clusters, scoped service accounts, rotated tokens, network policy enforcement, overlaps directly with what the Intruder index recommends for IAM generally. The OWASP Top 10 remains a useful baseline reference for teams building or updating an internal cloud hardening checklist.

Predictions: Where Cloud IAM Security Goes From Here

Based on the trajectory of both stories, here’s how the next two quarters are likely to play out.

  1. CSPM adoption accelerates at mid-market companies. The 80-98% figure is quotable enough to move budget conversations that had stalled, particularly at companies under 1,000 employees that previously treated CSPM as an enterprise-only tool.
  2. Package registries add mandatory provenance checks. Expect PyPI, npm, and similar registries to face renewed pressure to require signed releases or delayed publication windows after a breach that spread through a 40-minute exposure window.
  3. Non-human identity governance becomes its own budget line. Service accounts, CI/CD tokens, and API keys already outnumber human users in most cloud environments, and the LiteLLM breach makes the case for treating them as a distinct security category rather than an IAM afterthought.
  4. Cloud providers publish updated default-security guidance, but stay quiet on direct commentary. Given the shared responsibility framing, expect quieter blog-post-level guidance rather than public acknowledgment tied to either specific report.
  5. Cyber insurance premiums tied to IAM audit results become more common. Insurers are likely to start asking for CSPM scan results as part of underwriting, mirroring how ransomware-driven policies evolved after 2021.

Frequently Asked Questions

What is the 2026 Cloud Security Index?

It’s a report published by security scanning company Intruder, based on misconfiguration data collected from 3,000 organizations running AWS, Azure, and Google Cloud over the twelve months ending in July 2026. It found weak IAM controls or missing logging in 80% to 98% of accounts, with the specific weak points differing sharply by provider.

Which cloud provider has the most security misconfigurations?

AWS had the highest prevalence of misconfigurations in five of six categories Intruder measured, with 76% of accounts showing at least one publicly exposed service. Azure followed at 64%, and Google Cloud had the lowest exposure rate at 8%, though it still showed high rates of missing MFA on OS Login (77%).

What was the LiteLLM supply chain attack?

In March 2026, a group tracked as Team PCP uploaded two malicious versions of the LiteLLM open-source package to PyPI. The packages contained a stealer component, tracked by Google as SANDCLOCK, that harvested cloud credentials, SSH keys, and Kubernetes tokens from any CI/CD pipeline that pulled them. CloudSEK disclosed the incident publicly in August 2026.

How many organizations were affected by the LiteLLM breach?

CloudSEK estimates more than 2,500 organizations and roughly 434,000 CI/CD pipelines were potentially exposed, even though the malicious packages were only live on PyPI for about 40 minutes before being pulled.

What data did the LiteLLM attackers steal?

According to CloudSEK’s analysis, the stealer component collected SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, and CI/CD secrets, including values from .env files and masked environment variables scraped directly from process memory on compromised build runners.

How much does a data breach cost in 2026?

IBM’s 2026 Cost of a Data Breach report puts the global average at $4.99 million, up 12% year over year and a record high. The figure covers breaches broadly rather than cloud-specific incidents, but longer detection and remediation windows, like the 35-day average Intruder found for cloud misconfigurations, are a consistent driver of higher costs.

Is Google Cloud more secure than AWS or Azure?

Google Cloud showed a much lower public exposure rate (8% versus 76% for AWS and 64% for Azure) in Intruder’s study, suggesting stronger secure-by-default settings. It still showed high rates of other issues, like OS Login MFA gaps in 77% of projects, so it isn’t free of misconfiguration risk.

What should security teams do first after these reports?

Start with an IAM audit for wildcard permissions and unrotated access keys, enable MFA across all account types including service accounts, and add provenance or signature checks for any open-source packages pulled automatically into CI/CD pipelines.