Elasticsearch

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Critical (Elasticsearch asset row) │ $7,000 │ $8,000 High │ $3,000 │ $3,750 Medium │ $1,500 │ $1,875 Low │ $700 │ $875 Submit a vulnerability CVE history 32 Last 12 months 133 Lifetime Access control 30 % Info disclosure 25 % Denial of service 20 % Code execution 15 % Latest advisories Loading the feed Overview Elasticsearch is the default full-text and document store behind the majority of the world's log-search and observability stacks: it is the E in ELK, it ships inside SIEM deployments at most large enterprises, and it is embedded in commercial products from network appliances to e-commerce search. It is also one of the most-scanned services on the public internet, with Shodan routinely showing six figures of exposed 9200 and 9300 endpoints, and exposed unauthenticated clusters have been the root cause of a long series of mass data-leak incidents, so the blast radius of an Elasticsearch authorization bypass is measured in petabytes of other people's data. The AGPL relicensing in 8.16 pulled a large self-hosting population back onto genuinely open-source builds. Elastic N.V. pays it on HackerOne against a bound per-asset row that runs from $700 for a Low to $7,000 for a Critical, and those numbers are minimums the program awards up from rather than fixed prices. sorona.xyz adds 1.25x on top of whatever Elastic awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. Response times ~11 hours First response ~6 days Triage ~43 days Bounty In scope Elastic states the asset in one line: any supported, non-EOL version of Elasticsearch, covering the platform downloads, the container on docker.elastic.co, the github.com/elastic/elasticsearch source tree and a running instance on Elastic Cloud, all bounty-eligible up to critical severity The policy invites the whole product rather than a shortlist: 'Find an IDOR in Elasticsearch? Report it... If we wrote code with a bug in it, we want to know about it! Our code is open so use that to your advantage!' The REST layer in full, every documented API on 9200, together with the node-to-node transport protocol on 9300 and the cluster coordination and replication that ride on it The security subsystem: authentication realms, role-based access control, API keys and service tokens, field-level and document-level security, and cross-cluster access The query path: query DSL parsing, aggregations, runtime fields, search templates, the ES|QL engine and the Painless scripting sandbox Indexing and ingest: mapping and dynamic templates, ingest pipelines and their processors, bulk indexing and the document parsers that read whatever a client sends Storage and cluster operations: the Lucene-backed shard layer, snapshot and restore against object stores, repository handling, recovery and the reindex and remote-cluster clients Modules and plugins shipped in the distribution, along with x-pack/ , which is paid on the same row even though its Elastic Licence puts it outside the open-source gate Out of scope Anything that requires administrative or root OS privileges to exploit, since Elastic does not treat that as a security boundary Findings only reproducible on end-of-life or legacy versions; the release has to be on Elastic's supported list Volumetric denial of service, defined by the policy as 'network flooding, request flooding, port flooding, required traffic volume scaling with deployment size', which is never eligible for a bounty reward Cross-site scripting without a CSP bypass, which is assessed case by case and may be paid only at low severity if at all Third-party components and services, which fall outside the policy even when Elasticsearch ships or depends on them Assets from recent Elastic acquisitions for at least six months after the deal closes, which currently keeps *.jina.ai and *.keephq.dev out of scope Application-layer findings only shown on a deployment below the 1 CPU and 2 GB RAM floor the program requires Elastic's build and release tooling, which is paid on the separate Software Supply Chain row rather than as an Elasticsearch finding Most-valued findings Authentication or authorization bypass that reaches cluster data without valid credentials, the shape that turns an internet-exposed cluster into a mass data leak and the clearest route to the $7,000 critical row Access-control failure inside the security layer, the largest class at 30% of history: a request reaching an index, document or cluster API the deployment meant to keep it away from Code execution on a data or master node from a query, script, mapping or ingest pipeline that an ordinary cluster user is allowed to submit Cross-index or cross-tenant document disclosure through search, aggregation, or field-level and document-level security handling A single crafted request, mapping or query that takes down a node or cluster, provided the impact does not come from traffic volume Any of the above demonstrated on a default configuration of a currently supported release rather than one the reporter had to weaken first Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Reproduce the bug on a currently maintained, non-EOL release; anything that only works on a legacy build is out of scope Application-layer findings must be reproduced on a deployment with at least 1 CPU and 2 GB of RAM Findings that need root or administrator OS privileges to begin with are out of scope, because Elastic does not treat the administrator-to-kernel boundary as a security boundary Volumetric denial of service is never eligible for a bounty, however cleanly it is demonstrated The licence gate passes on the AGPLv3 option only: code under x-pack/ is Elastic License 2.0, still bounty-eligible, but not an open-source finding Program stats 891 Reports resolved $986k Bounties paid 79% Response efficiency Disclosure Coordinated through HackerOne, and Elastic asks only that reporters follow HackerOne's own disclosure guidelines. Nothing in the policy bars a third party from being involved, so sorona.xyz can route the report and hold it until Elastic has shipped a fix and published its advisory. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability