CVE-2024-10125 Overview
CVE-2024-10125 is an Authentication Bypass vulnerability in the Amazon.ApplicationLoadBalancer.Identity.AspNetCore package, a middleware component used in conjunction with AWS Application Load Balancer (ALB) OpenId Connect integration. The vulnerability exists in the JWT handling code, which performs signature validation but fails to validate the JWT issuer and signer identity. This authentication bypass can potentially allow attackers to impersonate valid OIDC-federated sessions.
Critical Impact
This vulnerability allows attackers to potentially forge JWT tokens and mimic valid OIDC-federated sessions when ALB targets are exposed to internet traffic, enabling unauthorized access to protected resources.
Affected Products
- Amazon.ApplicationLoadBalancer.Identity.AspNetCore (deprecated/end of life)
- ASP.NET Core deployments using the affected middleware
- AWS deployments including Fargate, EKS, ECS, EC2, and Lambda using the vulnerable package
Discovery Timeline
- 2024-10-22 - CVE CVE-2024-10125 published to NVD
- 2025-10-14 - Last updated in NVD database
Technical Details for CVE-2024-10125
Vulnerability Analysis
The vulnerability resides in the JWT handling implementation within the AWS ALB Identity ASP.NET Core middleware. While the code properly validates JWT signatures, it critically fails to verify two essential claims: the JWT issuer and the signer identity. The signer omission is particularly dangerous when combined with misconfigured infrastructure that allows internet traffic to reach ALB targets directly.
In a properly secured environment, traffic should only flow through the ALB, which handles authentication. However, if ALB targets (such as EC2 instances or Fargate tasks) have public IP addresses and accept direct connections, an attacker could craft a JWT token signed by an untrusted entity. Since the middleware does not validate that the signer matches the expected ALB ARN, the malicious token would be accepted as valid.
This is categorized under CWE-290 (Authentication Bypass by Spoofing), as it allows an attacker to bypass authentication by presenting a spoofed JWT that appears legitimate due to the missing signer validation.
Root Cause
The root cause is the incomplete implementation of JWT validation in the middleware. Proper JWT validation requires verifying multiple claims including the signature, issuer (iss), audience (aud), expiration (exp), and in this case, the signer attribute that should match the ARN of the Application Load Balancer. The code only implements signature validation while omitting these critical identity verification steps.
Attack Vector
The attack vector is network-based and requires the following conditions:
- The target application uses the vulnerable Amazon.ApplicationLoadBalancer.Identity.AspNetCore middleware
- The ALB target infrastructure (EC2 instances, Fargate tasks, etc.) has public IP addresses or is otherwise accessible from the internet
- The attacker can craft a JWT token with a valid signature from any source
When these conditions are met, an attacker can:
- Generate a valid JWT token signed by their own key
- Send requests directly to the exposed ALB target, bypassing the ALB
- The middleware accepts the forged token because it only validates the signature exists, not who signed it
- The attacker gains access as if they were a legitimate OIDC-authenticated user
For detailed technical information, refer to the AWS Security Bulletin AWS-2024-012 and the GitHub Security Advisory GHSA-5gh5-cc5m-q244.
Detection Methods for CVE-2024-10125
Indicators of Compromise
- JWT tokens with unexpected or unknown signer attributes in application logs
- Authentication requests arriving directly at backend services bypassing the ALB
- Unusual session patterns or user activity that doesn't correlate with ALB access logs
- Requests to protected endpoints originating from IP addresses not associated with the ALB
Detection Strategies
- Compare source IP addresses of authenticated requests against known ALB IP ranges
- Implement logging to capture and analyze the signer attribute in all incoming JWT tokens
- Cross-reference application authentication logs with ALB access logs to identify discrepancies
- Monitor for direct connections to backend services that should only receive ALB-proxied traffic
Monitoring Recommendations
- Enable detailed CloudWatch logging for both ALB and backend targets to correlate traffic patterns
- Set up alerts for authentication attempts where the JWT signer does not match the expected ALB ARN
- Implement network flow logs to detect direct access attempts to backend resources
- Regularly audit security group configurations to ensure only ALB traffic reaches targets
How to Mitigate CVE-2024-10125
Immediate Actions Required
- Ensure all ELB targets (EC2 instances, Fargate tasks, etc.) do not have public IP addresses
- Configure security groups to only allow traffic from the Application Load Balancer
- If using forked or derivative code, immediately implement validation of the signer attribute against the expected ALB ARN
- Migrate away from the deprecated Amazon.ApplicationLoadBalancer.Identity.AspNetCore package to a supported solution
Patch Information
The Amazon.ApplicationLoadBalancer.Identity.AspNetCore repository and package has been deprecated, is end of life, and is no longer supported by AWS. There will be no official patch released for this vulnerability. Organizations must migrate to alternative solutions and implement the recommended security controls.
For official guidance, refer to the AWS Security Bulletin AWS-2024-012.
Workarounds
- Restrict network access to ALB targets using security groups that only permit inbound traffic from the ALB
- Deploy ALB targets in private subnets without public IP addresses or internet gateways
- Implement additional JWT validation logic in your application to verify the signer matches your ALB ARN
- Use AWS PrivateLink or VPC endpoints to ensure all traffic flows through controlled channels
# Example AWS CLI command to verify security group only allows ALB traffic
aws ec2 describe-security-groups --group-ids sg-your-target-sg \
--query 'SecurityGroups[*].IpPermissions[*].{FromPort:FromPort,ToPort:ToPort,Source:IpRanges[*].CidrIp,SourceSG:UserIdGroupPairs[*].GroupId}'
# Ensure your target security group references the ALB security group, not 0.0.0.0/0
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


