$1,700 IDOR: Unauthorized Modification of Web Hosting Configuration
Hi Everyone! I recently discovered an IDOR (Insecure Direct Object Reference) vulnerability in ExHub that allowed an attacker to modify the web hosting configuration of any project without proper permissions. For this discovery, I was awarded a $1,500 bounty along with a $200 bonus. Let’s explore how this bug worked, how I exploited it, and why it was important.

Understanding the Target
ExHub is a platform for hulia-based development, offering cloud hosting, project collaboration, and deployment features. One of its functionalities allows users to configure web hosting settings for their projects, determining how they are deployed and accessed. To maintain security, only authorized users should be able to modify a project’s web hosting settings. However, this restriction was not properly enforced, allowing unauthorized users to alter hosting configurations just by knowing the project ID.
The Flaw: Unauthorized Modification via Direct API Request
The vulnerability existed in ExHub’s project deployment configuration API, which lacked proper authorization checks. This allowed any user, including an unauthenticated attacker who obtained a project ID, to send a crafted request and modify the project’s web hosting settings.
Even users with minimal permissions, such as reader-only roles, could alter critical settings using a simple API call.
Steps to Reproduce
- Obtain the project ID of the target project on EaHub.
- Craft a POST request to modify the web hosting configuration of the target project. Example:
POST /api/v1/projects/deployment_configuration/<projectid> HTTP/2
Host: Exahub.com
Content-Type: application/json
{ "machineType":"t32", "port":9901, "dnsAutogen":true, "authentication":"me" }
- Send the request using Burp Suite or any API testing tool.
- Observe the result — the web hosting configuration of the target project gets modified without proper authorization.
- Verify in the UI that the changes have taken effect.
Impact
- Unauthorized access to critical settings: Attackers could modify deployment configurations, potentially leading to service downtime or unauthorized project access.
- Service disruptions: Misconfigurations introduced by an attacker could render projects inaccessible.
- Security violations: Reader-only users were able to perform administrative actions, breaking the principle of least privilege.
- Potential exploitation for privilege escalation: Attackers could use modified configurations to manipulate how services interact, opening doors for further attacks.
Bounty & Program Response
- Reported: August 2, 2024
- Triaged: August 2, 2024
- Severity Adjusted: Critical (9.8) → High (8.8) (Due to the assumption that obtaining the project ID required some level of privilege)
- Bounty Awarded: $1,500 + $200 bonus + $100 for retest
- Retest Completed: October 15, 2024 (Fix confirmed)
ExHub acknowledged the severity of the issue, stating that implementing a proper fix required significant changes. They rewarded me with a bonus for the well-crafted report and invited me to perform a retest for an additional $100, which confirmed that the fix worked.

Key Takeaways
- APIs should always enforce authorization checks before allowing modifications to critical settings.
- Project IDs should not be easily guessable or accessible, as they can be leveraged in attacks.
- Low-privileged users should never have the ability to modify administrative settings.
- Even backend configuration changes should be tested for security loopholes, as improper API validation can lead to severe vulnerabilities.
- Good bug reports are highly valued — the bonus shows that programs appreciate detailed and well-structured disclosures.
Conclusion
This was a classic IDOR vulnerability where a lack of proper authorization checks allowed unauthorized users to modify sensitive configurations. Always ensure that every sensitive API endpoint properly enforces authentication and authorization checks to prevent such issues.
I hope this write-up helps others identify similar vulnerabilities in different systems. Until next time, happy hacking! 🚀
Connect and Engage
If you found this article informative, please share your feedback and insights in the comments section. Follow me for more updates on cybersecurity insights and responsible disclosure stories.
Connect on Twitter: @a13h1_