Hi everyone, it's me pr1vacy from Abyssal Hunter. Today, I'm sharing a write-up on how I turned my recon phase into an AWS and DB credentials leak with a CVSS 10.0 impact on Intigriti. Big shout-out to my two partners, insomnia1102 and h4x0rl33tx, who helped me a lot in finding this bug! Let's dive into my write-up, shall we?

I. Recon is the key

Recon is the key to everything — it helps you understand the target, its workflow, and the interesting points that guide you deeper in your bug hunt. I think everyone needs a recon checklist to make sure they cover everything before getting started. But today, I'm not going to dive too deep into recon. As usual, I began my recon on the target: redacted.com — doing things like subdomain discovery, Wayback URLs, Google dorking,…

That's when I found this subdomain: test-*.redacted.com. However, the server returned a 404 unless I provided the full URL, which made it tricky for me to fuzz directories.

So I did some Google dorking related to the domain redacted.com, and I found a domain containing apidoc.html, which I believe was a real-time API access log because I noticed it changed daily. And then I discovered an endpoint on test-*.redacted.com: /solr/<core-name>/admin/ping.

Treasure is coming!

Deeper digging

As I realized the server was using Apache Solr as its search engine, I started researching everything about it — known vulnerabilities, Solr documentation, and more. I was frustrated because the server seemed to have almost everything disabled… until I found the stream.url parameter. At first glance, it appeared to be a blind SSRF. However, a friend of mine and I investigated it further, and one day he said to me:

At that point, it was time to read the documentation. After researching payloads available online and combining them, we were only able to uncover fragmented pieces with limited impact. As a result, we decided to dive into the documentation. I reached out to Insomnia1102, a master at reading docs. By combining insights from the documentation with the payloads we had already found, we finally succeeded in turning a blind SSRF into a typical SSRF. This allowed us to read AWS credentials, as well as Solr configuration files containing database connection strings. Using just a single parameter, we were able to chain the payloads together and achieve full SSRF via stream.contentType.

Reason why we get 10. cvss

So basically, stream.contentType will: - Determines the Parser: It tells Solr which ContentStreamLoader to use. For example, setting stream.contentType=application/json forces Solr to use the JSON loader, regardless of the actual file extension. - Remote Streaming: When using stream.url to fetch data from an external URL, Solr relies on this parameter to know how to parse the incoming data, often ignoring the headers sent by the remote server.

So when you use stream.url + stream.contentType, stream.contentType forces Solr to treat the incoming data as a specific format (like application/xml or application/json), regardless of what the remote server says. Once you force the content type, you can exploit SSRF to leak the data through error messages.

I observed that this payload is still applicable to Solr versions ≤ 9.9.0. However, since remote streaming is disabled by default, it requires a misconfiguration or an explicit unlocking of remote streaming for this technique to be exploitable. Thank you for reading, and shout-out to my two friends who helped me discover this bug.

/solr/<core_name>/select?stream.url=ssrf_payload&stream.contentType=application/json

Always remember to chain small bugs into a high-impact vulnerability, and never skip reconnaissance.

Happy hacking, Pr1vacy.