CVE-2026-72744

Executive Summary

CVE-2026-72744 is an information disclosure vulnerability in the Nuxt development server's Chrome DevTools workspace endpoint (GET /.well-known/appspecific/com.chrome.devtools.json). Affected deployments are Nuxt versions >= 4.4.7 and < 4.5.1 and >= 3.21.7 and < 3.21.10 where the dev server is bound to a network-reachable interface (e.g., nuxt dev --host) and experimental.chromeDevtoolsProjectSettings is enabled (the default). An unauthenticated attacker on the LAN can retrieve the project's absolute filesystem root path (rootDir) and a persistent per-project workspace UUID. Production builds are not affected. The flaw is remediated in Nuxt 4.5.1 and 3.21.10.

Technical Analysis

The vulnerable component is the Nuxt development server's implementation of the Chrome DevTools workspace discovery endpoint. This endpoint is part of Chrome DevTools' "workspace" feature, which lets a browser-based editor bind local filesystem paths to a project served by a local web server. Nuxt exposes this endpoint only in development mode (the nuxt dev process), not in production builds.

The core flaw is an incorrect trust boundary in the local-request gate, named in the advisory as isLocalDevRequest. Instead of validating the connected peer address (the TCP socket's remote IP), the gate relies on the attacker-supplied Host header to decide whether the request originates locally. Because HTTP Host headers are fully client-controlled, this check is trivially bypassable. An attacker who sends a request with a spoofed Host value (for example localhost or the server's own hostname) is treated as a local client.

Additionally, the gate does not require browser-specific request headers — Sec-Fetch-Site, Origin, and Referer are not present in the attacker's request, yet the endpoint still processes it. These headers are commonly used as a secondary signal to distinguish genuine browser-initiated requests from scripted or crafted ones; their absence does not block the request in the affected logic.

The practical preconditions for exploitation are:

1. The development server must be bound to a network-reachable interface, e.g., nuxt dev --host, so that it accepts connections beyond loopback.
2. The experimental.chromeDevtoolsProjectSettings option must be enabled. The NVD description states this is the default, so most dev-server configurations satisfy this condition once the server is exposed.

When those conditions are met, an unauthenticated remote attacker can request the endpoint and receive sensitive project metadata: the absolute filesystem path of the project root (rootDir) and a persistent per-project workspace UUID. The UUID remains stable across sessions for the same project, making it a reliable target identifier.

The vulnerability is classified as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). The CVSS vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N with a base score of 6.2. Note that the Attack Vector is Local (adjacent-network / same-host context), the attack complexity is Low, no privileges or user interaction are required, and the impact is strictly confidentiality (High). There is no integrity or availability impact, and the scope is unchanged. The EPSS score is 0.00135 (3.4th percentile), indicating a low current probability of exploitation in the wild, and the CVE is not listed in CISA KEV.

Patch confidence is 2/4 (claimed): the fix is reported via OSV for versions 4.5.1 and 3.21.10, but the vendor fix is otherwise marked N/A in the data and the patch has not been independently confirmed. Analysts should verify against the official Nuxt release notes before treating the fix as authoritative.

Exploitation Scenarios

No public PoC or exploit code has been identified as of this writing; the attack chain below is inferred strictly from the NVD description and the vulnerability class.

1. Reconnaissance / target identification. An attacker on the same LAN (or able to reach the host over the internet, e.g., via port forwarding) scans for Nuxt development servers. Typical indicators are listening ports associated with developer tooling (commonly 3000) and Nuxt-specific response fingerprints. A reachable server running an affected version with --host binding is a valid target.

2. Triggering the flawed gate. The attacker crafts a raw HTTP GET request to /.well-known/appspecific/com.chrome.devtools.json. The request includes a spoofed Host header designed to satisfy the isLocalDevRequest gate — for example Host: localhost — so the server classifies the request as locally originating despite the remote peer address.

3. Payload / execution method. No browser-specific headers are sent: Sec-Fetch-Site, Origin, and Referer are omitted. The request is otherwise unauthenticated. Because the header-based gate trusts the Host value rather than the connected peer address, the endpoint responds normally. No exotic payload encoding or injection is required — the entire flaw is in the authorization decision, not in memory handling or input parsing.

4. Post-exploitation impact. The response discloses the project's absolute filesystem root path (rootDir) and a persistent per-project workspace UUID. With the absolute path in hand, an attacker gains a detailed map of the host filesystem layout (OS type, installation directory, user home path, container mount points), which materially improves the reliability of follow-on attacks such as path traversal, local file inclusion, or targeted placement/reading of configuration and credential files. The persistent UUID can be used to track the same project across sessions and to correlate a target across multiple dev environments, potentially defeating per-session randomization defenses in other tooling.

Given the lack of public exploit code, this chain remains an inferred best-effort analysis; however, the request pattern is trivial to reproduce with curl or a one-line socket script.

Impact Assessment

Business impact. The vulnerability is a pure confidentiality issue with High CVSS confidentiality impact (C:H). The leaked rootDir exposes the absolute filesystem path of the Nuxt project on the developer's machine or build host. For enterprise developers using shared or remotely reachable dev environments (cloud workstations, forwarded ports, containerized dev pods), this can reveal internal infrastructure layout, host naming conventions, and project structure that are normally considered sensitive. The workspace UUID provides a stable per-project identifier useful for targeted follow-on attacks.

