Link to the code that reproduces this issue

https://my.spendwise.se/nis/mypages/login/en-SE/

To Reproduce

1. Create a new Next.js app with 16.2.x (Turbopack default)
2. Run next build
3. Inspect .next/static/chunks/ — filenames contain ~ characters
4. Deploy behind any WAF that flags ~ in URL paths
5. App fails to load — WAF returns 400 with text/html instead of JS. We are talking about a bank with tought security controls.

Current vs. Expected behavior

Turbopack (16.2.x) generates chunk filenames containing ~ (tilde) characters,
e.g. _next/static/chunks/0259pyb~8-2~v.js.

Expected: Chunk filenames use only URL/WAF-safe characters (alphanumeric, -, _, .)
Actual: Chunk filenames contain ~ which is flagged by enterprise WAF rules,
causing a 400 response with text/html instead of application/javascript.
The browser refuses to execute the file and the app breaks entirely.

Previous behavior in 16.1.x (hex hashes) was WAF-compatible:
d0b8996cb3d22274.js
96c0a41d0f0dc35b.js

New behavior in 16.2.x (tilde format) is blocked:
0259pyb8-2v.js
09072fu20v1.js

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Enterprise
  Available memory (MB): 64957
  Available CPU cores: 14
Binaries:
  Node: 24.14.0
  npm: 11.9.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 16.1.5
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 5.4.5
Next.js Config:
  output: standalone

Deployment: OpenShift (self-hosted), behind enterprise WAF
Issue reproduced on: 16.2.x (not present in 16.1.5)

Which area(s) are affected? (Select all that apply)

Turbopack

Which stage(s) are affected? (Select all that apply)

Other (Deployed)

Additional context

Deploying via OpenShift (self-hosted Kubernetes) using output: "standalone".
The app runs behind an enterprise WAF that flags ~ (tilde) in URL paths due to
rules targeting:

• IIS short filename enumeration attacks (e.g. /something~1/)
• Unix home directory traversal (e.g. /~username/)

The WAF returns a 400 response with text/html for any request to
/_next/static/chunks/*.js filenames containing ~. The browser then refuses
to execute the file due to MIME type mismatch, breaking the app entirely.

This is not reproducible on Vercel (no WAF layer), which likely explains
why this hasn't been widely reported despite affecting any self-hosted
enterprise deployment behind standard WAF rulesets.

The issue is not present in 16.1.x where Turbopack used hex-only chunk
filenames. The ~ character appears to have been introduced as part of
Turbopack's compressed chunk naming format in 16.2.x.

Workaround: next build --webpack avoids the issue but opts out of
Turbopack performance gains.

Requested: a Turbopack config option to restrict chunk filename characters
to WAF-safe alphanumerics (similar to webpack's output.chunkFilename).