I was just poking around a U.S. Navy portal one afternoon when I stumbled across something that made me stop and double-check what I was seeing.

With two parameter changes in Burp Suite, I could wipe out anyone's profile on the platform.

No special tools. No fancy exploit chain. Just a number swap.

Here's the full story.

The Target

The platform was ONR SMEConnect — a U.S. Navy site that connects Subject Matter Experts (SMEs) with researchers. Think of it like LinkedIn, but for Navy science collaboration.

When you want to edit your profile, you visit a URL that looks like this:

https://www.X.navy.mil/smeconnect/smes/Edit/61

That 61 at the end? That's your user ID.

The moment I saw it, one thought crossed my mind: what happens if I change that number?

The Bug

I opened Burp Suite, intercepted the edit request, and looked at the request body. There it was — a field called SmeId, also set to 61.

So the ID showed up in two places:

  • The URL path
  • The request body

I created a second test account. Its ID was 62.

Then I did the simplest thing possible — I changed both values from 61 to 62 and forwarded the request.

The server accepted it. No error. No "you're not authorized." Nothing.

The victim's profile had just been overwritten by the attacker's request.

Why This Works

This type of bug has a name: IDOR — Insecure Direct Object Reference.

The server was basically trusting the ID in the request instead of checking: "Hey, does this logged-in user actually own profile 62?"

It didn't ask that question. So anyone could answer for anyone else.

What an Attacker Could Do

  • Overwrite a victim's email and personal info
  • Destroy their profile data entirely
  • Do it to every user — the IDs were just sequential numbers (61, 62, 63…), so mass enumeration was trivial

On a government platform built to facilitate research collaboration, that's a real problem.

How I Reported It

I submitted the report to the U.S. Department of Defense Vulnerability Disclosure Program on HackerOne, with a full video walkthrough showing the attack step by step.

The timeline was clean:

  • 📩 Nov 23 — Report submitted
  • ✅ Nov 24 — Triaged, severity set to High
  • 🔒 Dec 4 — Resolved

The Lesson

When you see a user ID in a URL, always look at the request body too. Apps often put the same ID in multiple places — and sometimes they validate one but completely forget the other.

The rule I follow: if a number identifies you, try making it identify someone else.

It sounds almost too simple. But bugs like this are still out there, on real platforms, with real impact.

That's what makes bug bounty hunting worth it.

This was submitted as part of authorized security research under the DoD Vulnerability Disclosure Program. HackerOne: @iamabdelaal