TinaCMS CLI has Arbitrary File Read via Disabled Vite Filesystem Restriction

Summary

The TinaCMS CLI dev server configures Vite with server.fs.strict: false, which disables Vite's built-in filesystem access restriction. This allows any unauthenticated attacker who can reach the dev server to read arbitrary files on the host system

Details

When running tinacms dev, the CLI starts a Vite dev server configured in:
packages/@tinacms/cli/src/next/vite/index.ts

server: {
  host: configManager.config?.build?.host ?? false,
  ...
  fs: {
    strict: false, // Disables Vite's filesystem access restriction
  },
},

TinaCMS middleware only intercepts specific route prefixes (/media/*, /graphql, /altair, /searchIndex). Any request to a path outside these routes falls through to Vite's default static file handler, which will serve the file directly from the absolute path on the filesystem.
Additionally, the server enables permissive CORS (cors() with no origin restriction), which may further facilitate browser-based exploitation such as DNS rebinding attacks.

PoC

Prerequisites: TinaCMS CLI dev server running (default port 4001).

• Read system files directly:

curl http://localhost:4001/etc/passwd

curl http://localhost:4001/etc/hostname

Vite resolves and serves the absolute path directly from the filesystem.

Impact

Any developer running tinacms dev in an environment where the dev server port is reachable by an attacker. This includes:

• Cloud IDEs (GitHub Codespaces, Gitpod) where ports are automatically forwarded and publicly accessible

• Docker or VM setups with port forwarding configured

• Misconfigured environments binding to 0.0.0.0 via the build.host config option

• Systems targeted via DNS rebinding attacks, leveraging the unrestricted CORS policy

• Local environments with malicious dependencies running on the same machine

An attacker who can reach port 4001 can:

• Read any file readable by the server process (/etc/passwd, /etc/shadow, SSH private keys)

• Exfiltrate environment variables and secrets via /proc/self/environ

• Access cloud credentials and API keys from configuration files