How a Simple Wayback Search Revealed 44,000+ Exposed Job Applicant Emails

A simple Wayback Machine recon uncovered archived pages exposing an estimated 44,560 job applicant emails, highlighting the risks of historical data exposure.

Sometimes the best bugs aren't hiding behind complex exploit chains.

No zero-day.
No authentication bypass.
No SSRF.
No deserialization.

Just a little curiosity… and the Internet Archive.

This write-up is about a vulnerability I discovered in [REDACTED], a recruitment advertising platform developed by [REDACTED], an HR Tech company. The platform allows recruiters to publish job ads to dozens — even hundreds — of job boards simultaneously, track campaign performance, and integrate with Applicant Tracking Systems (ATS).

In short, it's a platform that processes a huge amount of applicant data every day.

Which is exactly why this discovery caught my attention.

It All Started with Recon

The entire discovery started with a single Wayback Machine CDX query.

https://web.archive.org/cdx/search/cdx?url=*.[REDACTED]/*&collapse=urlkey&output=text&fl=original

https://web.archive.org/cdx/search/cdx?url=*.[REDACTED]/*&collapse=urlkey&output=text&fl=original

This endpoint simply lists archived URLs.

I wasn't looking for anything specific. Then one URL immediately stood out.

http://www.[REDACTED]:80/mysql/?view_responses=<identifier>

http://www.[REDACTED]:80/mysql/?view_responses=<identifier>

Hold on…

:80/mysql/?

That immediately triggered my curiosity.

Even more interesting…

The archive contained 1,114 URLs following exactly the same pattern.

Now I had to know.

The First Click

Naturally, I opened one of the URLs.

Nothing.

Looks like the page was gone.

For about three seconds, I thought:

"Well… that's unfortunate."

Then I tried the archived snapshot instead.

…And Then Everything Changed

There were 1,114 archived pages.

"Oh."

I checked a few more archived pages.

Then another.

Each archived page contained roughly 40–50 job applicants, including their email addresses.

At that point I stopped checking further. The problem was already obvious. No need to dig any deeper.

Estimating the Scale

A rough estimate was enough.

The archive contained:

1,114 archived pages
approximately 40 applicants per page (using the lowest observed value)

Simple math.

1,114 × 40 = 44,560

1,114 × 40 = 44,560

That means approximately 44,560 job applicant email addresses could have been been exposed through archived snapshots.

That's only a conservative estimate, and the actual number may be even higher.

For a brief moment…

The devil on my shoulder started making suggestions.

I politely ignored him.

The vulnerability was already confirmed, so I stopped digging and submitted the report.

Why This Matters

Email addresses are often underestimated.

But when thousands of job seekers are involved, they become valuable intelligence.

Attackers could use them for:

Spear phishing campaigns.
Fake recruiter emails.
Credential stuffing.
Social engineering.

People actively looking for jobs are naturally more likely to trust emails that appear to come from recruiters.

That's exactly what makes datasets like this valuable.

Lessons Learned

One thing I like about this case is that there wasn't any sophisticated exploitation involved. It was mostly an operational oversight.

Here are three lessons worth remembering.

1. Keep Sensitive Pages Away from Crawlers

Prevent sensitive pages from being crawled.

Otherwise, archived copies may continue exposing data even after the issue has been fixed.

2. Don't Forget Yesterday's Data

Many organizations focus on fixing today's vulnerability.

Very few ask:

What did our application expose last year?

Historical exposure can survive long after production has been patched.

Always audit Internet Archive snapshots after fixing sensitive issues.

3. Request Archive Removal

Fixing production is only step one.

If sensitive pages have already been archived, submit removal requests to archive providers.

Otherwise, your "fixed" vulnerability may continue leaking data for years.

Responsible Disclosure

Here's the disclosure timeline.

June 23, 2026 — Report submitted.
June 26, 2026 — The issue was still present.
July 4, 2026 — I noticed the issue had already been fixed without any notification, so I sent a follow-up.