During a recent penetration test, we uncovered a critical vulnerability in a publicly accessible API endpoint that allowed unauthenticated users to escalate privileges all the way to an administrative level. This flaw ultimately exposed the Personally Identifiable Information (PII) of every user in the system.
We’re sharing this finding because it’s a perfect example of how impactful vulnerabilities aren’t always flashy or complex, sometimes they just require careful manual testing and creative chaining of seemingly small issues to achieve a full compromise. In this blog, we’ll walk through how we discovered and exploited this vulnerability step by step and highlight practical recommendations for preventing similar issues in your own environment.
The initial discovery of the exploit was achieved by identifying an insecure endpoint namely /api/services/app/Microsites/GetMicrositeFromURL/ this was achieved via fuzzing and content discovery and was found to return data without authentication.
Within the data, there were two sensitive values of interest identified ‘upgradeCode’ and ‘adminUpgradeCode’. These codes were intended for internal use and should not have been exposed in the publicly accessible endpoint response and were identified to be utilised by the application to ‘upgrade’ user levels.
The output below displays the identified sensitive upgrade codes identified within the response of the unauthenticated request to the insecure API.
The application allowed self-registration, providing an attacker with the ability to register a standard-user account to gain initial access to the application.
Upon creating the account, it was identified to be possible to use the userToken of the standard user account within an identified /api/v1/user/UpgradeUser endpoint alongside the identified sensitive codes to upgrade to both a professional user level, which usually requires a paid subscription, as well as an administrative user level.
The output below displays it being possible to perform privilege escalation to a professional and administrative user level, giving the account both permissions.
Once the account was escalated to professional and administrative level it was possible to authenticate to the API endpoint /api/v1/user/GetUsersByMicrosite/ and retrieve all of the data for users registered to the application.
As intended, the data retrieved included: emails, phone numbers, and full names, all of which enable the identification of a person.
The output below displays an example of the PII returned via the endpoint.
You might be wondering what the real-world impact would be if this issue wasn’t identified and addressed as soon as it was. In short, due to the site being live and publicly accessible at the time of testing, the issue required addressing immediately. If an attacker were to identify the insecure endpoint and perform the same exploitation pathway as outlined above, the attacker would gain access to all the PII of the registered users.
This would be a significant breach of confidentiality, integrity, and availability of all data held by the client due to the administrative access gained also providing full control over the application, as well as reputational damage due to the nature of their business.
To prevent attacks like this, there are a few practices to keep in mind:
Implement Proper Authentication and Authorisation:
Ensure all sensitive API endpoints are protected by robust authentication mechanisms, this could include OAuth, JWT with properly validated claims, or other industry-standard approaches.
Enforce role-based access control (RBAC) or other appropriate authorisation models to limit access strictly based on user roles and permissions.
Avoid Exposing Sensitive Information:
Sensitive data such as upgradeCode or adminUpgradeCode should never be exposed in API responses. Store such information securely and ensure it is only accessible by authorised services or users.
Use Secure Coding Practices:
Validate all user input and sanitise API responses to prevent exposure of internal data. Regularly review the code for security vulnerabilities such as hardcoded credentials or exposed secrets.
Implement Rate Limiting and Logging:
Apply rate limiting to prevent abuse of sensitive endpoints and ensure all API requests are logged for monitoring and auditing purposes. Logs can help detect unusual access patterns or attempts to exploit vulnerabilities.
Regular Penetration Testing:
Automated tools are useful but can miss complex vulnerability chains. Regular, manual penetration testing can uncover these hidden risks.
Educate your development team on how to recognise and prevent vulnerabilities during coding.
Even seemingly small vulnerabilities, such as exposed API endpoints or improper access controls, can lead to major security risks. In this case, the lack of authentication on critical endpoints allowed privilege escalation and the exposure of sensitive PII. Manual penetration testing is essential for uncovering these hidden flaws and strengthening security before attackers can exploit them.
By staying proactive and identifying vulnerabilities like these early, organisations can prevent unauthorised access, data breaches, and the reputational damage that follows. Insecure APIs, when left unaddressed, can lead to full system compromise and data exposure.
At CybaVerse, our comprehensive penetration testing goes beyond automated scans. We focus on proactively identifying risks in real-world scenarios, ensuring that your applications are secure from exploitation. If you'd like to safeguard your systems against potential attacks, feel free to reach out and discover how we can help you stay ahead of evolving security threats.