How Changing a POST Request to GET Exposed Users’ PII and Earned Me a $5,000 Bounty

How Changing a POST Request to GET Exposed Users' Privacy Requests

Researcher: papjm Severity: Critical Reward: $5,000 bounty + $150 retest

The company, third-party provider, hostname, and API paths have been intentionally redacted.

Summary

I discovered a broken access-control vulnerability in a company's privacy-request portal. By changing a legitimate POST request to GET and removing the request body, I could retrieve privacy requests belonging to other users.

The exposed records contained sensitive personally identifiable information, including contact details submitted by people making deletion and other privacy-related requests.

Discovery

I started by submitting a deletion request using my own information. While reviewing the network traffic, I noticed a request being sent to the platform's privacy-request API.

I forwarded the request to Burp Repeater, removed the POST body, and changed the HTTP method to GET.

Instead of rejecting the request, the server returned records belonging to other users without verifying that I was authorized to access them.

I then reviewed the platform's public API documentation and found supported filtering and pagination parameters. These parameters made it possible to request specific categories of records and move through multiple pages of results.

An attacker could therefore automate the process and retrieve a large amount of sensitive user information.

Impact

The vulnerability could allow an unauthorized attacker to:

• Access privacy requests submitted by other users.
• Retrieve sensitive personal and contact information.
• Filter records by their source or category.
• Enumerate and download records in bulk using pagination.

Because the affected system processed privacy-related requests, the exposed information was particularly sensitive.

Disclosure and Resolution

I reported the vulnerability on June 17, 2025. The affected company independently reproduced the issue and determined that the vulnerability existed within a third-party service used to manage privacy requests.

The company instructed me to stop further testing while it coordinated remediation with the service provider.

The authorization controls were patched within two days. I was awarded a $5,000 Critical-severity bounty and invited to perform a paid retest.

During the retest, I followed the original reproduction process and confirmed that unauthorized access was no longer possible. The report was subsequently resolved, and I received an additional $150 retest reward.

Lesson

Never assume an API endpoint is secure simply because the application normally accesses it using a specific HTTP method. Testing alternative methods, removing request bodies, and reviewing documented filtering or pagination features can expose serious authorization weaknesses hidden behind an otherwise normal workflow.