dbt-core

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 6 Lifetime Template injection 35 % Credential exposure 25 % Supply chain 20 % Parsing/validation 20 % Latest advisories Loading the feed Overview dbt-core is the transformation layer in most modern data warehouses. It compiles Jinja templates into SQL and runs that SQL against Snowflake, BigQuery, Databricks or Redshift holding production warehouse credentials, and it pulls around 110 million PyPI downloads a month inside dbt Cloud, Fivetran and every major orchestrator. The execution model is the attack surface: a template becomes SQL becomes a query executed with warehouse privileges, and the packages.yml resolver fetches other people's code from the dbt hub before any of that starts. dbt Labs is a well-funded vendor that chose compliance certifications over a bounty and runs no programme anywhere. sorona.xyz pays you directly on qualified, reproduced findings. In scope There is no narrower declaration to work from: the project publishes no SECURITY.md, and the vendor trust page's research and disclosure section draws no boundary. The whole dbt-core package and the adapters the project maintains are the target The Jinja compilation path end to end: template rendering, the macro namespace, the context objects exposed to a template, and everything that reaches the compiled SQL The macro and materialisation system, including how a macro is resolved, overridden and dispatched across packages and adapters Project file parsing: dbt_project.yml , model and source YAML, schema tests, seeds and the exposures and metrics definitions The manifest, covering how it is written, read back and trusted on a later run, and the state comparison that a deferred or slim run depends on Package resolution through packages.yml : hub lookups, git and local package sources, version resolution and everything that happens when the fetched code is loaded Adapter credential handling in profiles.yml and through environment variables, including how a credential reaches a connection and whether it can reach a log The adapter and connection layer the project maintains, including identifier quoting, relation naming and query construction Logging and artifact output, covering the run results and manifest artifacts and anything that could carry a secret into a file a CI job publishes The command-line interface and its flag and variable handling, including --vars and the environment variable functions available inside templates Out of scope dbt Cloud, the hosted product, along with Snowflake, Databricks and Fivetran integrations that embed dbt. Those belong to their vendors Community adapters and community packages published on the hub that dbt Labs does not maintain A project author writing a macro or a model that executes SQL with the credentials they configured, which is what dbt does A warehouse role granted more privilege than it needed, which is a configuration decision by the operator Upstream Jinja2, agate or Python dependency bugs, unless dbt's own use of the dependency is what makes them reachable Most-valued findings Template injection where content a project author did not write reaches Jinja rendering and then the compiled SQL, since that path ends in a query executed with warehouse credentials Escapes from the template sandbox into the Python context, where a rendered macro reaches attributes or callables the context was not meant to expose SQL injection through identifier and relation handling in an adapter, particularly where a source name, column name or variable is interpolated rather than quoted Anything in the package resolution and hub-fetch path that lets a fetched package run code at install or parse time, or that lets a resolution be redirected. This is the supply-chain surface and it runs before the project author reviews anything Credential exposure from profiles.yml , environment variables or the connection layer into logs, artifacts or compiled SQL, since CI pipelines routinely publish those artifacts Manifest and state handling defects, where a run trusts an artifact from a previous run or from another environment and acts on it Deserialisation or unsafe loading in the YAML and artifact parsing paths, which run before any user-facing validation does 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. Use GitHub private vulnerability reporting on dbt-labs/dbt-core . It is enabled and it is the channel the project's existing advisories were published through There is no SECURITY.md in the repository at any path, so the advisory button is the documented route rather than a fallback getdbt.com/security is a compliance and trust page covering SOC 2, HIPAA and penetration testing. It has a research and disclosure section and no reward language of any kind Separate dbt-core from dbt Cloud. A finding in the hosted product belongs to dbt Labs' own service; this card covers the open-source package Name the adapter. Snowflake, BigQuery, Databricks, Redshift and Postgres adapters are separate packages with their own credential handling and their own quoting rules Show who controls the template. A project author writing a macro that runs SQL is dbt working as designed; the finding has to involve input the project author did not write Say whether the finding needs a package from the hub, since package resolution pulls code that a third party publishes Disclosure Coordinated privately through GitHub's advisory workflow on dbt-labs/dbt-core and published as a GitHub Security Advisory once a fixed version is released. Six advisories have come out that way, two of them in the last twelve months, so the pipeline works even without a written policy behind it. Expect the embargo to run to a patched release on PyPI, and expect a fix that touches an adapter to need coordinated releases across the adapter packages too. 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