It’s been a while since my last bug bounty write-up. Over the past few months, I simply haven’t had much time to turn my findings into public write-ups. Recently, I had an exciting experience while testing a program on YesWeHack where I discovered and responsibly reported 10 valid vulnerabilities within a single program. These findings earned me the Comet badge and ultimately the maximum reward on the program, resulting in the Black Hole badge. In this article, I’ll walk through some of the impactful vulnerabilities I discovered, including Improper Access Control, Information Disclosure, and Cross-Site Scripting (XSS), and share the methodology that helped uncover them.

1. Critical Improper Access Control Leading to Enterprise Account Takeover

One of the most severe issues I uncovered was a classic case of broken access control on the invitation endpoint - an Improper Access Control flaw that allowed any authenticated user to add themselves as an Owner to any enterprise by simply swapping the enterprise ID in a POST request. The server blindly trusted the client-supplied enterprise_id without verifying whether the authenticated user belonged to (or had invite/owner rights in) that organization. This led to full account takeover: attackers could add themselves as Owner, expose sensitive owner emails (a GDPR/PII violation), kick out legitimate owners, modify enterprise data, and gain complete administrative control over unrelated organizations.

POST /invitation/502565 HTTP/2
Host: redacted.com
Content-Type: application/x-www-form-urlencoded
csrfmiddlewaretoken=TOKEN&[email protected]&role=owner

By replacing the enterprise ID in the request path with the identifier of another enterprise, the server processed the invitation and granted Owner privileges to the attacker account. The issue stemmed from the server trusting a client-controlled parameter without performing server-side authorization checks to confirm that the requester was authorized to invite users to the specified enterprise.

2. Unauthenticated MongoDB Exposure Leading to Sensitive Information Disclosure

During broader reconnaissance and port scanning of the target infrastructure, I identified an exposed service running on port 27017, which is commonly associated with MongoDB. Further inspection revealed that the MongoDB instance was publicly accessible at redacted.com:27017 with authentication and access control disabled, allowing any unauthenticated user to connect directly to the database server. By connecting to the instance using the MongoDB client, it was possible to enumerate databases, access collections, and retrieve large amounts of data without providing any credentials.

After establishing a connection, database enumeration revealed multiple collections containing production-like data, including sent_email, transactions, report, pdf_snapshot, pictures, and user. Querying these collections exposed a significant volume of sensitive information such as internal emails, reports, documents, and transaction-related data. For example, the report collection alone contained over 64,409 records, while the transactions collection contained more than 91,318 entries, indicating that the exposed database stored operational application data rather than sanitized test content. Further analysis of exported data also revealed numerous internal email addresses and artifacts that could potentially contain personally identifiable information or sensitive organizational records.

3. Stored Cross Site Scripting Leading to Account Takeover

While testing the establishment contribution feature on the platform, I discovered a Stored Cross Site Scripting vulnerability in the establishment editing workflow. The application allowed authenticated users to update establishment information through the endpoint /contrib/edit-infos/[establishmentName]/, where the Name field was stored without proper sanitization. Because the value was later rendered directly in the establishment page and search results, a malicious payload inserted into this field would be permanently stored on the server and executed whenever another user viewed the affected page. This behavior allowed an attacker to inject arbitrary JavaScript that would run in the context of the application domain.

Once the update was saved, the payload became persistent and would automatically execute whenever a user visited the establishment page. By replacing the test payload with a cookie exfiltration script, it was possible to capture session cookies, allowing an attacker to impersonate the victim and perform actions on their behalf, effectively leading to full account takeover.

4. Unauthenticated API Endpoint Exposing Sensitive User Feedback

During API enumeration of the target infrastructure, I discovered that while the root endpoint of the API returned a 404 response, the application exposed an OpenAPI/Swagger interface at /swagger, which revealed the complete list of backend endpoints. While most endpoints required authentication, one particular endpoint /api/usage_feedback was accessible without any authentication and returned a full JSON dataset containing user submitted feedback records. Because this endpoint was intended for administrative use, the returned data included not only feedback messages but also sensitive personal information such as email addresses, phone numbers, and other identifying details submitted by users while contacting the platform.

Accessing the endpoint directly returned a large list of feedback objects containing fields such as Name, Email Addresses, Feedbacks, and timestamps, along with free text messages written by users. By downloading the response and performing simple data extraction, it was possible to retrieve numerous personal email addresses, phone numbers, and user comments, effectively exposing private communications that were meant only for administrators.

5. IDOR Allowing Unauthorized Access to Other Users’ AI Analysis Results

While testing the AI analysis feature of the platform, I discovered an Insecure Direct Object Reference (IDOR) vulnerability in the endpoint responsible for downloading generated analysis results. The application allowed users to upload documents and receive AI generated summaries, which could later be downloaded through the endpoint /analyses/[organisationId]/resultat/[resultId]/theme. However, the server failed to properly verify whether the authenticated user was actually authorized to access the requested analysis result. Because the endpoint relied directly on numeric identifiers in the URL, an attacker could manipulate the resultId parameter and retrieve summaries belonging to other organizations.

After uploading a sample document and triggering the AI analysis process, the platform generated a download request similar to the following:

GET /analyses/520026113/resultat/290/theme HTTP/2
Host: redacted.com

By intercepting this request and modifying only the result identifier, it was possible to iterate through different values while keeping the attacker’s organization ID unchanged. Because these summaries were derived directly from user uploaded documents, the vulnerability could lead to the exposure of confidential business information, private reports, or sensitive internal data contained within those files.

This bug bounty engagement was a great reminder that impactful vulnerabilities often come from simple but overlooked security controls. Each finding highlighted how small implementation gaps can lead to significant security risks. I would like to thank the program team and the YesWeHack platform for their prompt responses and smooth collaboration during the disclosure process. If you found this write-up useful or interesting, feel free to connect with me or follow my work where I regularly share insights on bug bounty hunting, vulnerability research, and application security. You can find me on LinkedIn and X where I post updates, research findings, and security related content.