CVE-2026-28792: Cross-Origin File Exfiltration and Path Traversal in TinaCMS CLI

The TinaCMS CLI provisions a local development server, typically bound to port 4001, to serve the content management interface and proxy backend requests. This server operates directly on the developer's host machine, inheriting the execution privileges of the current user. The application architecture relies on this local server to rapidly serve media and interface with the underlying filesystem during active development.

CVE-2026-28792 represents a composite exploitation sequence relying on a permissive Cross-Origin Resource Sharing (CORS) policy (CWE-942) paired with filesystem path traversal weaknesses (CWE-22). The vulnerability chain specifically targets developers actively using the framework. The combination of these configuration flaws exposes the developer's local filesystem to any external origin executing code within the developer's browser session.

An attacker executes this vector by luring a targeted developer to a malicious webpage while the local server is active. The malicious page initiates asynchronous HTTP requests to read, write, or delete arbitrary files on the local disk. The resulting impact includes local credential theft, source code exfiltration, and potential local command execution via configuration file modification.

The vulnerability stems from an insecure default CORS configuration applied to the local Express server. The TinaCMS local development server instantiated the Express cors() middleware without providing strict configuration arguments. This specific omission caused the server to append the Access-Control-Allow-Origin: * header to all outgoing HTTP responses. Browsers receiving this header bypass the Same-Origin Policy (SOP), allowing cross-origin scripts to read the response payload of requests made to the local interface.

The impact of the CORS misconfiguration is amplified by severe Vite filesystem exposure, tracked under GitHub Security Advisory GHSA-m48g-4wr2-j2h6. The development server explicitly disabled Vite's built-in directory restriction by setting the configuration parameter server.fs.strict: false. This configuration instructed the underlying Vite server to serve files located completely outside the project workspace. Attackers leverage the specific @fs URL prefix routing to traverse the entire host filesystem without restriction.

Furthermore, the server exposed specific media handling endpoints, such as /media/upload, to facilitate file management during CMS operations. These endpoints failed to validate or sanitize the src input parameter against standard directory traversal sequences. This implementation failure granted unauthenticated attackers the technical ability to write and delete files arbitrarily outside the intended media storage directory, leading to integrity and availability impacts.

The original server configuration applied the global CORS middleware universally to the routing layer. The lack of an origin whitelist allowed arbitrary external domains to interact with the local server APIs. Simultaneously, the Vite configuration block explicitly instructed the framework to disable strict file serving constraints.

The patch implemented in commit 56d533e610a520ba66b3e58f3a0dc03487d5d5d7 replaces the wildcard policy with an explicit array of allowed local origins. The diff demonstrates the shift from implicit trust to explicit definition for both CORS and the Vite filesystem boundaries.

// Vulnerable Configuration
app.use(cors());
// Vulnerable Vite config
server: {
  fs: { strict: false }
}
 
// Patched Configuration
const allowedOrigins = ['http://localhost', 'http://127.0.0.1', 'http://[::1]'];
app.use(cors({
  origin: function (origin, callback) {
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  }
}));
// Patched Vite config
server: {
  fs: {
    strict: true,
    allow: ['..'] // Restricted strictly to project root
  }
}

The patch includes secondary network constraints to limit the attack surface further. The maintainers bound the internal LevelDB TCP server specifically to the 127.0.0.1 interface instead of the 0.0.0.0 wildcard, preventing direct external network connections. A new configuration parameter, server.allowedOrigins, allows developers to safely define trusted origins for remote development environments like GitHub Codespaces without reverting to a globally permissive policy.

The exploit execution relies on strict prerequisites regarding the victim's state. The target must be running the TinaCMS development server, typically instantiated via the npx tinacms dev command, on their local workstation. The attacker must successfully convince the target to navigate to an attacker-controlled website using a modern web browser running on the same host.

The exploitation sequence begins when the attacker's webpage executes a background JavaScript fetch() request targeting http://localhost:4001/@fs/ concatenated with an absolute system file path. The browser transmits the request to the local server, which processes the path traversal and returns the file contents. Due to the permissive configuration, the server attaches the Access-Control-Allow-Origin: * header to this response.

Upon receiving the file contents and the permissive header, the browser processes the response and permits the malicious script to read the response body, successfully bypassing the Same-Origin Policy. The malicious script then encodes the sensitive data and initiates a secondary HTTP request to transmit the payload to the attacker's command and control infrastructure.

This vulnerability exposes the developer's entire accessible filesystem to the attacker. The severity relies directly on the operating system privileges of the user executing the tinacms dev command. Because development tools are typically run within the user's primary context, the attacker gains full read and write access to personal directories, configuration files, and system registries available to that user profile.

Attackers prioritize high-value targets during local exfiltration campaigns. Primary targets include SSH private keys, AWS credentials stored in ~/.aws/credentials, environment variables containing API tokens, and browser session databases. Successful exfiltration of these assets provides the adversary with the necessary credentials to pivot into the organization's cloud infrastructure or source code repositories.

The media endpoint traversal component introduces significant integrity and availability impacts by permitting arbitrary file creation and deletion. Attackers leverage this capability to establish permanent local persistence. Typical persistence mechanisms include writing malicious executable code to user shell configuration files, altering .bashrc or .zshrc, or directly injecting backdoors into the project source code prior to a developer commit.

The assigned CVSS v3.1 score is 9.7, correctly indicating a critical severity level. The CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H vector highlights the high impacts to confidentiality, integrity, and availability. The vector also reflects the requirement for user interaction and the transition across changed trust scopes, moving from an external browser context directly to local host execution.

Organizations must upgrade the @tinacms/cli dependency to version 2.1.8 or later across all active projects. This specific release permanently enforces strict CORS rules bounded to local loopback addresses and restricts Vite filesystem access entirely to the project directory boundaries. The upgrade mitigates both the exfiltration vector and the local file manipulation capabilities.

Developers must verify their local development environments by checking the installed CLI version via native Node package managers. Security teams should proactively audit package-lock.json or yarn.lock files across organizational repositories to ensure no vulnerable dependencies remain in active or legacy projects. CI/CD pipelines should be configured to fail builds if vulnerable versions of the @tinacms/cli package are detected.

For teams utilizing cloud-based or containerized development environments, the upgrade introduces the explicit server.allowedOrigins configuration key. Administrators must configure this array with specific, trusted domain names representing the remote development workspaces rather than reverting to wildcard policies.

If exploitation is suspected or verified, incident responders must immediately rotate all local credentials present on the affected developer's workstation. This mandatory remediation includes regenerating SSH keypairs, invalidating cloud provider access tokens, and rotating any application secrets previously stored in local .env configuration files.