Affected systems. Only development-mode servers are affected. Production builds are explicitly not affected. The true at-risk population is developers who:

• Run nuxt dev --host (or equivalent) to allow access from mobile devices, VMs on other hosts, or CI environments;
• Use cloud-based IDEs or port-forwarding that exposes the dev server beyond loopback;
• Run dev servers on shared corporate networks where untrusted users can reach the port.

Blast radius. Within an affected environment, the blast radius is limited to the confidentiality of project metadata — no code execution, no data modification, no availability impact. However, the disclosed filesystem path acts as a force multiplier for subsequent attacks. On multi-tenant LANs (e.g., corporate Wi-Fi, shared office networks, conference networks), any unauthenticated user can harvest rootDir and UUIDs from exposed dev servers, and this information is not logged meaningfully by most default dev-server configurations.

CVSS context. CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — base score 6.2 (Medium). The low EPSS (0.00135, 3.4% percentile) and absence from CISA KEV suggest no active exploitation campaigns are being observed today. This is a useful "tidy-up" finding for security teams sweeping for exposed dev tooling, rather than an active zero-day under exploitation.

Detection Guidance

Detection should focus on two signals: (1) requests to the well-known DevTools workspace path from non-loopback sources, and (2) requests to that path carrying spoofed localhost-style Host headers. The detection rules below are generic templates that SOC teams should tailor to their web-server, proxy, and EDR log sources.

Sigma Rule

title: Nuxt Dev Server Chrome DevTools Workspace Endpoint Access
id: 8d1f6e73-6c1a-4d52-9d4e-f92c7ea3c2a1
status: experimental
description: Detects GET requests to the Nuxt dev-server Chrome DevTools workspace endpoint that originate from non-loopback sources, potentially indicating CVE-2026-72744 exploitation attempts.
logsource:
  category: webserver
  product: generic
detection:
  selection:
    cs-method: GET
    cs-uri-path|startswith: '/.well-known/appspecific/com.chrome.devtools.json'
  filter_loopback:
    c-ip|startswith:
      - '127.'
      - '::1'
    cs-host|startswith:
      - 'localhost'
      - '127.0.0.1'
  condition: selection and not filter_loopback
falsepositives:
  - Legitimate Chrome DevTools connections from a browser running on the same host (filtered by loopback check)
  - Reverse proxies that forward the original Host header for local development
level: medium
tags:
  - attack.t1190
  - cve.2026-72744
  - cwe.200

YARA Rule

rule nuxt_devtools_workspace_disclosure
{
    meta:
        author = "Valters IT SOC"
        description = "Detects HTTP response bodies from the Nuxt dev server Chrome DevTools workspace endpoint exposing rootDir and workspace UUID (CVE-2026-72744)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-72744"
        cve = "CVE-2026-72744"
        date = "2026-01-01"
    strings:
        $path = "/.well-known/appspecific/com.chrome.devtools.json"
        $root_dir = "rootDir"
        $workspace = "workspace"
        $uuid = /[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}/
    condition:
        $root_dir and $workspace and $uuid and #path >= 1
}

Note: when scanning PCAP-extracted HTTP responses, apply the YARA rule to reassembled response bodies; the $path string may be absent from the body itself if the response only contains JSON — in that case remove $path from the condition and match on rootDir + workspace + uuid.

Suricata IDS Rule

alert http any any -> any any (msg:"ET EXPLOIT Nuxt Dev Server Chrome DevTools Workspace Endpoint Access (CVE-2026-72744)"; flow:to_server,established; content:"GET"; http.method; content:"/.well-known/appspecific/com.chrome.devtools.json"; http.uri; nocase; http.header_names; content:!"Sec-Fetch-Site"; http.header_names; content:!"Origin"; classtype:attempted-recon; sid:202672744; rev:1; metadata:created_at 2026_01_01, updated_at 2026_01_01;)

Explanation: the rule alerts on any GET to the vulnerable workspace path where the request does not carry Sec-Fetch-Site or Origin headers — matching the exact attack pattern described in the advisory. Tune the rule to ignore trusted loopback subnets if your sensor sees host-local traffic.

Elastic Detection

any where http.request.method == "GET"
  and url.path == "/.well-known/appspecific/com.chrome.devtools.json"
  and not startsWith(source.ip, "127.")
  and not startsWith(source.ip, "::1")

Contextualization: this EQL query matches any process or network event mapping the HTTP request fields (ingested via packetbeat or an HTTP-aware agent) that targets the vulnerable endpoint from a non-loopback source. Add and userAgent.name != "Chrome" if false positives from local browsers become an issue.

Splunk SPL Query

index=* (sourcetype=access_combined OR sourcetype=iis OR sourcetype=*proxy* OR sourcetype=*http*)
  method=GET uri_path="*/.well-known/appspecific/com.chrome.devtools.json"
