Skip to content
bugbounty.fyi
Get paid to secure open source 475 paid open-source programs on Sorona, up to $1M Perk Low bugs: $100 or 1 mo Claude Max

Also on Patchstack. All 476 paid open-source programs

Try

Highest paying Newly launched Paid without KYC Full safe harbor
All results

About this site

TDengine

Bug bounty on Sorona tdengine.com

Accepting reports open-source
Go to program Website
Top reward
$1,500
Top severity paid
Critical
Assets in scope
13
Public CVEs
15
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 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://tdengine.com

Products and areas 12

  • On-disk storage files, metadata and the write-ahead log, including what happens when the server opens data it did not write
  • Stream processing, continuous queries and the data subscription surface
  • The CLI and the administrative and monitoring components shipped alongside the server
  • The cluster layer: node membership, replication, leader election and the RPC that nodes trust from one another
  • The database server process end to end, including the query engine and every operator it runs
  • The HTTP and REST interface that fronts the server, covering every route it exposes
  • The native client library and every language connector built on top of it, along with the wire protocol between them and the server
  • The published policy is one line asking for submissions through the repository's advisory page. It draws no boundary at all, so the whole TDengine tree is in scope
  • The SQL layer: parsing, planning, function evaluation and the built-in functions a query can reach
  • The write path in full: schemaless ingest, the compatibility endpoints for other databases' line protocols and the parsers behind each of them
  • User-defined function loading and execution
  • Users, privileges and database-level permissions, including how a permission decision is cached
Out of scope (6)
  • A server deliberately exposed to an untrusted network with default credentials in place, which is a deployment decision
  • Findings already covered by one of the project's published advisories
  • Resource exhaustion from a query or an ingest rate the operator sized the machine for
  • The commercial enterprise and cloud editions, where a finding cannot be reproduced against the open source server
  • Third-party connectors and integrations maintained outside the project
  • Upstream dependency vulnerabilities, unless TDengine's own use of the dependency makes them 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 the GitHub advisory page on taosdata/TDengine , the only channel the SECURITY.md names.
  • Name the exact server version and the edition.
  • Include the request or the ingested payload that triggers it, and say which interface carried it
  • State the authentication level required
  • check the existing advisory list before reporting so you are not duplicating a fix already in flight
  • Hold the detail until the advisory is published.

Not accepted

  • Upstream dependency vulnerabilities, unless TDengine's own use of the dependency makes them reachable
  • Resource exhaustion from a query or an ingest rate the operator sized the machine for
  • Findings already covered by one of the project's published advisories

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.

Search NVD
CVESeverityPublished
CVE-2026-42542 High 7.5 10 Jun 2026
CVE-2023-38502 Medium 6.5 25 Jul 2023
CVE-2023-34111 High 8.1 6 Jun 2023

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 14 Last 12 months 15 Lifetime Memory safety 40 % Auth/access control 25 % Protocol parsing 20 % Info disclosure 15 % Latest advisories Loading the feed Overview TDengine is a time-series database built for machine data: industrial plant telemetry, energy metering and connected-vehicle fleets. It is the dominant open-source option for that work in China and a common InfluxDB replacement elsewhere, and what it holds is the operational record of physical infrastructure. The advisory record is the anchor here. Fourteen of the fifteen advisories the project has ever published landed in the past twelve months, several of them rated high, and every reporter behind them was paid nothing. TAOS Data publishes no reward language on its security pages and appears on no bounty platform. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy is one line asking for submissions through the repository's advisory page. It draws no boundary at all, so the whole TDengine tree is in scope The database server process end to end, including the query engine and every operator it runs The SQL layer: parsing, planning, function evaluation and the built-in functions a query can reach The HTTP and REST interface that fronts the server, covering every route it exposes The native client library and every language connector built on top of it, along with the wire protocol between them and the server The write path in full: schemaless ingest, the compatibility endpoints for other databases' line protocols and the parsers behind each of them Stream processing, continuous queries and the data subscription surface The cluster layer: node membership, replication, leader election and the RPC that nodes trust from one another Users, privileges and database-level permissions, including how a permission decision is cached On-disk storage files, metadata and the write-ahead log, including what happens when the server opens data it did not write User-defined function loading and execution The CLI and the administrative and monitoring components shipped alongside the server Out of scope The commercial enterprise and cloud editions, where a finding cannot be reproduced against the open source server Upstream dependency vulnerabilities, unless TDengine's own use of the dependency makes them reachable A server deliberately exposed to an untrusted network with default credentials in place, which is a deployment decision Resource exhaustion from a query or an ingest rate the operator sized the machine for Findings already covered by one of the project's published advisories Third-party connectors and integrations maintained outside the project Most-valued findings Memory corruption in the server reachable from a query or from ingested data. This is a C database taking input from field equipment, so an out-of-bounds write in a parser is a remote primitive on the box Anything reachable before authentication on the REST interface or the native protocol port. The high-severity end of the recent record sits here, including GHSA-vqj6-pwq9-qc5j and GHSA-v8cj-fw82-9jjf Privilege and permission defects: a read-only user writing, a database-scoped user reaching another database, or a permission cached past a revocation Parsing defects in the schemaless and compatibility ingest paths, where the input arrives from devices nobody authenticates carefully Trust between cluster nodes, where an RPC accepted from a peer changes replication state or executes work on another node User-defined function loading that reaches the filesystem or the process outside the intended sandbox Disclosure of credentials or of another tenant's series data from any endpoint, including diagnostic and monitoring routes 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 the GitHub advisory page on taosdata/TDengine , the only channel the SECURITY.md names. The maintainers use it actively and publish there There is no reward to negotiate. The published policy is one line of routing, and the vendor security site carries no bounty or payment language at all Name the exact server version and the edition. The open source server is the target here; findings that only reproduce against the commercial enterprise build are a different conversation Include the request or the ingested payload that triggers it, and say which interface carried it: the SQL layer, the REST interface, a native connector or a compatibility ingest endpoint State the authentication level required, since the difference between an authenticated user and an unauthenticated network peer decides the severity on a database that usually sits on an operational network Given how many advisories this project publishes, check the existing advisory list before reporting so you are not duplicating a fix already in flight Disclosure Coordinated through GitHub Security Advisories on the project repository, with the maintainers publishing there and requesting CVEs. The advisory stream runs in batches tied to releases rather than to a fixed embargo clock, so expect the timeline to follow the next server release. Hold the detail until the advisory is published. 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