Hacking VAmPI Part II
March 7, 2026
In Part 1 of this series, I set up my hybrid lab environment using Docker and Kali Linux, and I successfully exploited four critical vulnerabilities.
I populated the database, registered an attacker account, and compromised the API through Broken Object Property Level Authorization (BOPLA) by registering as an admin via Mass Assignment.
I also exposed plaintext passwords through Excessive Data Exposure, accessed another user's private data through Broken Object-Level Authorization (BOLA), and changed another user's password through Broken Function-Level Authorization (BFLA).
If you haven't read it yet, I highly encourage you to go through Part 1 before continuing here to understand how the lab is structured.
In this second part, I am continuing the hunt for vulnerabilities in the VAmPI application.
1. SQL Injection (API8): Full Data Exfiltration
My next target was the user retrieval feature. I knew from my initial API mapping that the application fetches user details at /users/v1/{username} by taking the username directly from the URL path. I wanted to see whether this input was being sanitized or passed directly to the backend database.
Instead of spending time manually injecting single quotes to look for SQL syntax errors, I used sqlmap to automate the testing against the endpoint to see if I could extract data directly.
sqlmap -u "http://localhost:5000/users/v1/Mel" --dump
This bypassed the application's logic and confirmed that the endpoint is vulnerable to SQL Injection because the developer concatenated the username directly into the SQL query. sqlmap successfully dumped the entire contents of the SQLite database.
I retrieved the entire users table, which exposed all usernames, emails, and plaintext passwords for every user on the system (e.g., pass1 and password123). Furthermore, I extracted the books table, allowing me to read every user's private secret content. An attacker could use this exact flaw to leak all user data, steal identities, or manipulate financial and medical records, completely destroying the confidentiality and integrity of the system.
2. Broken Authentication (API2): JWT Secret Cracking
VAmPI relies heavily on JSON Web Tokens (JWTs) for user authentication. While reviewing my requests in Postman, I wondered how strong the signing secret guarding these tokens was. If the developer used a weak secret, I knew I could forge my own token and bypass the login system entirely.
I used the legitimate token I acquired after logging in and pasted it into xjwt.io, an online JWT secret-cracking tool. I ran a dictionary attack against the token to see if the developer used a common, easily guessable word to sign it.
I successfully cracked the HMAC signature, and since the API uses the symmetric HS256 algorithm, this meant I could forge my own tokens and proceed as I pleased.
With the secret in hand, I modified my token's payload. I changed the subject field (sub) from my standard user, Imelda, to admin. I then signed this newly forged token using the cracked secret random.
When I passed this forged token in my Authorization header, the API accepted it without hesitation. I successfully bypassed the login flow and impersonated the global administrator. This is a catastrophic flaw. Anyone who cracks this weak secret can forge tokens for any account on the platform. It leads to account compromise without ever needing to know a single password.
3. User Enumeration (API2): Verbose Error Messages
Finally, I wanted to see how the API behaves when I give it incorrect login credentials. Sometimes, APIs are too talkative, which helps attackers perform reconnaissance on the system.
I sent POST requests to the /users/v1/login endpoint using different combinations of credentials.
First, I tried logging in with a username that I knew did not exist (Imel).
Then I tried logging in with a valid username (Imelda) but entered a deliberately incorrect password.
The API returned two different error messages depending on what I got wrong.
When the user did not exist, it returned: {"status": "fail", "message": "Username does not exist"}.
When the user existed, but the password was wrong, it returned: {"status": "fail", "message": "Password is not correct for the given username."}.
This is a classic enumeration flaw. I can use an automated tool like Burp Intruder to send thousands of usernames to this endpoint, and the API will explicitly tell me which ones are valid system accounts. Once I map out the valid users, I can focus all my brute-force efforts solely on guessing their passwords, drastically increasing the chances of a successful account compromise.
Finally Done!
This concludes my exploitation of VAmPI. Through these two articles, I demonstrated how seemingly minor development choices can lead to a system compromise.
That's it for this one, see you on the next one.