Security hardening: Next.js patch release, MCP SDK advisories, pre-auth body size, CSP, readonly gaps #3491

Found while reviewing a self-hosted @hyperdx/app@2.42.0 deployment. None of these depend on our local changes.

1. Latest release ships Next.js 16.3.8

2.42.0 pins next@16.3.8, which is inside the range of the Next.js 16.4.1 security release (>=16.0.0 <=16.4.0). main already has the bump (#3460). Could that go out in a patch release? Self-hosters on the latest tag are exposed until then.

2. @modelcontextprotocol/sdk 1.29.0 has open advisories

Both 2.42.0 and main resolve 1.29.0. yarn npm audit reports advisories fixed in 1.30.1–1.32.0, including missing request-body and JSON-RPC batch limits on the HTTP transport and memory exhaustion during validation. /mcp is internet-facing in many deployments.

3. Request bodies up to 32 MB are parsed before authentication

api-app.ts mounts express.json, express.text and express.urlencoded with limit: '32mb' globally, ahead of every auth check and rate limiter. Any unauthenticated client can make the API parse 32 MB bodies on any route. A small default limit, with the large limit only on the routes that need it (e.g. the ClickHouse proxy), would close this.

4. No Content-Security-Policy or related headers

next.config.mjs sets only X-Frame-Options: DENY. There is no CSP, X-Content-Type-Options: nosniff, Referrer-Policy or HSTS, and the API sets none either. I found no current XSS sink, so this is defence in depth.

5. Some server-side user-SQL paths do not force readonly=2

The MCP SQL tool and dashboard SQL tiles force readonly=2, but external API v2 search / charts (routers/external-api/v2/utils/search.ts) and builder-config alerts run a user-supplied whereLanguage: 'sql' condition without it. They are always a single SELECT, so I found no escalation, but passing clickhouse_settings: { readonly: '2' } there would make the guarantee uniform.