The Story

It started with checking my visa petition status online. Six months later, I was the #1 security researcher for the Department of Homeland Security, responsible for 8 out of 11 critical vulnerabilities found across their systems from October 2024 to April 2025.

Here’s how it happened.

It Started with a Bug in My Own Visa Case

I wasn’t looking for security vulnerabilities when I found my first one. I was just checking my visa petition status online, like I’d done dozens of times before.

One day, the UI looked different. Something had changed. As a security engineer, I couldn’t help myself. I opened the browser console to see what was going on under the hood.

The code looked weird. There were these esoteric variable names that didn’t make sense. I kept digging, and that’s when I found it: an exposed secret key sitting right there in an environment variable. This key was used for signing JWT bearer tokens, which meant I could generate valid authentication tokens with just an email address and call a bunch of private APIs.

This turned out to be a critical vulnerability. I reported it through the DHS Vulnerability Disclosure Program and figured that was that.

Then I had a thought.

The Government Uses Contractors

If one developer made this mistake, they probably made similar mistakes elsewhere. The U.S. government contracts out a lot of web development work, and developers tend to reuse the same patterns across projects.

I decided to fingerprint those weird variable naming conventions I’d seen. They were distinctive enough that I could potentially track them across different projects.

Then I got systematic about it:

• Used subfinder to enumerate over 20,000 DHS in scope domains and subdomains
• Wrote a script to scan all of them, looking for regex matches of those esoteric variable patterns in the source code
• From that I found 4 additional websites with similar fingerprints

Time to dig in.

Thanksgiving Weekend

I spent Thanksgiving weekend writing the enumeration scripts and testing these four sites.

Most of what I found was standard stuff: IDORs, exposed secrets, broken access controls, sensitive data exposure. It was great that the fingerprinting technique had worked.

But one site was particularly interesting. It was just a login page. I had no account and couldn’t access the functionality.

Since it was a React application, the source code was sitting right there in the browser. I could see the component structure and API endpoints even if I couldn’t access them directly.

I started mapping out the API surface from the client-side code. With some help from AI tools to speed things up, I reverse engineered how the requests worked and started testing for vulnerabilities.

For one API I started guessing IDs to test for IDOR (Insecure Direct Object Reference) vulnerabilities. This is when you can access other users’ data just by changing an ID in a request. I tried 123456 and got a corrupted PDF. Tried some alphanumeric patterns I saw before but nothing was working. Then I accidentally reran 123456 and a valid PDF loaded with PII. I accidentally deleted the 6 and typed 12345. It worked.

It was a simple enumerated IDOR found in an API buried in obfuscated code. An attacker could just iterate through sequential IDs and download thousands of pdfs containing PII. Honestly, I had no idea what this API or website did. I just got lucky finding it and this turned into a critical.

By the end of Thanksgiving weekend, I’d found an additional 1 critical, 2 high, 1 medium, and 1 low severity bugs across those systems.

My scanner also found a high-severity bug in a U.S. General Services Administration product used in a DHS app, and a medium-severity bug for the Department of the Treasury.

Going Deeper

A few months later, the U.S. rejected my visa petition. Naturally, I decided to take another look at the USCIS systems. 🙃

This time I wasn’t just doing surface-level testing. I went deeper and actually tried to enumerate all the features properly. Something I was too lazy to do the first time around.

I found 6 more critical vulnerabilities and reported them through the VDP.

Two of them were fixed within 24 hours after I reported them. I was genuinely surprised. That’s incredibly fast for any organization. I believe the severity of those two issues may have played a part in this.

Google Dorking for Access

I also decided to properly pentest another one of the four websites. Going deeper meant being more thorough about feature enumeration.

The problem was I needed a special company license ID just to access a lot of additional functionality and APIs. This is a special ID you get when your company is registered with the DHS, kind of like a driver’s license number. It was a long alphanumeric that was too long to guess and they would check if the ID was valid in the system.

So I used Google Dorking to find someone’s company license ID. I searched for things like intext:"LicenseName" filetype:pdf. Got to page 16 of Google results and found some company's Google Drive PDF that had been indexed. Inside was a document with the company license ID I needed.

With that, I could access more of the application and test the APIs properly. This resulted in 4 additional critical vulnerabilities.

The Results

In total over six months:

• 8 critical findings
• 3 high-severity findings
• 1 medium-severity finding
• 1 low-severity finding

During this period (October 2024 — April 2025), there were only 11 critical findings shown on the crowd stream for the DHS VDP. I was responsible for 8 of them.

I received thank-you letters from both Hemant Baidwan, the DHS Chief Information Security Officer, and Amanda Day, the Chief Information Security Officer Directorate, which stated: “You have been essential in defending the homeland by identifying vulnerabilities prior to adversarial exploitation and protecting some of the most critical technologies in the U.S.”

I am grateful for the recognition. These systems process sensitive data for millions of people. I’m proud to say my efforts led to these issues being fixed before malicious actors could exploit them, helping protect critical national security infrastructure.

What Actually Worked

Here’s what made this possible:

Pattern recognition: Developers reuse patterns. If you find one mistake, look for similar ones elsewhere.

Systematic enumeration: Don’t just look at one site. Scale your reconnaissance with automation.

Client-side analysis: Modern web apps expose their architecture in the JavaScript. Use it.

Going deep: The first pass finds the obvious stuff. The second pass finds the real issues.

Creative information gathering: Sometimes you need information that’s not technical, like that company license ID from Google Dorking.

Persistence: The good findings often take multiple attempts and different approaches.

Zero Trust Architecture

Most of these vulnerabilities came down to one thing: lack of Zero Trust principles.

Systems were trusting things they shouldn’t:

• Missing authorization checks (not verifying access rights per request)
• Predictable IDs (enabling IDOR attacks)
• Client-side security (exposed secrets)
• Sensitive data exposure (unnecessary information leakage)

Zero Trust means “never trust, always verify.” Every request needs to be authenticated and authorized, regardless of where it comes from. A lot of these systems weren’t doing that.

Final Thoughts

Going from checking my own visa petition status to becoming the #1 researcher on the DHS VDP wasn’t planned. It started with curiosity and turned into a systematic approach to finding patterns across government systems.

The DHS Vulnerability Disclosure Program was the best government program I’ve worked with. They fixed issues incredibly fast, not just fast for a government organization, but fast for any organization. Two of my critical findings were patched within 24 hours. I felt that every report was taken seriously. Since my initial reporting period, I’ve noticed a significant improvement in the security posture of DHS websites. They now have stronger protections against various attack vectors that weren’t there before. In the six months after my reporting period ended (June 12, 2025 to December 7, 2025), only two critical vulnerabilities appeared on the DHS CrowdStream. That’s a dramatic reduction from the prior period.

The vulnerabilities are fixed, and the systems are more secure. As the DHS Chief Information Security Officer noted, this work was essential in defending the homeland and protecting critical U.S. technologies. Millions of Americans interact with these systems every day for border crossings, immigration services, and customs processes. They’re all safer now because these critical flaws were found and fixed before adversaries could exploit them.

A Quick Note on the Visa Petition

The visa petition was an EB2-NIW (National Interest Waiver), which lets you self-petition for a green card if your endeavor is in the national interest of the U.S. The first filing received an RFE (Request for Evidence) then was rejected. I put it together myself and missed some documentation on the RFE. I refiled in June 2025 with help from a law firm, and the second petition was better put together.

Hopefully this time it’s approved.