How hardcoded AWS Access Key ID exposure happens in YAML template files and how to fix it

How Hardcoded AWS Access Key ID Exposure Happens in YAML Template Files and How to Fix It

Introduction

In the nuclei templates repository, we discovered a high-severity hardcoded AWS Access Key ID embedded within http/cves/2024/CVE-2024-51482.yaml at line 15. The file is a nuclei security scanning template for ZoneMinder's CVE-2024-51482 SQL injection vulnerability, but ironically, the template itself contained a security flaw: a pre-signed Amazon S3 URL with a fully exposed AWS Access Key ID (AKIAVCODYLSA53PQK4ZA) committed directly to the repository.

This matters because anyone with access to the repository—which in the case of nuclei-templates is the entire internet—can extract this credential and potentially use it to access AWS resources associated with the AKIAVCODYLSA53PQK4ZA key.

The Vulnerability Explained

The vulnerable code was a reference URL in the template's metadata section:

reference:
  - https://securityonline.info/zoneminders-cve-2024-51482-a-10-10-severity-vulnerability-exposes-sql-databases/
  - https://github-production-user-asset-6210df.s3.amazonaws.com/104687644/381894613-3cc50e51-68cf-4540-8225-4288f73e0c08.mp4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20241129%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20241129T074108Z&X-Amz-Expires=300&X-Amz-Signature=9cc5b01b0482cbd5573c223a1d44e9ffed10afd7d042d76e8308dfcf3bb7e8a5&X-Amz-SignedHeaders=host
  - https://nvd.nist.gov/vuln/detail/CVE-2024-51482

The problematic element is the X-Amz-Credential query parameter, which contains:

AKIAVCODYLSA53PQK4ZA%2F20241129%2Fus-east-1%2Fs3%2Faws4_request

When URL-decoded, this reveals the full credential scope:

AKIAVCODYLSA53PQK4ZA/20241129/us-east-1/s3/aws4_request

Why This Is Dangerous

AWS Access Key IDs follow a predictable format: they start with AKIA followed by 16 uppercase alphanumeric characters. This makes them trivially detectable by automated scanners and malicious actors who scrape public repositories.

Attack Scenario: An attacker monitoring public commits to the nuclei-templates repository could:

1. Extract AKIAVCODYLSA53PQK4ZA from the YAML file
2. Pair it with any leaked or brute-forced secret access key associated with this ID
3. Attempt to access the GitHub production S3 bucket (github-production-user-asset-6210df.s3.amazonaws.com)
4. Even without the secret key, the access key ID itself reveals the AWS account structure and can be used for reconnaissance

While pre-signed URLs are designed to be temporary (this one had a 300-second expiry), the Access Key ID itself is a long-lived credential that doesn't expire with the URL. It identifies the IAM user or role and can be used in targeted attacks against the associated AWS account.

The Fix

The fix is straightforward but effective: the entire pre-signed S3 URL was removed from the reference list.

Before:

reference:
  - https://securityonline.info/zoneminders-cve-2024-51482-a-10-10-severity-vulnerability-exposes-sql-databases/
  - https://github-production-user-asset-6210df.s3.amazonaws.com/104687644/381894613-3cc50e51-68cf-4540-8225-4288f73e0c08.mp4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20241129%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20241129T074108Z&X-Amz-Expires=300&X-Amz-Signature=9cc5b01b0482cbd5573c223a1d44e9ffed10afd7d042d76e8308dfcf3bb7e8a5&X-Amz-SignedHeaders=host
  - https://nvd.nist.gov/vuln/detail/CVE-2024-51482

After:

reference:
  - https://securityonline.info/zoneminders-cve-2024-51482-a-10-10-severity-vulnerability-exposes-sql-databases/
  - https://nvd.nist.gov/vuln/detail/CVE-2024-51482

Why This Change Works

1. Eliminates the credential from the codebase: The AWS Access Key ID no longer exists in the current version of the file
2. Preserves functionality: The removed URL was a reference link to a demo video—not essential for the template's scanning capability
3. Retains useful references: The SecurityOnline article and NVD links remain, providing adequate context for the CVE
4. Reduces attack surface: No AWS credentials of any kind remain in the template