| eval loopback_src=if(match(clientip, "^127\.") OR clientip=="::1", "true", "false")
| eval local_host_header=if(match(http_host, "(?i)^localhost|^127\.0\.0\.1|^::1"), "true", "false")
| where loopback_src=="false"
| table _time, clientip, http_host, uri, useragent, status
| eval alert_reason=if(local_host_header=="true", "SPOOFED_HOST_HEADER + NON_LOOPBACK_SOURCE (CVE-2026-72744)", "NON_LOOPBACK_ACCESS_TO_DEVTOOLS_ENDPOINT (CVE-2026-72744)")

This identifies the two key indicators: (1) any non-loopback client hitting the endpoint, and (2) specifically non-loopback clients presenting a localhost-style Host header, which strongly suggests deliberate spoofing.

Wazuh OSSEC Rule

<group name="web,nuxt,">
  <rule id="100520" level="12">
    <decoded_as>web</decoded_as>
    <match>\.well-known/appspecific/com\.chrome\.devtools\.json</match>
    <description>Nuxt DevServer Chrome DevTools workspace endpoint accessed - potential CVE-2026-72744 information disclosure attempt</description>
    <group>cve-2026-72744,information_disclosure,cwe-200,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>

  <rule id="100521" level="14">
    <if_sid>100520</if_sid>
    <match>Host: localhost|Host: 127\.0\.0\.1</match>
    <description>Nuxt DevServer workspace endpoint accessed with spoofed local Host header from non-local source - CVE-2026-72744 exploitation likely</description>
    <group>cve-2026-72744,information_disclosure,cwe-200,</group>
  </rule>
</group>

The first rule flags any access to the vulnerable path; the second, correlated rule raises the severity when the request carries a localhost-style Host header — the exact bypass technique for isLocalDevRequest.

Mitigation & Patch Guidance

Patch confidence is 2/4 (claimed) — the fix is reported via a single source (OSV) and has not been independently confirmed by the vendor advisory channels. Treat the version upgrade as the intended remediation but validate against official Nuxt release notes and changelogs before declaring closure.

1) Immediate mitigations (no patch yet applied):

• Do not bind the Nuxt dev server to network-reachable interfaces. Run nuxt dev on loopback only; if remote access is required, use an SSH tunnel (ssh -L 3000:localhost:3000) instead of --host.
• If --host is unavoidable, place the dev server behind a firewall that restricts access to a trusted management VPN or dedicated development VLAN.
• Disable the feature if it is not needed: set experimental.chromeDevtoolsProjectSettings: false in the Nuxt configuration.
• Add a reverse-proxy or WAF rule that blocks external requests to /.well-known/appspecific/com.chrome.devtools.json from non-local sources.
• Audit your environment for running Nuxt dev servers bound to non-loopback addresses; use the Shodan dorks in the metadata to check for internet-exposed instances.

2) Patch / upgrade steps:

• Upgrade to Nuxt 4.5.1 (for users on the 4.x line with versions >= 4.4.7) or Nuxt 3.21.10 (for users on 3.x with versions >= 3.21.7).
• If the exact running version is between the affected ranges, upgrade regardless of whether the fix has been independently confirmed — the affected ranges are explicitly stated in the NVD description.
• After upgrading, verify the endpoint no longer responds to requests with spoofed Host headers, e.g., curl -H "Host: localhost" http://<host>:3000/.well-known/appspecific/com.chrome.devtools.json.
• Document the patch state in your vulnerability management system; re-check for an official vendor security advisory to upgrade patch confidence from 2/4 to 4/4.

3) Long-term hardening:

• Treat development servers as high-value internal assets: run them in isolated containers or VMs with their own network namespace, and never expose them to untrusted networks.
• Implement network-level segmentation between developer workstations and the rest of the enterprise, with the dev network firewalled from production and guest networks.
• Enforce a secure-by-default policy for developer tooling: bind services to loopback unless a signed-off business need exists, and prefer SSH/port-forwarding over --host-style exposure.
• Add monitoring rules (Sigma/Suricata/SPL above) to your detection stack so future exposure of Nuxt dev servers is caught at the network edge.
• Include CVE-2026-72744 in internal penetration-testing playbooks; the flavor of this bug — trusting client-controllable headers for authorization decisions — is a recurring pattern worth testing in other frameworks.

References

1. NVD Entry — CVE-2026-72744: https://nvd.nist.gov/vuln/detail/CVE-2026-72744
2. OSV Vulnerability Record — CVE-2026-72744 (patch source): https://osv.dev/vulnerability/CVE-2026-72744
3. Nuxt release channel (verify 4.5.1 / 3.21.10 independently): https://github.com/nuxt/nuxt/releases
4. CISA Known Exploited Vulnerabilities catalog (CVE-2026-72744 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Campaign / in-the-wild evidence: No known threat-actor campaigns or exploit-in-the-wild activity for CVE-2026-72744 have been observed at the time of writing. The EPSS score (0.00135, 3.4th percentile), absence from CISA KEV, and lack of public PoC or Nuclei coverage indicate this is a low-activity vulnerability. Organizations should nonetheless remediate exposed Nuxt dev servers, as the attack pattern is trivial to execute and requires no authentication.