In August 2024, a security flaw dubbed ALBeast captivated the cloud security world when Miggo Security revealed that thousands of applications were vulnerable not due to a software bug, but to a critical configuration oversight in Amazon Web Services’ Application Load Balancer (ALB) authentication flows.
The ALBeast Breakdown
To understand ALBeast, you first need to know what an ALB is. It’s a Layer 7 AWS service that routes HTTP traffic based on the request content, such as the URL path or headers, rather than just the IP or port. It’s one of AWS’s most widely used services.
A key feature, introduced in 2018, is built-in user authentication using popular identity providers such as Google, Okta, Microsoft, and Facebook. This allows developers to shift the authentication step from the application to the ALB itself.
Here’s how it works: when a user tries to access an app behind an ALB, they’re first redirected to the identity provider to log in. Once the user authenticates, the ALB exchanges their auth code for an access token and sets an encrypted session cookie. On future requests, the ALB reads the cookie, signs a new JWT token containing the user’s identity and permissions, and forwards it along with the request to the backend application.
The backend is responsible for verifying this token before responding. Three key fields in the token are:
- Issuer: the identity provider used for authentication
- User claims: usernames or roles
- Signer: identifying which specific ALB signed the token
While issuer and claims follow standard JWT specs, the signer is not standardized, which makes it a weak point. If the application doesn’t verify that the signer matches the expected ALB, attackers can impersonate a legitimate ALB and forge tokens.
With this mechanism in place, the flaw behind ALBeast and how Miggo detected it comes into view.
Miggo’s Early Detection and the High-Profile AWS Flaw
While analyzing ALB authentication, Miggo’s research team discovered a critical flaw: the public key server used to validate ALB tokens is shared across all tenants in the same AWS region. This meant that any application using ALB could validate tokens signed by any other app in the same region.
At the center of this flaw was a custom JWT field AWS introduced called signer, which includes the ARN of the ALB that signed the token. Unlike the standard issuer field, the signer isn’t part of the OpenID or OAuth 2.0 specs, and AWS didn’t document it properly. As a result, most applications had no logic to verify the signer field.
Here’s how the exploit works: when a user authenticates via ALB, the ALB signs a token with its private key and publishes the public key to a shared regional endpoint. That endpoint’s base URL is the same for all apps—only the key ID changes, and the user can choose the key ID.
Miggo’s security researchers realized this meant an attacker could upload a public key to their own ALB, then forge a token and trick another app into accepting it, because the app would fetch the key from the shared server without verifying that the signer matched its own ALB.
Even worse, AWS documentation never instructed developers to validate this field. That omission created a blind spot that left countless applications unknowingly exposed.
That is, until Miggo raised the alarm.
Widespread Impact: A Silent Risk in the Open
Once Miggo identified the flaw, they scanned the open-source ecosystem to assess its real-world impact, and the results were alarming.
They identified 154 open-source projects utilizing the ALB authentication feature, many of which had thousands of GitHub stars and numerous forks. All of these projects were vulnerable to some degree.
- 66% were vulnerable by default, as they performed no validation of either the issuer or the signer field.
- The remaining 34% did validate the issuer but still skipped signer validation, leaving them exposed to forged tokens.
You might wonder: if they checked the issuer, why were they still at risk?
Because the attacker didn’t need to fake the issuer, they could use a legitimate identity provider, sign the token using their own ALB, and bypass application checks that ignored the signer. Without verifying that the token came from a trusted ALB, those applications were still open to impersonation.
Miggo’s conclusion was clear: even well-intentioned security checks weren’t enough. The flaw was systemic and silently embedded in production environments everywhere.
Real-World Impact: CVEs and Global Recognition
To raise awareness, Miggo’s research team worked with AWS to publish the ALBeast findings to the broader security community in August 2024. The research quickly gained traction, making headlines in Forbes, SecurityWeek, and WIRED, and igniting urgent conversations around the shared responsibility model of cloud providers.
Since then, the flaw has led to four official CVEs:
- Two in AWS-owned libraries
- One affecting a library used by GCHQ, the UK’s intelligence agency
- One tied to a widely adopted open-source project
Several other vulnerabilities remain private or pending disclosure.
Miggo’s discovery has also been recognized by HashiCorp, GCHQ, and security teams across the cloud community.
From Exposure to Empowerment
The ALBeast flaw exposed a critical, undocumented gap in cloud authentication: one that quietly left major applications vulnerable across regions and industries. But Miggo didn’t stop at disclosure.
To help the community stay ahead of similar risks, Miggo launched the AWS Security Changes Project, a public resource tracking undocumented or subtle shifts in AWS behavior. Since its launch, it has attracted tens of thousands of visitors, becoming a go-to tool for developers and security teams worldwide.
ALBeast was a wake-up call. Miggo’s response transformed it into a blueprint for improved cloud hygiene, one that is proactive, transparent, and community-driven.
Key Takeaways
- For cloud providers: While they’re not obligated to disclose every security change, they should. Clear documentation of security-related updates is critical. AWS’s recent steps toward more transparency are a move in the right direction.
- For security teams: Narrow your attack surface, audit where authentication is decoupled from the app, and monitor behavior at runtime. Moreover, track documentation changes, as subtle updates in cloud provider docs can introduce or expose new risks. Miggo’s AWS Security Changes Project helps teams stay ahead by flagging security-relevant changes as they happen.
Staying secure in the cloud isn’t just about hardening components. It’s about understanding behaviors that only reveal themselves at runtime.
