Navigating Lax Load Balancers: When an Intersection Gets You Inside
25 May 2026 - Posted by Francesco Lacerenza, Mohamed OuadAfter our last episode on Multi-SSO Cognito User Pools, we are back with another issue. This time, we are looking at one of those AWS components that is everywhere and rarely questioned deeply enough: the Elastic Load Balancer.
Tidbit No. 5 - Navigating Lax Load Balancers
What is AWS ELB?
AWS Elastic Load Balancing (ELB) distributes traffic to backend services and serves as the entry point between the Internet and your applications.
It supports Layer 7 routing (Application Load Balancer - ALB) and Layer 4 routing (Network Load Balancer - NLB). It decides where traffic goes and under which conditions. ELB is commonly found fronting multiple applications, environments, and trust zones across the same infrastructure.
Why It Matters
ELB is often the first public entry point before application backends, and in many AWS environments, it also becomes part of the access-control boundary. For ALBs, listener rules do more than route traffic: they can enforce authentication with authenticate-oidc or authenticate-cognito, restrict access with source-ip conditions, and decide which target group receives a request based on host, path, headers, or other request attributes.
The simplified flow below shows how a single request can be routed through different rules depending on priority and matching conditions:
That makes the listener rule chain security-sensitive. A backend may appear protected when looking at a single rule, but still be reachable through another rule, another listener, another ALB, or a direct network path that bypasses the expected entry point.
Misconfigurations there could:
- Expose backend services that were expected to be reachable only through specific hostnames, paths, or upstream controls
- Allow an authentication bypass when an unauthenticated rule forwards to the same targets as an authenticated route
- Bypass IP-based gates when the same target group or backend instances are reachable through another routing path without the same
source-iprestriction - Bypass CloudFront-level checks when an Internet-facing origin ALB remains directly reachable
Configuration vs. Real Exposure
Standard load balancer reviews usually focus on resource level hygiene: TLS policies, access logging, deletion protection, security groups, and whether a WAF is attached. These checks are useful, but they mostly describe how the load balancer is configured, without an offensive mindset.
They do not answer the important question: what can an external request actually reach?
What usually gets missed during load balancer audits:
- Routing logic issues that let traffic skip restrictive rules
- Backend targets that are directly reachable regardless of what the ALB listener enforces
- Real attack paths that are invisible to static config review
The Bugs
The following are some of the routing and exposure misconfigurations we encounter most often during AWS load balancer reviews. They are not the only possible ELB issues, but they are representative of a broader class of bugs where the configured routing graph does not match the intended security boundary.
1. CloudFront / WAF Bypass via Direct ALB Access
CloudFront is often placed in front of an ALB to enforce WAF rules, geo-restrictions, caching policies, or rate limiting. In this setup, the ALB is expected to behave like a private origin: users should reach it only through CloudFront, not directly.
The problem appears when the origin ALB is still Internet-facing and its security group allows public inbound traffic. In that case, an attacker could send requests directly to the ALB DNS name, bypassing every control enforced at the CloudFront layer, including WAF rules attached to the distribution.
2. Rule Shadowing
ALB listener rules are evaluated in ascending-priority order. A rule with priority 10 is evaluated before one with priority 20. If a broad rule (e.g., path /*) sits at priority 10 and a more restrictive rule (e.g., path /admin* with authenticate-oidc) sits at priority 20, all traffic to /admin matches the broad rule first. The auth action never fires.
(priority) (condition) (action)
[10] path /* → forward → tg-app (no auth)
[20] path /admin* → authenticate-oidc → tg-app (← never reached for /admin)
This is purely an ordering bug with a direct authentication bypass impact.
3. IP Gate Bypass via Alternate ALB
A common pattern is to restrict access to an Internal backend by placing a source-ip condition on the rule:
(priority) (condition) (action)
[10] source-ip 1.2.3.4/32 → forward → tg-internal-api
[default] → 403
That works only if the protected backend is not reachable through any other path. The issue appears when the same target group, or the same backend instances, are also registered behind another load balancer with weaker conditions.
When that alternate route exists, the source-ip gate is real, but it only protects one path to the backend. The backend remains exposed through the weaker route, where the same IP restriction is not enforced.
That demonstrates why listener rules cannot be reviewed in isolation. The key question is not only “Does this rule restrict access?” but “Is every path to these targets protected by a similar control?”
Infrastructure is not just configuration. It defines how traffic actually flows, and misconfigurations create unintended paths
Typical CSPM and audit checklists report on attributes - TLS version, logging flag, and WAF presence - but none of that tells you whether an /supposedly/protected/endpoint path is actually protected end-to-end, whether a CloudFront-fronted ALB is directly reachable, or whether the same backend instance appears in both a gated and an ungated rule.
That requires understanding the routing graph, not just the resource properties.
For Cloud Security Auditors
When reviewing an AWS account with ALBs, answer the following questions:
- For each internet-facing ALB: are there any Target Group members that are also registered in a different ALB or listener with weaker (or no) conditions?
- Is
routing.http.xff_header_processing.modeset topreserve? If yes, does any downstream service trustX-Forwarded-Forfor access decisions? - Walk listener rules in priority order. For each restrictive rule (auth action, source-ip), is there a broader rule at a lower priority number that matches the same traffic first?
- If a CloudFront distribution fronts an ALB, can you send HTTP or HTTPS directly to the ALB DNS and get a non-error response?
- For source-ip gated rules: enumerate all paths to the gated targets - same ALB on a different port, a different ALB in the same VPC, an NLB in front of the same instances.
For Developers
When ELBs are used widely across the infrastructure for routing, authentication, or IP-based restrictions, treat the ALB listener rule chain as part of your access-control model, not just networking configuration. Priority ordering matters as much as the conditions themselves. Review it the same way you would review middleware ordering in an application framework.
Do not treat a single IP gate as complete protection for a sensitive backend. A source-ip condition only protects the route where it is enforced. If the same targets are reachable through another ALB, listener, or port without equivalent restrictions, the backend may still be exposed. Combine source-ip conditions with authentication when possible, and verify that no alternate route reaches the same targets.
Lock down security groups on ALB origins. If a CloudFront distribution fronts an ALB, the ALB’s security group inbound rules should allow only CloudFront-managed prefix lists (com.amazonaws.global.cloudfront.origin-facing), not 0.0.0.0/0.
Set routing.http.xff_header_processing.mode to append or remove on Internet-facing ALBs. If the final backend uses client IP information for access-control decisions, rate limiting, audit logging, or security monitoring, do not allow clients to control the X-Forwarded-For header value.
Tool Release: ELBaph
Some of the issues above are hard to spot by looking at a single listener or load balancer in isolation. Finding them requires correlating listeners, rules, target groups, backend instances, and reachability across the whole ELB surface. Doing this manually is time-consuming and annoying, especially in large AWS accounts with a lot of load balancers.
This is why we built doyensec/ELBaph to automate exactly this.
It is a read-only CLI tool written in Go that maps ALBs, NLBs, listeners, rules, and targets into a single routing model. It then looks for exposed paths, runs targeted HTTP/HTTPS reachability probes, and generates a structured report with the root cause, exploit path, and remediation for each finding.
It works with SecurityAudit-style read-only permissions and outputs findings live to the terminal as each check completes, alongside a JSON, Markdown, or SARIF report and an interactive topology.html that maps the full routing graph from VPC to backend targets.
# Scan a region - findings printed live, output folder created automatically
elbaph scan --region us-east-1
# Scan multiple regions using an AWS profile
elbaph scan --all-regions -p my-pentest-profile
ELBaph gave us the extra leverage needed to scale manual ELB reviews. Let us know your feedback!
Hands-On IaC Lab
We also developed a Terraform (IaC) laboratory to deploy a vulnerable dummy application and play with the vulnerability: https://github.com/doyensec/cloudsec-tidbits/tree/main/lab-elbaph
The lab deploys two Internet-facing ALBs, a CloudFront distribution in front of the public one, and two EC2 instances running a small Go web application, showcasing a few of the misconfigurations described above.