VFS handler trusts X-Forwarded-For header on Unix socket deployments

[FredKSchott]

Environment

Nitro (nitropack 2.13.1), dev mode, Unix socket deployment behind reverse proxy

Reproduction

1. Start dev server on Unix socket:

NITRO_UNIX_SOCKET=/tmp/nitro.sock nuxi dev

2. Configure reverse proxy (e.g. nginx):

location / {
    proxy_pass http://unix:/tmp/nitro.sock;
}

3. Send request with spoofed header from the network:

curl -H "X-Forwarded-For: 127.0.0.1" http://dev-server.example.com/_vfs

4. VFS handler returns application source code instead of 403.

Describe the bug

createVFSHandler() restricts /_vfs access to local IPs. When the server runs on a Unix socket, it passes { xForwardedFor: isUnixSocket } to getRequestIP(), which enables trust of the X-Forwarded-For header. A client behind a reverse proxy can send X-Forwarded-For: 127.0.0.1 to satisfy the localhost check.

When the transport is a Unix socket, the peer IP isn't available from the socket layer, so trusting X-Forwarded-For as a fallback makes sense in principle — but most reverse proxy configurations forward the header from the original client, making it attacker-controlled.

Suggested fix: change getRequestIP(event, { xForwardedFor: isUnixSocket }) to getRequestIP(event, { xForwardedFor: false }), or deny /_vfs access entirely when socket-level IP info is unavailable.

Additional context

Dev mode only — VFS handler is not mounted in production builds. Requires Unix socket deployment behind a reverse proxy that passes through X-Forwarded-For.

[nyxsky404]

Fixed in #4114. The VFS handler now never trusts X-Forwarded-For (it's attacker-controlled) and denies access on Unix sockets where IP cannot be reliably determined. Tests added in test/unit/vfs-security.test.ts — all passing