Hello folks,
I’m Mahmoud El manzalawy, a bug bounty hunter who enjoys finding vulnerabilities in his free time.

Today, I’ll walk you through how how changing the HTTP method led to full admin credential disclosure email addresses, password hashes, and additional sensitive data

One of the simplest vulnerabilities I’ve found.

Our target today is a script called: B2B CRM Solution for eCommerce Software

While testing the platform, I accessed the email section and started interacting with the reply feature.
During this process, I noticed a suspicious request being sent it included an API in the path

I copied the request and sent it to Repeater for further analysis.
To my surprise, the response returned: 201 created

Understanding the Response: 201 Created

While replaying the request, the server responded with a 201 Created status code.
This HTTP response indicates that the request was successful and a new resource was created as a result such as a record being inserted into the database.

Example Scenario:
When an API receives a POST request to create a new message, order, or user, a 201 response confirms that the operation was successful and returns the new item’s ID or reference {“id”:1}

Initially, the server responded with a 201 Created upon replaying the original POST request indicating that a resource (likely a message reply) was created. The returned ID ({“id”:1}) matched the recipient’s user ID.

Out of curiosity and suspicion of a potential misconfiguration, I changed the HTTP method from POST to GET

Unexpectedly, the server responded with a full dump of user data.
This included a list of all registered users with the following sensitive details: User IDs , Email addresses and Passwords (in plain or hashed format)

This clearly confirms a critical misconfiguration in the API’s HTTP method handling, allowing unauthorized read access to sensitive user data.

Now Let’s Explain: How and Why This Vulnerability Occurred

This vulnerability exists due to poor access control and improper HTTP method handling on the backend. While the original POST request was correctly handled and didn’t expose any sensitive information, the same endpoint unexpectedly responded to a GET request with a full dump of registered user data — including emails and password hashes.

These data were never meant to be displayed, not even to authenticated users let alone anonymous visitors.
This reveals a critical misconfiguration where sensitive internal functions were exposed publicly

Simple Example — Misconfigured Registration Endpoint

Imagine a registration system where users submit their data via POST to /register.

Everything seems secure no leak happens during normal usage.

But an attacker tries to access /register using a GET request and surprisingly receives a full list of users. This shows a serious issue: an internal function or admin logic was mistakenly mapped to a public endpoint.

Here’s a simplified visual explaining how this vulnerability occurred:

Thank you for reading my write-up!
See you soon with another bugs 😄

Feel free to follow me on Medium , Linkedin , X: @is4curity
Happy bug hunting!

./Egypt 🇪🇬