GHSA-G87C-R2JP-293W

Vulnerability from github – Published: 2026-04-01 00:23 – Updated: 2026-04-01 00:23
VLAI?
Summary
@tinacms/graphql's Media Endpoints Can Escape the Media Root via Symlinks or Junctions
Details

Summary

@tinacms/cli recently added lexical path-traversal checks to the dev media routes, but the implementation still validates only the path string and does not resolve symlink or junction targets.

If a link already exists under the media root, Tina accepts a path like pivot/written-from-media.txt as "inside" the media directory and then performs real filesystem operations through that link target. This allows out-of-root media listing and write access, and the same root cause also affects delete.

Details

The dev media handlers validate user-controlled paths with:

function resolveWithinBase(userPath: string, baseDir: string): string {
  const resolvedBase = path.resolve(baseDir);
  const resolved = path.resolve(path.join(baseDir, userPath));
  if (resolved === resolvedBase) {
    return resolvedBase;
  }
  if (resolved.startsWith(resolvedBase + path.sep)) {
    return resolved;
  }
  throw new PathTraversalError(userPath);
}

function resolveStrictlyWithinBase(userPath: string, baseDir: string): string {
  const resolvedBase = path.resolve(baseDir) + path.sep;
  const resolved = path.resolve(path.join(baseDir, userPath));
  if (!resolved.startsWith(resolvedBase)) {
    throw new PathTraversalError(userPath);
  }
  return resolved;
}

But the validated path is then used directly for real filesystem access:

filesStr = await fs.readdir(validatedPath);
...
await fs.ensureDir(path.dirname(saveTo));
file.pipe(fs.createWriteStream(saveTo));
...
await fs.remove(file);

This does not account for symlinks/junctions already present below the media root. A path such as pivot/secret.txt can be lexically inside the media directory while the filesystem target is outside it.

Local Reproduction

I verified this locally with a real junction on Windows.

Test layout:

  • media root: D:\bugcrowd\tinacms\temp\junction-repro4\public\uploads
  • junction under media root: public\uploads\pivot -> D:\bugcrowd\tinacms\temp\junction-repro4\outside
  • file outside the media root: outside\secret.txt

Tina's current media-path validation logic was applied and used to perform the same list/write operations the route handlers use.

Observed result:

{
  "media": {
    "base": "D:\\bugcrowd\\tinacms\\temp\\junction-repro4\\public\\uploads",
    "resolvedListPath": "D:\\bugcrowd\\tinacms\\temp\\junction-repro4\\public\\uploads\\pivot",
    "listedEntries": [
      "secret.txt"
    ],
    "resolvedWritePath": "D:\\bugcrowd\\tinacms\\temp\\junction-repro4\\public\\uploads\\pivot\\written-from-media.txt",
    "outsideWriteExists": true,
    "outsideWriteContents": "MEDIA_ESCAPE"
  }
}

This shows the problem clearly:

  • the path validator accepted pivot
  • listing revealed a file from outside the media root
  • writing to pivot/written-from-media.txt created outside\written-from-media.txt

The delete path uses the same flawed containment model and should be hardened at the same time.

Impact

  • Out-of-root file listing via /media/list/...
  • Out-of-root file write via /media/upload/...
  • Likely out-of-root file delete via /media/... DELETE, using the same path-validation gap
  • Bypass of the recent path traversal hardening for any deployment whose media tree contains a link to another location

This is especially relevant in development and self-hosted workflows where the media directory may contain symlinks or junctions intentionally or via repository content.

Recommended Fix

Harden media path validation with canonical filesystem checks:

  1. resolve the real base path with fs.realpath()
  2. resolve the real target path, or for writes the nearest existing parent
  3. compare canonical paths rather than lexical strings
  4. reject any operation that traverses through a symlink/junction to leave the real media root

path.resolve(...).startsWith(...) is not sufficient for filesystem security on linked paths.

