---
id: GHSA-rq7w-g337-39qq
title: >-
  Nuxt: Dev server discloses project absolute path and persistent workspace UUID
  via `/.well-known/appspecific/com.chrome.devtools.json`
summary: >-
  Nuxt: Dev server discloses project absolute path and persistent workspace UUID
  via `/.well-known/appspecific/com.chrome.devtools.json`
severity: low
cwe:
  - CWE-200
vendor: nuxt
product: nuxt
ecosystem: npm
affected:
  - 'nuxt >= 4.0.0-alpha.1, < 4.4.7'
patched:
  - nuxt 4.4.7
published: '2026-06-15'
updated: '2026-06-15'
source: GHSA
sourceUrl: 'https://github.com/advisories/GHSA-rq7w-g337-39qq'
references:
  - url: 'https://github.com/nuxt/nuxt/security/advisories/GHSA-rq7w-g337-39qq'
  - url: 'https://github.com/nuxt/nuxt/pull/35201'
  - url: >-
      https://github.com/nuxt/nuxt/commit/55c75b78c989b8bd210837b0e5faaebbf2b87b15
  - url: 'https://github.com/advisories/GHSA-rq7w-g337-39qq'
tags:
  - ghsa
  - npm
ingestedAt: '2026-07-07T15:41:58.397Z'
---

## Overview

### Summary

When running `nuxt dev`, Nuxt registers an unauthenticated route at `/.well-known/appspecific/com.chrome.devtools.json` that returns the absolute filesystem path of the project root and a per-project UUID persisted to `node_modules/.cache/nuxt/chrome-workspace.json`. The route is enabled by default via `experimental.chromeDevtoolsProjectSettings: true`.

The endpoint exists to let Chrome DevTools' Workspace integration map sources to the developer's local checkout. The handler is registered directly on `nitro.options.devHandlers` and does not pass through the CORS / origin wrapper that the rest of the dev pipeline uses, so it has no host / origin / `Sec-Fetch-Site` check of its own.

### Impact

Dev-server only. Production builds do not register the route.

Two values are disclosed:

- `workspace.root`: the absolute filesystem path of the project (commonly reveals the OS username and the on-disk project name).
- `workspace.uuid`: a v4 UUID persisted to `node_modules/.cache/nuxt/chrome-workspace.json`, stable across dev-server restarts and re-clones.

### Threat model

The response carries no `Access-Control-Allow-Origin` header. A cross-origin `fetch()` from an arbitrary malicious page is therefore blocked by the browser's same-origin policy and cannot read the body. The two realistic recovery paths are:

1. **LAN-adjacent attacker** when the developer runs `nuxt dev --host` (or otherwise binds to a non-loopback interface). A plain `curl http://<dev-lan-ip>:3000/.well-known/appspecific/com.chrome.devtools.json` returns the JSON; no browser, no CORS.
2. **DNS rebinding** against the default loopback dev server. A page the developer visits resolves to the attacker, then re-resolves to `127.0.0.1` after the TTL; the browser believes the request is same-origin and reads the response.

### Affected versions

`nuxt@4.0.0-alpha.1` (PR #32084) through `nuxt@4.4.6`. `3.x` is not affected.

### Reproduction

```bash
npx nuxt dev
curl -s http://localhost:3000/.well-known/appspecific/com.chrome.devtools.json
# {"workspace":{"uuid":"...","root":"/Users/<name>/..."}}
```

### Workaround

Set `experimental: { chromeDevtoolsProjectSettings: false }` in `nuxt.config.ts`. Chrome DevTools' Workspace auto-integration will stop working; the dev server is otherwise unaffected.

### Patches

Fixed in `nuxt@4.4.7` by [#35201](https://github.com/nuxt/nuxt/pull/35201) (commit [`55c75b78`](https://github.com/nuxt/nuxt/commit/55c75b78c989b8bd210837b0e5faaebbf2b87b15)). The handler is now routed through the same host / origin gate the rest of the dev server uses, so the endpoint only responds to requests that look local.

## Affected packages

- `nuxt >= 4.0.0-alpha.1, < 4.4.7`

## Remediation

Upgrade to a patched release:

- `nuxt 4.4.7`