Lurking in the (documentation) shadows: Why We Built the AWS Security Changes Project

Lurking in the (Documentation) Shadows: Why We Built the AWS Security Changes Project

Speakers: Liad Eliyahu, Head of Research, Miggo Security

Conference: fwd:cloudsec Europe 2025

YouTube: https://www.youtube.com/watch?v=EQLyD9ZdQIk

Overview

Liad Eliyahu, head of research at Miggo Security, presented the story behind the AWS Security Changes project — an automated system that monitors all AWS documentation for security-relevant modifications, classifies them using a reasoning LLM, and makes them searchable at awssecuritychanges.com. The project was born from the discovery and disclosure of the ALBeast vulnerability, which revealed that AWS sometimes patches critical security issues through silent documentation changes without notifying affected customers. Eliyahu demonstrated how the project has already uncovered seven additional security issues, including multiple confused deputy vulnerabilities in AWS service logging configurations.

Background

▶ Watch: ALBeast introduction: authentication bypass affecting Fortune 500 companies a... (1:30)

In 2024, Miggo Security discovered ALBeast, a vulnerability in the AWS Application Load Balancer (ALB) authentication feature that allowed complete authentication bypass across thousands of organizations, including Fortune 500 companies and governmental agencies. ALBeast resulted in four distinct CVEs: two in AWS's own libraries, one in HashiCorp, and one at GCHQ (the UK's intelligence agency).

The ALB authentication feature allows customers to offload authentication to the load balancer level. When a user authenticates through a configured Identity Provider (Okta, Google, Microsoft, etc.), the ALB exchanges the authentication code for tokens, sets an encrypted session cookie, and then signs a new ALB token containing user claims. The application must validate this ALB token to ensure legitimate authentication.

The critical design flaw was architectural: the public key server used to validate ALB-signed tokens is shared across all tenants in a region. Every ALB instance in a region signs tokens using keys stored in the same regional endpoint, and any application can access any other application's public keys. AWS added a non-standard signer field to the JWT token (containing the ARN of the signing ALB), but this field was not part of the OpenID standard and was not documented in a way that made validation obvious.

When Miggo examined AWS's documentation, the code examples for token validation did not include signer field validation. This meant an attacker could forge tokens using their own ALB's keys, and any application in the region following AWS's official documentation would accept them as valid.

Key Findings

▶ Watch: Shared regional public key server means every ALB in a region can forge token... (6:00)

The Silent Documentation Patch Pattern

When Miggo reported ALBeast to AWS in April 2024, AWS began investigating and within a month made the first documentation change — adding a corrected code example with signer validation and instructing customers to configure the specific ARN of their ALB instance. However, AWS made this change without notifying anyone, not even the researchers who reported the vulnerability. Customers had no way to know their authentication implementations were vulnerable or that the documentation had changed.

After continued discussions, AWS made a second documentation change, recommending that applications configure their target groups to only receive traffic from the ALB — a more manageable mitigation than patching application code. But again, no customer notification.

Only after Miggo contacted potentially vulnerable customers directly and gathered feedback about the difficulty of code-level patching did AWS finally implement proactive notifications: push notifications to vulnerable customers and health dashboard warnings for newly vulnerable ALB configurations.

The Same Pattern in AWS Verified Access

The AWS Verified Access service — a zero-trust solution — shared the same authentication architecture as ALB and therefore shared the same vulnerability. AWS silently updated the Verified Access documentation to add signer field validation guidance without notification, confirming that the pattern of documentation-only patches was not a one-time event.

The AWS Security Changes Project

Recognizing that silent documentation patches likely occur across many AWS services, Miggo built an automated monitoring system:

1. Crawling: All AWS documentation is crawled periodically.
2. Normalization: Pages are converted to Markdown format to filter out cosmetic changes (formatting, layout) that don't affect content.
3. Diffing: git diff compares the current version against the previous pull.
4. LLM Classification: All detected changes are sent to a reasoning LLM that determines whether each change has potential security impact and whether it's security-related at all.
5. Storage and Search: Enriched changes are stored in a database and presented on the awssecuritychanges.com website with full search capabilities.

ELB Logging Confused Deputy Discovery

Using the project, Miggo found a documentation change in the ELB logging mechanism that appeared to be a "clarification" about including the account ID in an S3 bucket resource name for an IAM policy. In reality, this was a silent fix for a confused deputy vulnerability.

