At RSAC 2025, Miggo Security unveiled a critical vulnerability hiding in plain sight within cloud environments—an issue that challenges assumptions about one of cloud computing’s most trusted models: the Shared Responsibility Model. In their session, "Beauty and the ALBeast: Be Our (Shared Responsibility Model) Guest," Miggo's Head of Research, Liad Eliyahu, and CTO, Itai Goldman, exposed a flaw in the authentication architecture of AWS’s Application Load Balancer (ALB), prompting an industry-wide discussion on identity, trust, and cloud misconfigurations.
Uncovering the ALBeast
Miggo’s research revealed a deeply concerning reality: more than 15,000 potentially vulnerable ALB instances were discovered across major enterprises, governments, and cloud-native environments. The vulnerability allowed identity tokens issued by one ALB to be trusted by others in the same region, creating a situation where an attacker could forge authentication and gain access to otherwise protected systems..
The heart of the problem lies in token validation, or the lack thereof. ALB authentication, while powerful, relies on identity tokens that many implementations fail to fully validate. Specifically, organizations often skipped critical checks on the signer (who issued the token) and the issuer (who the token claims to represent). This oversight potentially allowed attackers to create their own ALBs, sign forged tokens, and present them as legitimate to vulnerable applications.
A Realistic Attack Path
Itai and Liad walked the RSAC audience through how an attacker could exploit the flaw in a real-world environment. By spinning up a malicious ALB and manipulating the token’s issuer field, the attacker could pass off a fake identity token as valid, even under configurations that appeared secure on the surface.
The presentation highlighted three critical weaknesses that needed to be chained together:
- Bypassing signer validation.
- Bypassing issuer validation.
- Exploiting permissive network access to deliver the forged token.
In combination, these weaknesses created a scenario where ALB-based authentication could be silently subverted without any obvious indicators, especially in environments without proper runtime monitoring.
Challenging the Cloud Shared Responsibility Model
One of the most impactful messages from Miggo’s session was not just about the vulnerability itself, but about the broader ecosystem failure that allowed it to persist. The flaw wasn’t buried in obscure code. It was a result of how identity and trust are managed between cloud providers and their customers.
After responsibly disclosing the issue to AWS in early 2024, Miggo learned that the initial fix came not through software changes or customer alerts, but via a quiet documentation update. Customers were expected to update configurations and validate tokens manually, without any proactive tooling, notification, or audit mechanisms provided by the platform.
This prompted a serious question: when a cloud provider silently updates documentation in response to a security issue, has the responsibility truly been shared?
Key Takeaways: Applying the Lessons from ALBeast
The ALBeast vulnerability was not just a technical concern. It exposed deeper architectural and operational flaws in how cloud identity is secured. Itai and Liad closed their RSAC 2025 session with a practical roadmap for both cloud providers and defenders. These key recommendations are:
For Cloud Providers:
Proactively communicate all security-related documentation changes.
Silent updates are not sufficient. Transparency must be a default setting when it comes to cloud security.
For Security Teams:
- Implement AWS ALB authentication best practices.
Ensure validation of token signers and issuers, and avoid default trust configurations. - Audit components where authentication logic is decoupled from the application.
Many systems rely on middleware for identity, which can become a blind spot if not continuously evaluated. - Continuously monitor cloud architecture for potential design flaws.
Misconfigurations, especially at the network or identity layer, can go unnoticed without structured reviews. - Adopt runtime monitoring across all identity and access flows.
Static checks and manual validation aren’t enough. Teams need live visibility into how authentication functions in production environments.
Miggo’s message was clear: securing cloud infrastructure requires both providers and customers to step up and share responsibility in a transparent, proactive way.
Driving Industry Change
The vulnerability, which Miggo dubbed the “ALBeast,” has since received multiple CVE designations and prompted broader investigations into ALB-based auth mechanisms. Among them:
- AWS CVE-2024-011
- AWS CVE-2024-012
- GCHQ Stroom CVE-2025-1293
- Hashicorp CVE-2025-129
AWS has since notified affected customers and introduced new security checks, with more changes expected through 2025. Miggo also launched AwsSecurityChanges.com, a resource to help track undocumented and silent security changes in cloud platforms, underscoring our commitment to visibility and education.
-with-Miggo-1.jpg)
