- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 8
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
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.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
13 assets you may test, 6 excluded.
Web 1
- https://openobserve.ai
Products and areas 12
- Alerts, destinations and templates, which evaluate queries on a schedule and post results to an endpoint a user configured
- Authentication and session handling, covering local accounts, API tokens, the basic auth path, SSO and single sign-on provisioning
- Clustering, covering ingester, querier, compactor and router roles and any inter-node request that arrives already trusted
- Dashboards, folders, saved views and the sharing model, including any dashboard reachable without a session
- Pipelines and the enrichment tables, which transform records in flight and pull in reference data
- Stream and schema handling, including dynamic schema inference, field limits and anything that lets ingested data change how later data is stored
- The ingestion API in full, covering the bulk, JSON, multi, Elasticsearch-compatible, OpenTelemetry, Prometheus remote-write, syslog and Kinesis endpoints, plus the parsers behind each
- The object storage and local storage backends, including WAL handling, compaction, the file list metadata and the credentials configured for remote storage
- The organisation and user model in full, covering roles, groups, permissions and every check that decides whether a user reaches a stream, dashboard, alert or pipeline
- The policy asks for private disclosure of any vulnerability and declares no component carve-out. Everything the platform ships is inside it
- The query layer end to end: the SQL interface, PromQL, the VRL transform functions and the aggregation cache
- User-defined VRL functions and the sandbox around them, which run against ingested records inside the server process
Out of scope (6)
- A deployment left with default credentials or exposed on a public network, which is an operator decision
- Object storage services and the databases the platform stores metadata in, each of which has its own vendor process
- OpenObserve's hosted cloud infrastructure rather than the product code
- Public GitHub issues, which are not a private channel for a security report
- Third-party integrations and collectors outside the project's own repositories
- Upstream crates and libraries, unless OpenObserve's own use of them is what makes the defect reachable
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Report through GitHub private vulnerability reporting on the OpenObserve repository, which is enabled, or through the channel named in the project's SECURITY.md
-
Do not open a public GitHub issue for a security bug
-
Pin the version. This project ships fast and the surface changes between releases, so a finding without an exact version may not reproduce for a triager
-
Say which organisation and role the attacker held, and whether the target was a single-tenant or multi-organisation deployment. Isolation is the security model here
-
State whether you reached it through the ingestion API, the query API or the UI. The three have different authentication expectations and different exposure in a typical deployment
-
Hold detail until the advisory and the release are out.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-39361 | OpenObserve is a cloud-native observability platform. In 0.70.3 and earlier, the validate_enrichment_url function in src/handler/http/request/enrichment_table/mod.rs fails to block IPv6 addresses because Rust's url crate returns them with surrounding brackets (e.g. "[::1]" not "::1"). An authenticated attacker can reach internal services blocked from external access. On cloud deployments this enab | High 7.7 | 7 Apr 2026 |
| CVE-2024-41809 | OpenObserve is an open-source observability platform. Starting in version 0.4.4 and prior to version 0.10.0, OpenObserve contains a cross-site scripting vulnerability in line 32 of `openobserve/web/src/views/MemberSubscription.vue`. Version 0.10.0 sanitizes incoming html. | High 7.2 | 25 Jul 2024 |
| CVE-2024-41808 | The OpenObserve open-source observability platform provides the ability to filter logs in a dashboard by the values uploaded in a given log. However, all versions of the platform through 0.9.1 do not sanitize user input in the filter selection menu, which may result in complete account takeover. It has been noted that the front-end uses `DOMPurify` or Vue templating to escape cross-site scripting | High 8.8 | 25 Jul 2024 |
| CVE-2024-24830 | OpenObserve is a observability platform built specifically for logs, metrics, traces, analytics, designed to work at petabyte scale. A vulnerability has been identified in the "/api/{org_id}/users" endpoint. This vulnerability allows any authenticated regular user ('member') to add new users with elevated privileges, including the 'root' role, to an organization. This issue circumvents the intende | Critical 9.9 | 8 Feb 2024 |
| CVE-2024-25106 | OpenObserve is a observability platform built specifically for logs, metrics, traces, analytics, designed to work at petabyte scale. A critical vulnerability has been identified in the "/api/{org_id}/users/{email_id}" endpoint. This vulnerability allows any authenticated user within an organization to remove any other user from that same organization, irrespective of their respective roles. This i | Critical 9.1 | 8 Feb 2024 |
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
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 3 Last 12 months 8 Lifetime Access control 35 % Tenant isolation 25 % Injection 20 % SSRF 20 % Latest advisories Loading the feed Overview OpenObserve is the observability platform pitched as a cheap replacement for Elastic or Splunk, and it holds exactly what those systems hold: the telemetry, the captured request bodies and the credentials that leak into them. One deployment serves many organisations, so the tenant boundary carries the weight. Three CVEs landed in the last twelve months out of eight advisories ever, on a project growing fast enough that the surface moves between releases. The policy is blunt about money: no public bug bounty programme, credit in the release notes and occasional swag. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy asks for private disclosure of any vulnerability and declares no component carve-out. Everything the platform ships is inside it The organisation and user model in full, covering roles, groups, permissions and every check that decides whether a user reaches a stream, dashboard, alert or pipeline The ingestion API in full, covering the bulk, JSON, multi, Elasticsearch-compatible, OpenTelemetry, Prometheus remote-write, syslog and Kinesis endpoints, plus the parsers behind each Stream and schema handling, including dynamic schema inference, field limits and anything that lets ingested data change how later data is stored The query layer end to end: the SQL interface, PromQL, the VRL transform functions and the aggregation cache User-defined VRL functions and the sandbox around them, which run against ingested records inside the server process Authentication and session handling, covering local accounts, API tokens, the basic auth path, SSO and single sign-on provisioning Dashboards, folders, saved views and the sharing model, including any dashboard reachable without a session Alerts, destinations and templates, which evaluate queries on a schedule and post results to an endpoint a user configured Pipelines and the enrichment tables, which transform records in flight and pull in reference data The object storage and local storage backends, including WAL handling, compaction, the file list metadata and the credentials configured for remote storage Clustering, covering ingester, querier, compactor and router roles and any inter-node request that arrives already trusted Out of scope OpenObserve's hosted cloud infrastructure rather than the product code Object storage services and the databases the platform stores metadata in, each of which has its own vendor process A deployment left with default credentials or exposed on a public network, which is an operator decision Upstream crates and libraries, unless OpenObserve's own use of them is what makes the defect reachable Third-party integrations and collectors outside the project's own repositories Public GitHub issues, which are not a private channel for a security report Most-valued findings Cross-organisation access of any kind: querying a stream, reading a dashboard or altering an alert belonging to another organisation on a shared deployment. Telemetry stores hold other people's request bodies, so this is a direct data breach Ingestion endpoints reachable without a valid token, or with a token whose organisation scope is not enforced, which lets an outsider write into or read from another tenant's stream Query injection through the SQL or PromQL layer, where a filter or a function escapes the intended stream and reaches data the role excludes VRL sandbox escape, where a user-defined transform function reaches the filesystem, the network or memory outside its record. These functions run inside the server on every matching record Server-side request forgery through alert destinations, pipeline endpoints or remote storage configuration, since this host sits inside the network it collects telemetry from Anything that returns stored credentials: remote storage keys, SSO secrets, destination tokens or another user's API token Parser defects reachable from an ingested record, since the input arrives from agents and applications the operator may not fully control, and it is the one surface guaranteed to be exposed 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. Report through GitHub private vulnerability reporting on the OpenObserve repository, which is enabled, or through the channel named in the project's SECURITY.md Do not open a public GitHub issue for a security bug Nothing is paid. The policy states there is no public bug bounty programme and offers credit in release notes or advisories plus occasional swag The policy asks for consent before crediting you, so say in the report whether you want to be named Pin the version. This project ships fast and the surface changes between releases, so a finding without an exact version may not reproduce for a triager Say which organisation and role the attacker held, and whether the target was a single-tenant or multi-organisation deployment. Isolation is the security model here State whether you reached it through the ingestion API, the query API or the UI. The three have different authentication expectations and different exposure in a typical deployment Disclosure Coordinated privately through the project's own channels and published as a GitHub Security Advisory with a CVE alongside a release. Eight advisories over the project's life against three in the last year shows the cadence accelerating with adoption, and fixes land quickly given the release pace. The policy offers public credit with your consent. Hold detail until the advisory and the release are out. 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