Server-side route matching accepts malformed URLs (infinite trailing slashes/backslashes)

[maxxlwr]

Reproduction

https://stackblitz.com/edit/github-1gpbxtzp?file=app%2Froutes%2Fhome.tsx

Open the Preview in a new tab, open the Network tab, and use the provided buttons to send requests with trailing slash variations. You will see the server responds with 200 OK for all variations.

In real life, these buttons won't exist; the issue can be abused via terminal/Postman or similar tools.

System Info

System:
    OS: macOS 26.2
    CPU: (8) arm64 Apple M1 Pro
    Memory: 109.20 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.15.0 - /usr/local/bin/node
    Yarn: 1.22.22 - /usr/local/bin/yarn
    npm: 10.9.2 - /usr/local/bin/npm
    pnpm: 10.18.3 - /usr/local/bin/pnpm
  Browsers:
    Chrome: 145.0.7632.46
    Safari: 26.2
  npmPackages:
    @react-router/dev: 7.12.0 => 7.12.0 
    @react-router/node: 7.12.0 => 7.12.0 
    @react-router/serve: 7.12.0 => 7.12.0 
    react-router: 7.12.0 => 7.12.0 
    vite: ^7.1.7 => 7.3.1

Used Package Manager

npm

Expected Behavior

When a request is made to the server with a malformed URL structure, the router should strictly validate the path. Malformed URL examples:

• /submit//////.data
• /submit\\\\\.data
• /submit//////
• /submit\\\\\

Ideally, it should either:

• Return a 404: Treat path/ and path//// as distinct, unmatched routes.
• Strictly Normalize (308 Redirect): Detect the malformed trailing characters and redirect to the canonical route (e.g., redirect /path////// -> /path).

The router should not match a route definition against a string containing non-standard repetitions of path separators.

Actual Behavior

The server-side router matches routes even when the URL contains an arbitrary number of trailing forward slashes or backslashes.

For example, if a route is defined as /signin:

• Request to /path -> Matches (Correct)
• Request to /path/ -> Matches (Correct/Tolerable)
• Request to /path/////// -> Matches (Unexpected)
• Request to /path\\\\\\ -> Matches (Unexpected)
• Request to /path////.data -> Matches (Unexpected)

While the client-side router constructs URLs correctly, this server-side permissiveness creates a discrepancy between the router's behavior and standard proxy/WAF path matching rules.

[Axadali]

Hi @maxxlwr,

Thanks for reporting this and for providing a clear reproduction along with detailed system information.

I’m going to start working on this issue. I’ll first reproduce the behavior on my side and review how the server-side router is handling malformed or non-standard trailing separators to understand why these routes are still being matched.

If I need any clarification regarding the expected behavior or intended routing constraints, I’ll follow up here.