Forgotten Serverless History: Finding Exposed AWS Keys & .env Files on pages.dev via SSL Assignation

1. The Discovery: Why Serverless History Is Dangerous & Forgotten

Modern developers deploy web applications on serverless platforms (*.pages.dev, *.workers.dev, *.vercel.app, *.netlify.app) because every push automatically builds and publishes a live URL. What most developers forget—or do not care to clean up—is that serverless platforms keep an immutable history of old deployments and dev / preview URLs live on the internet.

During security research, Midas discovered a critical, widespread vulnerability pattern across serverless deployments:

• Developers Push a Fix Instead of Deleting History: A developer accidentally deploys a build containing a .env file, hardcoded AWS keys (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY), or internal API tokens. Ten minutes later, they remove the secret in a new commit and redeploy. Production (example.com) now looks clean—but the old deployment is still online in the serverless history (<hash>.<project>.pages.dev or dev.<project>.pages.dev), and the developer never deleted the deployment history or rotated the AWS keys.
• Finding Hidden pages.dev & dev Deployments via SSL Assignation: Even when a company hides its .pages.dev or dev URL behind a custom domain, checking SSL certificate assignation (Certificate Transparency logs / SAN records) reveals the underlying pages.dev, dev, and branch preview hostnames where .env files and AWS credentials are still exposed.

---

2. How SSL Assignation Reveals Forgotten pages.dev & dev Deployments

Whenever a developer creates a project on a serverless platform, connects a custom domain, or spins up a dev / staging branch, the platform automatically issues TLS/SSL certificates (via Let's Encrypt, Google Trust Services, or DigiCert). Every issued certificate is permanently recorded in public Certificate Transparency (CT) logs.

By checking SSL assignation, a researcher can map the entire forgotten surface of an application in seconds:

1. Correlating Custom Domains to pages.dev / dev Names: Developers almost always name their serverless project after their brand or repository (<company>.pages.dev, <company>-dev.pages.dev, staging-<company>.pages.dev). Checking SSL certificate assignation history surfaces every certificate ever issued for their staging, dev, and preview subdomains.
2. Enumerating Branch & Commit Previews: When wildcard or branch certificates are assigned (*.<project>.pages.dev or <branch>.<project>.pages.dev), CT logs record the exact hostnames where early, unhardened builds were deployed before security checks were added.
3. Bypassing the Main Domain Entirely: Even if the main domain (app.company.com) is protected by strict WAF rules or serves a sanitized latest build, the underlying pages.dev or dev hostname discovered through SSL assignation responds directly with the uncleaned build or historical deployment.

---

3. Why .env Files & AWS Keys Survive in Serverless History

When auditing pages.dev and dev endpoints discovered via SSL assignation, leaks consistently happen for three reasons:

1. People Don't Delete Deployment History:
   • On platforms like Cloudflare Pages, Vercel, and Netlify, every previous deployment remains online at its unique deployment URL unless an administrator explicitly deletes the deployment or locks previews behind an access policy.
   • When a developer accidentally commits a .env file or hardcodes an AWS key during initial dev testing, simply pushing a new commit (git rm .env) only updates the latest build—the old deployment URL still serves the leaked .env and AWS keys.
2. Static Asset & Bundler Leakage on dev Branches:
   • Early dev deployments frequently publish raw project directories (where /.env, /.env.local, or /.env.production is served directly as a static file) or include unminified JavaScript sourcemaps (*.js.map) that contain full .env object dumps and AWS S3 / IAM credentials.
3. Unrotated Cloud Keys:
   • Because developers assume that removing the key from their latest commit fixed the issue, they almost never revoke or rotate the leaked AWS_ACCESS_KEY_ID in AWS IAM—leaving live cloud infrastructure wide open to anyone who checks their serverless history.

Exposure Point	How It Is Found	What Developers Forget	Impact
*.pages.dev / dev Subdomains	SSL Assignation (CT Logs)	Preview and dev URLs stay public even after a custom domain is added	Direct bypass of production domain to reach forgotten dev builds
Immutable Deployment History	Preview / Branch URLs	Pushing a new commit does not delete previous serverless deployments	Old builds with accidental .env or key leaks remain online forever
Leaked .env & Sourcemaps	Inspecting dev / Old Builds	Early test builds often ship raw .env files or .js.map sourcemaps	Full disclosure of environment variables and backend endpoints
Hardcoded AWS Keys (AKIA*)	Scanning JS Chunks & .env	Removing a key in Git/production does not invalidate the key in AWS IAM	Live compromise of AWS S3 buckets, Lambda, SES, or EC2 infrastructure

---

4. How to Actually Lock Down Serverless History

Fixing a leak in your latest commit is useless if your serverless history is still public:

1. Lock *.pages.dev & Preview URLs Behind Authentication: Enable Cloudflare Access (or deployment protection) on all *.pages.dev and preview deployments so public visitors can only access the current production custom domain.
2. Delete Old Deployment History: Whenever a build accidentally includes a .env file, sourcemap, or secret, delete the historical deployment records on the serverless platform—do not just push a new commit on top of it.
3. Immediately Rotate Exposed AWS Keys: Treat any credential that ever touched a dev or preview build as compromised. Revoke the AWS_ACCESS_KEY_ID in AWS IAM immediately, because SSL assignation and serverless history make "hidden" preview builds trivial to find.

Technical References & Verification

Certificate TransparencySectigo / crt.sh

crt.sh — Certificate Transparency Log Search & SSL Assignation Auditing

Public Certificate Transparency search engine used to inspect SSL certificate assignation and enumerate forgotten subdomains and dev/preview endpoints.

Serverless PreviewsCloudflare Documentation

Securing Cloudflare Pages Preview Deployments (*.pages.dev) with Cloudflare Access

Official guide on restricting public access to historical and branch preview deployments on *.pages.dev.

Cloud Key RotationAmazon Web Services (AWS)

AWS IAM Best Practices — Rotating and Revoking Exposed Access Keys

AWS security documentation on immediately deactivating and rotating IAM access keys exposed in builds or repositories.