Intruder finds AWS, Azure, Google Cloud flaws

Intruder analyzed 3,000 organizations running workloads on AWS, Azure and Google Cloud over the 12 months ending in July 2026, and found public exposure patterns and configuration mistakes that vary sharply across the three environments. The dataset summary shows 76% of accounts publicly exposed in AWS, 64% in Azure and 8% in Google Cloud, with different flaws in each case.

What did Intruder's index find?

Intruder grouped the findings into categories such as weak IAM controls, missing logging and alerts, misconfigured services, permissive firewalls, exposed services and weak encryption. Additional coverage of the 2026 cloud security index noted that more than two thirds of organizations now operate multi cloud environments, and that the main configuration risks are almost entirely different across AWS, Azure and Google Cloud, which makes coherent defense and control standardization harder.

In AWS, the main misconfiguration was S3 buckets that did not enforce HTTPS, which appeared in 87% of the cases cited in the summary. That was followed by an IAM policy that allowed privilege escalation, present in 83%. In Azure, the most frequent problem was storage account key rotation not being enabled, at 67%, followed by Entra ID users without MFA, at 55%.

In Google Cloud, the leading error was OS Login MFA not enabled, at 77%, followed by unused service accounts, at 75%. The pattern, according to Intruder's cited summary, shows that risk is not distributed evenly and that each provider exposes different surfaces, even inside organizations operating across multiple hyperscalers.

Why does this matter for multi cloud environments?

Because the material reviewed shows that public exposure and weak identity and access practices do not repeat in the same way across AWS, Azure and Google Cloud. In parallel, another analysis note on identity governance and containers, citing Intruder data, added that around 43% of evaluated cloud environments were affected by the Nginx Ingress Controller vulnerability set, with more than 6,500 clusters exposed publicly.

That data broadens the focus beyond hyperscaler native services and extends it to orchestration and edge components. For regional operators, the combination of public exposure, weak IAM controls and exposed container surfaces creates a fragmented risk map, with flaws that do not follow a single technical pattern.

What other alerts and patches were published for the region?

Microsoft published a Spanish-language notice for LATAM on CaptiveCrunch, malware that uses public Wi Fi for travelers, and included infrastructure indicators associated with adversary-in-the-middle activity on captive portals. The notice identified the domain M365-OWA[.]com, first seen on 2026-07-20, and also owa-ms365[.]com, first seen on 2026-07-16.

A regional technical analysis linked that campaign to the group tracked as UNC7005 or Storm 2945 and detailed that between July 16 and July 23, 2026, at least three domains impersonating Microsoft OWA were registered, owa-ms365[.]com, m365-owa[.]com and ms365-device[.]com, all later observed in CaptiveCrunch infrastructure. Microsoft said that infrastructure was being used on public Wi Fi captive portals.

In parallel, Shapeblue said Apache CloudStack 4.20.3.1 and 4.22.1.1 fix security issues including remote code execution, server side request forgery, cross site scripting, sensitive disclosure at the database level and unauthorized access to cloud resources. The patches address vulnerabilities documented in several official CVEs, including CVE-2026-50112, CVE-2026-59085 and CVE-2026-61422.

According to the notices and logs cited, some flaws allow SSRF in the webhooks module, while others enable remote code execution as root on KVM hypervisors through template or ISO registration with malicious metalinks and prior HEAD or GET requests before URL validation. The advisories for CVE-2026-59085 and CVE-2026-61422 say the impact reaches Apache CloudStack 4.20.0.0 through 4.20.3.0 and 4.21.0.0 through 4.22.1.0, and recommend updating to 4.20.3.1 or 4.22.1.1 or later.

The cited NVD records and CVE feeds add that part of these vulnerabilities is classified as critical because it allows SSRF to reach internal services and, when combined with RCE, enables lateral movement from a tenant to the hypervisor layer and other tenants. The impact mentioned extends to public or private multi tenant clouds used by regional providers.