Resources

  • packages/@tinacms/cli/src/next/commands/dev-command/server/media.ts
  • packages/@tinacms/cli/src/server/models/media.ts
  • packages/@tinacms/cli/src/utils/path.ts
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@tinacms/graphql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34603"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T00:23:02Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`@tinacms/cli` recently added lexical path-traversal checks to the dev media routes, but the implementation still validates only the path string and does not resolve symlink or junction targets.\n\nIf a link already exists under the media root, Tina accepts a path like `pivot/written-from-media.txt` as \"inside\" the media directory and then performs real filesystem operations through that link target. This allows out-of-root media listing and write access, and the same root cause also affects delete.\n\n## Details\n\nThe dev media handlers validate user-controlled paths with:\n\n```ts\nfunction resolveWithinBase(userPath: string, baseDir: string): string {\n  const resolvedBase = path.resolve(baseDir);\n  const resolved = path.resolve(path.join(baseDir, userPath));\n  if (resolved === resolvedBase) {\n    return resolvedBase;\n  }\n  if (resolved.startsWith(resolvedBase + path.sep)) {\n    return resolved;\n  }\n  throw new PathTraversalError(userPath);\n}\n\nfunction resolveStrictlyWithinBase(userPath: string, baseDir: string): string {\n  const resolvedBase = path.resolve(baseDir) + path.sep;\n  const resolved = path.resolve(path.join(baseDir, userPath));\n  if (!resolved.startsWith(resolvedBase)) {\n    throw new PathTraversalError(userPath);\n  }\n  return resolved;\n}\n```\n\nBut the validated path is then used directly for real filesystem access:\n\n```ts\nfilesStr = await fs.readdir(validatedPath);\n...\nawait fs.ensureDir(path.dirname(saveTo));\nfile.pipe(fs.createWriteStream(saveTo));\n...\nawait fs.remove(file);\n```\n\nThis does not account for symlinks/junctions already present below the media root. A path such as `pivot/secret.txt` can be lexically inside the media directory while the filesystem target is outside it.\n\n## Local Reproduction\n\nI verified this locally with a real junction on Windows.\n\nTest layout:\n\n- media root: `D:\\bugcrowd\\tinacms\\temp\\junction-repro4\\public\\uploads`\n- junction under media root: `public\\uploads\\pivot -\u003e D:\\bugcrowd\\tinacms\\temp\\junction-repro4\\outside`\n- file outside the media root: `outside\\secret.txt`\n\nTina\u0027s current media-path validation logic was applied and used to perform the same list/write operations the route handlers use.\n\nObserved result:\n\n```json\n{\n  \"media\": {\n    \"base\": \"D:\\\\bugcrowd\\\\tinacms\\\\temp\\\\junction-repro4\\\\public\\\\uploads\",\n    \"resolvedListPath\": \"D:\\\\bugcrowd\\\\tinacms\\\\temp\\\\junction-repro4\\\\public\\\\uploads\\\\pivot\",\n    \"listedEntries\": [\n      \"secret.txt\"\n    ],\n    \"resolvedWritePath\": \"D:\\\\bugcrowd\\\\tinacms\\\\temp\\\\junction-repro4\\\\public\\\\uploads\\\\pivot\\\\written-from-media.txt\",\n    \"outsideWriteExists\": true,\n    \"outsideWriteContents\": \"MEDIA_ESCAPE\"\n  }\n}\n```\n\nThis shows the problem clearly:\n\n- the path validator accepted `pivot`\n- listing revealed a file from outside the media root\n- writing to `pivot/written-from-media.txt` created `outside\\written-from-media.txt`\n\nThe delete path uses the same flawed containment model and should be hardened at the same time.\n\n## Impact\n\n- **Out-of-root file listing** via `/media/list/...`\n- **Out-of-root file write** via `/media/upload/...`\n- **Likely out-of-root file delete** via `/media/...` `DELETE`, using the same path-validation gap\n- **Bypass of the recent path traversal hardening** for any deployment whose media tree contains a link to another location\n\nThis is especially relevant in development and self-hosted workflows where the media directory may contain symlinks or junctions intentionally or via repository content.\n\n## Recommended Fix\n\nHarden media path validation with canonical filesystem checks:\n\n1. resolve the real base path with `fs.realpath()`\n2. resolve the real target path, or for writes the nearest existing parent\n3. compare canonical paths rather than lexical strings\n4. reject any operation that traverses through a symlink/junction to leave the real media root\n\n`path.resolve(...).startsWith(...)` is not sufficient for filesystem security on linked paths.\n\n## Resources\n\n- `packages/@tinacms/cli/src/next/commands/dev-command/server/media.ts`\n- `packages/@tinacms/cli/src/server/models/media.ts`\n- `packages/@tinacms/cli/src/utils/path.ts`",
  "id": "GHSA-g87c-r2jp-293w",
  "modified": "2026-04-01T00:23:02Z",
  "published": "2026-04-01T00:23:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tinacms/tinacms/security/advisories/GHSA-g87c-r2jp-293w"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinacms/tinacms/commit/f124eabaca10dac9a4d765c9e4135813c4830955"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tinacms/tinacms"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@tinacms/graphql\u0027s Media Endpoints Can Escape the Media Root via Symlinks or Junctions"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…