Exploiting API Misconfiguration & Weak Security to Discover a Critical Vulnerability

Hello everyone! Today, I’ll be sharing how API misconfiguration and weak security led me to discover a critical vulnerability in a major company specializing in corporate security.

I started by performing subdomain enumeration on the target website using tools like:

• Subfinder
• Amass
• Dnscan

After collecting a large number of subdomains, I filtered out duplicates using Anew and then passed the remaining domains through httpx to identify live ones. Once I had a list of active subdomains, I examined them for anything interesting. One subdomain that caught my attention was:

wp.example.com

When I visited the URL, it redirected me to example.com, which made me curious to investigate further.

I decided to run some automated security tools to test for vulnerabilities:

• Nuclei
• Acunetix

After waiting for the scans to complete, the only relevant information I found was the WordPress version, but that wasn’t enough. So, I used WPScan to check for installed plugins, but unfortunately, they were all up-to-date, meaning no known vulnerabilities were present.

Since automated tools didn’t reveal anything critical, I decided to perform fuzzing. I prefer using Dirsearch over ffuf for directory brute-forcing, so I ran it and found the following endpoint:

wp-json

However, when I tried to access it, I got a 403 Forbidden response. I attempted multiple bypass techniques, but none were successful. I didn’t give up and continued recursive fuzzing using Dirsearch, which led me to discover:

wp-json/myplugin

This also returned 403 Forbidden. I kept going until I found:

wp-json/myplugin/v1/reposts

When I accessed this endpoint, it returned public reports, but I wanted to see if I could retrieve private data. So, I modified the request like this:

/wp-json/myplugin/v1/reposts?filter=private

Surprisingly, it returned a JSON response with the following structure:

[
{
“ID”: 12345,
“post_title”: “Test”,
“details”: {
“stages”: [
{
“file”: “https://wp.example.com/wp-content/uploads/2023/03/Test.pdf",
“status”: “Audited”
}
]
}
}
]

The Test.pdf file immediately caught my attention because it was supposed to be private. So, I decided to check if I could download it without authentication using:

wget “https://wp.example.com/wp-content/uploads/2023/03/Test.pdf"

wget "https://wp.example.com/wp-content/uploads/2023/03/Test.pdf"

To my surprise, the download was successful without requiring authentication! When I opened the file, I realized it contained highly sensitive security reports, including fixed and unfixed vulnerabilities, along with links to private GitHub repositories. This was a major information disclosure vulnerability.🔥

I didn’t stop there. I wanted to see if other sensitive files were exposed, so I attempted to list and download all files from the directory:

wp-content/uploads/

As a result, I was able to access over 250 security reports dating from 2019 to the present day, all containing confidential information about companies that were being security-tested by this platform.

I responsibly reported the vulnerability to the website, but to my surprise, it was rejected as “Out of Scope”, even though the domain was clearly in scope!

I tried reporting it again, but I received the same response. Shortly after, the bug bounty program was paused for two weeks.

A few days later, I revisited the vulnerability to see if it was still exploitable, but I discovered that it had been silently patched without any acknowledgment!🥲

Conclusion

That’s the writeup for this vulnerability! I hope you find it useful. Here’s my advice:

1. Never stop searching and experimenting.
2. Don’t give up, even if your report is rejected.
3. Always aim for the highest possible impact when reporting vulnerabilities.

💪 Persistence and dedication are the keys to success in cybersecurity!