## 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:

```ts
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:

```ts
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:

```json
{
"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`

CWE-22 Path Traversal

CWE-59 Link Following