The previous version of the documentation instructed customers to allow the log delivery service full write access to their S3 buckets. The log delivery service is shared across all AWS tenants. This meant any AWS account could configure its ELB to write logs to any other account's S3 bucket — if that bucket followed the documented IAM policy. The impact included wallet draining (unrestricted resource consumption on the victim's bucket) and potential data injection.

The fix added a warning instructing customers to include their account ID in the S3 resource ARN and avoid wildcards, ensuring that only their own ELBs could write to their buckets.

Miggo found four additional confused deputy issues using the same project, all following the pattern of IAM policies in documentation that granted overly broad permissions to shared AWS services.

Technical Deep Dive

▶ Watch: AWS silently patched the documentation without notifying customers or the res... (9:30)

ALBeast Token Forgery Mechanics

The ALB token validation flow has three critical security-relevant fields:

• issuer: The IDP that originally authenticated the user (e.g., Google). Part of the OpenID standard.
• signer: The ARN of the ALB that signed the token. A non-standard AWS extension that was undocumented as a required validation field.
• sub/email: User identity fields that the application uses for authorization decisions.

The public key URL is assembled from a static base URL plus a key ID parameter supplied by the token itself: https://public-keys.auth.elb.{region}.amazonaws.com/{key-id}. Since the base URL is shared regionally and the key ID can point to any ALB's public key, an attacker who controls an ALB in the same region can sign tokens that any other application will validate.

Miggo further discovered an issuer forgery vulnerability that allowed forcing the ALB to sign tokens with an attacker-controlled issuer field, completing the full authentication bypass chain.

Searching for Confused Deputies at Scale

The AWS Security Changes project enables keyword-based searching across all documentation changes. For confused deputy vulnerabilities, researchers can search for IAM policy keywords — principal names, permission actions, resource ARN patterns — to identify documentation changes where shared service principals were granted overly broad access. The four additional confused deputy findings all came from this search pattern, making the project a force multiplier for vulnerability research.

Demo / Proof of Concept

▶ Watch: AWS Security Changes project architecture: crawl, normalize, diff, LLM classi... (12:00)

Eliyahu walked through the AWS Security Changes website, showing the search interface and drilling into the ELB logging confused deputy finding. He displayed the before-and-after documentation, highlighting the added warning box and modified IAM policy. The ALBeast vulnerability was demonstrated through architecture diagrams showing the shared regional key server and the token validation flow.

Defensive Implications

▶ Watch: Four additional confused deputy vulnerabilities found through the project's I... (16:00)

• Monitor AWS documentation changes actively. The AWS Security Changes project (awssecuritychanges.com) provides free, community-driven monitoring of security-relevant documentation modifications.
• Do not assume AWS RSS feeds capture all security changes. The project found changes that did not appear on AWS's official RSS feed.
• Validate the signer field in ALB authentication tokens. If your application uses ALB authentication integration, ensure your token validation code checks that the signer ARN matches your specific ALB instance.
• Configure ALB target groups to accept traffic only from the ALB. This is the most manageable mitigation for ALBeast, as it doesn't require application code changes.
• Audit IAM policies derived from AWS documentation for confused deputy risks. Any policy that grants a shared AWS service broad write access to your resources (especially S3 buckets) without scoping to your account ID is potentially vulnerable.
• Avoid wildcards in IAM resource ARNs for policies involving shared AWS service principals.
• Review your Verified Access token validation if using the AWS Verified Access zero-trust service — the same signer validation gap applied.
• Treat documentation changes as potential security patches. AWS may not always proactively notify customers of security-relevant documentation updates.

Key Takeaways

• AWS patches security vulnerabilities through silent documentation changes — without notifying affected customers or even the researchers who reported the issues.
• ALBeast allowed complete authentication bypass across thousands of organizations by exploiting a shared regional public key server and missing signer field validation guidance in AWS documentation, resulting in four CVEs.
• The confused deputy vulnerability class is prevalent in AWS documentation, with at least five instances found where shared service principals were granted overly broad IAM permissions in official code examples.
• awssecuritychanges.com provides automated, LLM-classified monitoring of all AWS documentation changes, enabling the community to detect silent security patches.
• AWS's official RSS feed does not capture all security-relevant changes — the ground truth is what customers actually see in the documentation, not what appears in notification feeds.

About the Speaker(s)

Liad Eliyahu is the head of research at Miggo Security, bringing eight years of vulnerability research experience. He led the discovery and disclosure of the ALBeast vulnerability in AWS ALB authentication and subsequently created the AWS Security Changes project to systematically detect silent documentation-based security patches across the AWS ecosystem.