Skip to content

VictoriaMetrics

Bug bounty on Sorona victoriametrics.com

Accepting reports open-source
Top reward
$1,500
Top severity paid
Critical
Assets in scope
15
Public CVEs
2
Last change
No changes yet

At a glance

What to know before you start testing.

Pays from $1,500
for critical bugs.
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 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

15 assets you may test, 6 excluded.

Web 1

  • https://victoriametrics.com

Products and areas 14

  • Backup and restore against object storage, including how the credentials for it are handled
  • Ingestion in full, covering Prometheus remote write and the compatibility endpoints for Influx line protocol, Graphite, OpenTSDB and other formats the suite accepts
  • The authentication and routing proxy shipped with the suite, and the rules it uses to decide what a caller may reach
  • The bundled web interface and everything reachable from it
  • The cluster build and the separation between the ingestion, storage and query tiers, including the inter-component calls each tier accepts
  • The documented policy asks for any security issue by email to the security alias, reinforced by a signed security.txt naming the same contact. It states no scope boundary, so the whole suite is in
  • The Helm charts and the Kubernetes operator, which is how most of these deployments are actually configured
  • The multi-tenancy boundary in the cluster build, where a tenant identifier in the request decides whose series are read, written or deleted
  • The on-disk data format and what happens when a process opens data it did not write
  • The query layer end to end: PromQL and MetricsQL parsing, evaluation and the query APIs that dashboards talk to
  • The single-node database and its entire HTTP surface, including the administrative and debug routes
  • VictoriaLogs, its ingest paths and its query surface
  • vmagent, including scrape configuration, service discovery and the credentials it holds for both targets and remote-write destinations
  • vmalert, its rule evaluation and its connections to the alert manager and to notification endpoints
Out of scope (6)
  • A component deliberately exposed to an untrusted network without the reverse proxy or auth layer the docs assume, which is a deployment decision
  • Findings against releases outside the supported and LTS lines
  • Prometheus, Grafana or Alertmanager defects reached through VictoriaMetrics rather than caused by it
  • Resource exhaustion from a query the operator sized the cluster for, or from an ingest rate above the configured limits
  • The vendor's hosted offering as infrastructure, where the finding cannot be reproduced against the open source build
  • Upstream dependency advisories with no demonstrated reachable path, since the project already runs govulncheck in CI

Rules

What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.

While testing

  • Submit through sorona.xyz.
  • Email the address on the policy page , the address the docs name and the same contact listed in the PGP-signed security.txt
  • Name the component precisely.
  • Give the version and say whether the LTS lines are affected.
  • Include the exact request and state whether the endpoint required credentials in your deployment
  • Show reachability if you are reporting one
  • Hold the detail until it is out.

Not accepted

  • Upstream dependency advisories with no demonstrated reachable path
  • Resource exhaustion from a query the operator sized the cluster for, or from an ingest rate above the configured limits
  • Findings against releases outside the supported and LTS lines
  • Prometheus, Grafana or Alertmanager defects reached through VictoriaMetrics rather than caused by it

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 9 minutes 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.

Search NVD

Sorona credits this project with 2 CVEs, 2 of them recent. The individual records appear here after the next sync.

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 2 Last 12 months 2 Lifetime Access control 35 % SSRF/outbound fetch 30 % Info disclosure 20 % Parsing/validation 15 % Latest advisories Loading the feed Overview VictoriaMetrics is the drop-in long-term store for Prometheus metrics, run by operators who outgrew Prometheus itself and packaged into the Helm charts and Kubernetes operators of a lot of production infrastructure. It concentrates the observability history of an entire estate in one place, along with the scrape credentials and alert routes that reach it. The published record is thin: two advisories ever, both landing in the past twelve months, neither above medium severity. That reads as under-examined surface rather than a hardened target. The vendor is commercial, publishes a signed security.txt and a documented CVE policy, and attaches no money to any of it. sorona.xyz pays you directly on qualified, reproduced findings. In scope The documented policy asks for any security issue by email to the security alias, reinforced by a signed security.txt naming the same contact. It states no scope boundary, so the whole suite is in The single-node database and its entire HTTP surface, including the administrative and debug routes The cluster build and the separation between the ingestion, storage and query tiers, including the inter-component calls each tier accepts The multi-tenancy boundary in the cluster build, where a tenant identifier in the request decides whose series are read, written or deleted The query layer end to end: PromQL and MetricsQL parsing, evaluation and the query APIs that dashboards talk to Ingestion in full, covering Prometheus remote write and the compatibility endpoints for Influx line protocol, Graphite, OpenTSDB and other formats the suite accepts vmagent, including scrape configuration, service discovery and the credentials it holds for both targets and remote-write destinations vmalert, its rule evaluation and its connections to the alert manager and to notification endpoints The authentication and routing proxy shipped with the suite, and the rules it uses to decide what a caller may reach Backup and restore against object storage, including how the credentials for it are handled The bundled web interface and everything reachable from it VictoriaLogs, its ingest paths and its query surface The on-disk data format and what happens when a process opens data it did not write The Helm charts and the Kubernetes operator, which is how most of these deployments are actually configured Out of scope The vendor's hosted offering as infrastructure, where the finding cannot be reproduced against the open source build A component deliberately exposed to an untrusted network without the reverse proxy or auth layer the docs assume, which is a deployment decision Resource exhaustion from a query the operator sized the cluster for, or from an ingest rate above the configured limits Upstream dependency advisories with no demonstrated reachable path, since the project already runs govulncheck in CI Findings against releases outside the supported and LTS lines Prometheus, Grafana or Alertmanager defects reached through VictoriaMetrics rather than caused by it Most-valued findings Any endpoint that answers without credentials in a common deployment, above all the ones that delete series or change configuration on a running instance Tenant crossover in the cluster build: reading, writing or deleting another tenant's series through a crafted identifier or a path that skips the check Server-side request forgery out of scrape configuration, service discovery, remote-write destinations or notifier URLs. vmagent's whole job is making outbound requests on instruction Disclosure of the credentials the suite holds for scrape targets, remote-write endpoints or object storage, since those credentials usually reach the monitored infrastructure Anything that turns ingested metric or log data into memory corruption, a file write or an unexpected process action Authorisation defects in the routing proxy, where a rule that should deny a path lets it through Findings above medium severity of any kind. The two advisories on record, CVE-2026-61625 and CVE-2025-65942, sit at medium and low, so the upper range of this target is genuinely unmapped 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 the docs name and the same contact listed in the PGP-signed security.txt There is no reward attached. The signed security.txt carries contact and policy links only, and no page on the vendor site mentions a bounty Name the component precisely. The suite covers the single-node database, the cluster build, vmagent, vmalert and VictoriaLogs, and they have separate surfaces under one policy Give the version and say whether the LTS lines are affected. The project's CVE policy requires a fix before the next release and a backport to LTS, so that answer shapes the release plan Include the exact request and state whether the endpoint required credentials in your deployment, since a great deal of this surface is commonly run behind a reverse proxy The project runs govulncheck in CI, so a dependency advisory it already tracks is unlikely to be news. Show reachability if you are reporting one Disclosure Coordinated privately by email with the maintainers under a documented CVE-handling policy: a fix is required before the next release and backported to the supported LTS lines, with the advisory published on the repository. No fixed day count is published, so the embargo tracks that release and backport cycle. Hold the detail until it is 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