OpenSearch

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 8 Last 12 months Access control 35 % Auth bypass 25 % Injection 20 % Info disclosure 20 % Latest advisories Loading the feed Overview OpenSearch is the fork of Elasticsearch 7.10 that AWS took over and handed to the Linux Foundation, running as a managed cloud service and across a very large self-hosted base. It indexes logs and application data, and its security plugin is the only thing standing between one tenant and everybody else's documents. Eight CVEs landed against it in the last twelve months. AWS's single public programme is a disclosure programme that names OpenSearch at zero bounty, and Aiven's paid programme covers its own managed service rather than the upstream code, so nobody pays for the engine itself. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy asks for any suspected security issue by email to the project security address and declares no component carve-out. The engine, Dashboards and the plugins the project publishes are all inside it The security plugin end to end: authentication backends, roles and role mappings, index and document permissions, field-level security and document-level security The REST layer in full, covering search, index, bulk, mapping, cluster and cat APIs, along with the request-parsing and authorisation checks in front of them The transport layer and inter-node communication, including node join, cluster state propagation and any request that arrives already trusted Query DSL parsing, aggregations, scripting through Painless and the sandbox around it, and the ingest pipeline processors The SQL and PPL query interfaces, which translate a text query into cluster operations under a caller's identity The alerting, anomaly detection, index management, observability, notifications and reporting plugins, including any outbound request they make on a schedule Snapshot and restore, including repository configuration, remote storage credentials and the restore path that writes index data back into a cluster Cross-cluster search and replication, where one cluster acts on behalf of a user against another OpenSearch Dashboards in full: session handling, saved objects, the proxy that forwards browser requests into the cluster, and the visualisation rendering surface The multi-tenancy features in Dashboards, which are the boundary an operator relies on to keep teams apart in a shared deployment Out of scope Amazon OpenSearch Service, Amazon OpenSearch Serverless and the other AWS-managed offerings, which are a cloud service with their own reporting path Aiven's managed OpenSearch and Aiven's own repositories, which sit inside a separate programme Elasticsearch and Kibana, a different product line under a different vendor with its own paid programme A cluster deployed without the security plugin, without TLS or on an open network, all of which are operator decisions Third-party plugins that are not published by the OpenSearch project Upstream dependencies, unless OpenSearch's own use of them is what makes the defect reachable Most-valued findings Anything that crosses a tenant boundary in the security plugin: reaching an index a role excludes, bypassing document-level security, or recovering fields that field-level security masked. On a shared log cluster that is every other team's data Authentication bypass in any backend the plugin supports, particularly SAML, OIDC and JWT handling, where a crafted assertion or token becomes a cluster identity Privilege escalation through role mapping, where a legitimate identity resolves to permissions the mapping did not intend Injection through the SQL and PPL interfaces, where a text query escapes the translation layer and performs operations the caller's role forbids Painless sandbox escape or any scripting path that reaches the JVM outside the script context, which turns a search request into code execution on a data node Transport-layer requests accepted as pre-authenticated from outside the cluster, which collapses the entire authorisation model in one step Server-side request forgery out of alerting destinations, notification channels, snapshot repository configuration or reporting, since these nodes sit deep inside a production network Saved object and proxy handling in Dashboards, where stored content executes in another user's session or the proxy forwards a request the user could not make directly Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Email [email protected] , the address in the repository SECURITY.md and in the expanded organisation policy GitHub private vulnerability reporting is off on opensearch-project/OpenSearch , so the advisory button is not an option here Do not open a public GitHub issue for a security bug Nothing is paid. AWS's public programme is a disclosure programme with every asset at zero bounty, and it names OpenSearch by name. Aiven's paid Bugcrowd scope covers its managed service, not this codebase Name the OpenSearch version and say whether the security plugin was installed and configured. A finding against a cluster running without it is a configuration argument rather than a vulnerability State which plugins were loaded. Alerting, anomaly detection, the SQL and PPL interfaces and the observability plugins each add API surface, and severity depends on which one you reached Say whether you were on the REST layer or the transport layer, and whether TLS and node-to-node authentication were in place OpenSearch Dashboards is covered by the same policy and the same address Disclosure Coordinated privately by email with the project security team, published as a CVE and an advisory once a fixed release is out. Fixes generally land across the supported minor lines together, and downstream managed services need the patched build before detail is public, so plan on an embargo that runs to the coordinated release rather than to a fixed day count. 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