- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 12
- Public CVEs
- 3
- 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
12 assets you may test, 6 excluded.
Web 1
- https://duckdb.org
Products and areas 11
- Every client binding and its interop layer, covering the Python, R, Java, Node, Rust and WASM builds and the conversion between host objects and engine values
- Every file format reader and writer the engine ships, including Parquet, CSV, JSON, Arrow and the compression codecs behind them
- Remote filesystem access through httpfs and the object-store paths, covering URL handling, redirects and the credentials held for them
- The CLI shell, including its dot-commands and output handling
- The extension mechanism end to end: resolution, download, signature verification, loading and the ABI an extension is trusted across
- The native database file format, its write-ahead log and the code that opens a .duckdb file handed over by someone else
- The published policy asks for any potential security issue through the repository's private advisory form and draws no boundary narrower than the DuckDB tree itself
- The secrets and encryption surface, including how keys are held in memory and written to disk
- The SQL front end in full: the parser, the binder, the optimizer and every function the engine exposes
- The vectorized execution engine and the operators that run over decoded data in memory
- User-defined functions, replacement scans and any other callback where host code and engine code cross
Out of scope (6)
- A host application that hands the engine untrusted SQL with full filesystem permissions and no sandbox, which is an integration decision
- Community extensions maintained outside the DuckDB organisation, unless the defect is in how the core loads or verifies them
- MotherDuck's hosted service, a separate commercial product built on DuckDB rather than the engine itself
- Resource exhaustion from a deliberately expensive query on an engine that was designed to use the whole machine
- Security issues filed as public GitHub issues rather than through the advisory form
- Upstream dependency vulnerabilities, unless DuckDB's own use of the dependency is what 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 GitHub private vulnerability reporting on duckdb/duckdb , using the advisory form the SECURITY.md points at. Private reporting is enabled on that repository
-
Say which build you tested. The same engine ships as a Python wheel, an R package, a JVM jar, a native CLI and a WASM module, and the reachable surface differs between them
-
Attach the input that triggers it: the SQL, the data file, the database file or the extension, whichever one carries the bug
-
State whether the trigger needs an extension to be loaded and whether that extension is signed, since an unsigned-extension requirement changes how the finding is rated
-
Do not file security issues as public GitHub issues on the repository
Not accepted
-
Resource exhaustion from a deliberately expensive query on an engine that was designed to use the whole machine
-
Upstream dependency vulnerabilities, unless DuckDB's own use of the dependency is what makes them reachable
-
Security issues filed as public GitHub issues rather than through the advisory form
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-111497 | A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream. Users need to update any Brotli librarie | Critical 9.2 | 22 Oct 2026 |
| CVE-2025-64429 | DuckDB is a SQL database management system. DuckDB implemented block-based encryption of DB on the filesystem starting with DuckDB 1.4.0. There are a few issues related to this implementation. The DuckDB can fall back to an insecure random number generator (pcg32) to generate cryptographic keys or IVs. When clearing keys from memory, the compiler may remove the memset() and leave sensitive data on | Medium 6.9 | 12 Nov 2025 |
| CVE-2024-41672 | DuckDB is a SQL database management system. In versions 1.0.0 and prior, content in filesystem is accessible for reading using `sniff_csv`, even with `enable_external_access=false`. This vulnerability provides an attacker with access to filesystem even when access is expected to be disabled and other similar functions do NOT provide access. There seem to be two vectors to this vulnerability. First | High 7.5 | 24 Jul 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 4 Last 12 months Memory safety 40 % File format parsing 30 % Extension/code execution 20 % Info disclosure 10 % Latest advisories Loading the feed Overview DuckDB is the embedded analytical database, an in-process engine that runs inside the tool instead of on a server. It ships as a library for Python, R, Java, Node and WASM and sits under dbt models, notebooks and a large share of modern BI stacks, parsing untrusted SQL and untrusted data files inside whatever process loaded it. A defect in a reader is therefore code execution in the host application. Three of the four CVEs published in the past year rated high, CVE-2026-41490 among them. The policy is triage and a CVE with no reward language, and DuckDB Labs runs no bounty programme. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy asks for any potential security issue through the repository's private advisory form and draws no boundary narrower than the DuckDB tree itself The SQL front end in full: the parser, the binder, the optimizer and every function the engine exposes The vectorized execution engine and the operators that run over decoded data in memory Every file format reader and writer the engine ships, including Parquet, CSV, JSON, Arrow and the compression codecs behind them The native database file format, its write-ahead log and the code that opens a .duckdb file handed over by someone else The extension mechanism end to end: resolution, download, signature verification, loading and the ABI an extension is trusted across Remote filesystem access through httpfs and the object-store paths, covering URL handling, redirects and the credentials held for them The secrets and encryption surface, including how keys are held in memory and written to disk Every client binding and its interop layer, covering the Python, R, Java, Node, Rust and WASM builds and the conversion between host objects and engine values User-defined functions, replacement scans and any other callback where host code and engine code cross The CLI shell, including its dot-commands and output handling Out of scope MotherDuck's hosted service, a separate commercial product built on DuckDB rather than the engine itself Community extensions maintained outside the DuckDB organisation, unless the defect is in how the core loads or verifies them Upstream dependency vulnerabilities, unless DuckDB's own use of the dependency is what makes them reachable Resource exhaustion from a deliberately expensive query on an engine that was designed to use the whole machine A host application that hands the engine untrusted SQL with full filesystem permissions and no sandbox, which is an integration decision Security issues filed as public GitHub issues rather than through the advisory form Most-valued findings Memory corruption in a file format reader reachable from a data file alone. Three of the four CVEs in the twelve months to July 2026 rated high (CVE-2025-59037, CVE-2026-32611, CVE-2026-41490), and this engine is routinely pointed at files that arrived from outside Anything where opening a .duckdb database file produces execution or an out-of-bounds access. Database files get emailed and committed to repositories in a way server databases never are Extension loading defects: signature verification bypass, a path that loads an extension the user did not ask for, or an ABI mismatch that turns a benign extension into a crash primitive Server-side request forgery, credential disclosure or arbitrary local file read out of httpfs and the object-store integrations Escapes from the WASM build, where the engine is deliberately running attacker-supplied SQL inside a browser sandbox Defects at the binding boundary that let engine-side data corrupt host-side objects in Python, R or the JVM Any path from pure SQL to filesystem write or process execution without an explicitly enabled extension 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 duckdb/duckdb , using the advisory form the SECURITY.md points at. Private reporting is enabled on that repository There is no money to negotiate. The policy offers triage and a CVE, and the team requests one for confirmed issues, so expect credit in NVD rather than payment Say which build you tested. The same engine ships as a Python wheel, an R package, a JVM jar, a native CLI and a WASM module, and the reachable surface differs between them Attach the input that triggers it: the SQL, the data file, the database file or the extension, whichever one carries the bug State whether the trigger needs an extension to be loaded and whether that extension is signed, since an unsigned-extension requirement changes how the finding is rated Do not file security issues as public GitHub issues on the repository Disclosure Coordinated privately through the GitHub advisory form and published as a GitHub Security Advisory alongside a patched release, with a CVE requested by the team for confirmed issues. The policy sets no fixed number of days, so plan for an embargo that runs to the next release. Hold the detail until the advisory is public. 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