dbt-core v1.11.15 - Package Install Path Validation

dbt-core v1.11.15 was published on 8 September 2026. The patch validates that a resolved package installation path stays inside the configured packages-install-path. The notes list that one fix and mark the build as a stable release, not a prerelease.

The full release notes and downloads are on the GitHub release page.

dbt deps installs the sources listed in packages.yml into a directory the project selects. That directory is the packages-install-path setting in the dbt project config. When the setting is omitted, dbt uses a dbt_packages directory next to dbt_project.yml.

The new check runs on the resolved destination. Resolution is the step that turns a package source into a concrete filesystem path. After that path is known, the installer asks whether it still sits inside the configured install root. If it does not, the path is invalid.

A resolved path can leave the install root when a source uses .. segments, when a link points outside the tree, or when an absolute path is supplied. The notes do not enumerate those cases. They are the usual ways a resolved path stops matching the directory set in config.

packages-install-path: dbt_packages

No new config key is added. Hub, git, and local package syntax are unchanged. Compile, run, test, and snapshot are not mentioned. The change is confined to package installation.

On an ELT platform this is an operator concern because dbt deps is often an unattended CI step. The process may run as a service account, in a container, or on a shared runner with a mounted workspace. A write that escapes dbt_packages can touch project SQL, CI glue, or files outside the job directory. The limit is the uid of the process and the mounts of the job, not the dbt project boundary.

Package install is also on the data path. Macros and models from packages are compiled into the same DAG as first party code. If dbt deps can place a .sql file under models/ or overwrite a macro, the next dbt run executes that file. A path check on the install root is a write fence before compile, not a style rule.

The changelog does not cite a CVE, a commit, or a real issue number. The GitHub notes point at a placeholder issue id. Read the release page as the source of record.

The practical change is the failure mode. A destination that previously wrote outside packages-install-path should now fail the command instead of writing there.

If packages-install-path points at a cache volume or a path outside the git worktree, that remains valid. The check is against the configured root, not against the repo root. A dedicated cache directory is fine if every resolved install stays under that prefix. A layout that uses .. to reach a sibling project directory is the case that now fails.

When a job starts failing after the pin, inspect package sources that use local paths or custom install locations. Packages that unpack to dbt_packages/<name> from Hub are unlikely to trip the check. A local package whose path walks above the install root is the likely trigger.

The notes do not document a CLI flag or a config switch that turns the check off. There is no documented bypass in this release. If a workspace layout depends on writing outside packages-install-path, that layout is invalid on v1.11.15.

Shared caches across several dbt projects need a pass as well. The check does not merge trees. It only asks whether one resolved path is inside one configured root. Cross project layouts that assumed a relative walk into a sibling folder will fail.

Keep dbt deps logs. The notes do not publish the error string, so match on command failure and on the install path in the project config. Compare the configured packages-install-path with the destinations recorded in those logs before changing package sources.

v1.11.15 is a patch on the 1.11 line. The notes list no adapter bump, no breaking API change, and no migration procedure.

Pin dbt-core==1.11.15 in the same artifact you already use: requirements.txt, a lock file, a container image tag, or the orchestrator image. Run dbt deps once against the production packages.yml in a clean workspace. If the command succeeds and the contents of dbt_packages match what you already ship, the bump is done.

The release is not a release candidate, beta, or alpha. GitHub marks it as a full release.

No internal refactor is listed. Do not expect a behavior change in parse, compile, or run. The only documented change is the package install path check.

The notes credit @ash2shukla. That is the only named contributor.