The pre-signed URL was likely copied directly from a browser's address bar when someone was viewing a proof-of-concept video on GitHub. This is a common mistake—GitHub generates pre-signed S3 URLs for user-uploaded assets, and developers inadvertently commit these URLs without realizing they contain embedded credentials.

Prevention & Best Practices

For Template and Configuration Authors

1. Never paste pre-signed URLs into committed files: If you need to reference an S3-hosted asset, use the permanent GitHub URL (e.g., https://github.com/user/repo/assets/...) rather than the underlying S3 pre-signed URL
2. Use permalink formats: GitHub provides stable URLs for uploaded content that don't expose AWS infrastructure details
3. Review URLs before committing: Check for query parameters like X-Amz-Credential, X-Amz-Signature, or aws_access_key_id

For Repository Maintainers

1. Implement pre-commit hooks: Use tools like git-secrets or detect-secrets to scan for AWS key patterns before commits are accepted
2. Enable Semgrep CI scanning: The rule generic.secrets.security.detected-aws-access-key-id-value catches this exact pattern
3. Rotate exposed credentials immediately: Even if the key was for a pre-signed URL, the underlying IAM credentials should be rotated
4. Scrub git history: Use git filter-branch or BFG Repo-Cleaner to remove the credential from historical commits

Detection Patterns

The AWS Access Key ID format is well-defined:
- Always starts with AKIA (for long-term keys) or ASIA (for temporary credentials)
- Followed by exactly 16 uppercase alphanumeric characters
- Regex: AKIA[0-9A-Z]{16}

Key Takeaways

• Pre-signed S3 URLs contain real AWS credentials: The X-Amz-Credential parameter in any pre-signed URL exposes the Access Key ID used to generate the signature—never commit these to version control
• Reference links in YAML templates are still production code: Even metadata fields like reference: in nuclei templates are scanned and should be treated with the same security rigor as executable code
• GitHub asset URLs have two forms: The stable permalink (github.com/.../assets/...) and the underlying S3 pre-signed URL—always use the former in committed files
• Expired pre-signed URLs still expose long-lived credentials: The 300-second URL expiry doesn't protect the Access Key ID, which remains valid until explicitly rotated
• The AKIA prefix is a reliable detection signal: Any string matching AKIA[0-9A-Z]{16} in source code is almost certainly a real AWS Access Key ID that needs remediation

How Orbis AppSec Detected This

• Source: A pre-signed Amazon S3 URL pasted as a reference link in the YAML template's info.reference section
• Sink: The X-Amz-Credential query parameter at http/cves/2024/CVE-2024-51482.yaml:15, containing the literal value AKIAVCODYLSA53PQK4ZA
• Missing control: No credential scanning or pre-commit validation was in place to prevent AWS key patterns from being committed to the repository
• CWE: CWE-798 (Use of Hard-coded Credentials)
• Fix: Removed the entire pre-signed S3 URL from the reference list, eliminating the hardcoded AWS Access Key ID from the production codebase

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

This vulnerability demonstrates a subtle but common way credentials end up in source control: not through intentional hardcoding, but through copy-pasting URLs that happen to contain embedded authentication tokens. Pre-signed S3 URLs are particularly insidious because they look like ordinary web links but carry real AWS credentials in their query parameters.

The fix was simple—remove the offending URL—but the lesson is important: every URL, every reference link, and every piece of metadata in your codebase should be treated as potentially sensitive. Automated scanning with tools like Semgrep makes it possible to catch these issues before they reach production, and credential rotation should follow any exposure, regardless of how the credential was used.

References

• CWE-798: Use of Hard-coded Credentials
• OWASP Credential Management Cheat Sheet
• AWS Security Best Practices for Access Keys
• Semgrep Rule: Detected AWS Access Key ID
• fix: aws access key id value detected in CVE-2024-51482.yaml...