Update CVE-2025-55182.yaml

[fatguru]

This PR introduces three critical improvements to reduce False Negatives:

Redirect Bypass: Changed the HTTP target from / to /{{random-path}}.

Why: Next.js root paths often return 307/308 redirects (e.g., to /login), causing Nuclei to lose the POST body or convert it to GET. Hitting a random path forces the App Router (404 handler) to process the RSC payload directly.

Hardened Target Detection: Removed internal: true from the HTTP matcher and added Minified React error check.

Why: Many production environments strip the window.next.version object from the client-side code (Hardened). The previous template would fail silently on these targets even if the server was vulnerable. Now, if the HTTP step confirms the unique React 19 RSC "Digest" error, it will report the vulnerability immediately, even if the Headless step cannot find the version string.

Expanded Matchers: Added Minified React error as a fallback for the JSON digest response, covering different Next.js error reporting configurations.

PR Information

• Fixed CVE-2020-XXX / Added CVE-2020-XXX / Updated CVE-2020-XXX
• References:

Template validation

• [ ] Validated with a host running a vulnerable version and/or configuration (True Positive)
• [ ] Validated with a host running a patched version and/or configuration (avoid False Positive)

Additional Details (leave it blank if not applicable)

Additional References:

• Nuclei Template Creation Guideline
• Nuclei Template Matcher Guideline
• Nuclei Template Contribution Guideline
• PD-Community Discord server

[Sebbito]

yaml: unmarshal errors:\n line 70: field headless not found in type http.Request\n line 95: field matchers already set in type http.Request"

[DhiyaneshGeek]

Hi @fatguru

Thanks for sharing the template , we have already added full working POC https://github.com/projectdiscovery/nuclei-templates/blob/main/http/cves/2025/CVE-2025-55182.yaml

Due to the following reason we are closing this PR

[hlein]

@fatguru from reading your explanation and the version of CVE-2025-55182.yaml that got merged, does it still have the same problems? At the least, the reason for the /{{random-path}} change (use the 404 handler's behavior). It looks like it checks for login?a= in the response, but is that sufficient?

[fatguru]

Yes, relying on login?a= is risky because it detects a redirect symptom, not the RSC protocol.

Hitting root (/) often triggers middleware.ts redirects (307/308). This usually drops the POST body before the server processes it. The payload never reaches the RSC parser, causing False Negatives.

In Next.js App Router, the 404 Handler IS a Server Component. By hitting a random path (/{{random}}), we force the server to parse the RSC headers/body in-place to render the 'Not Found' UI. This bypasses middleware redirects and ensures the vulnerability sink is actually triggered.

[hlein]

Thanks! OK, @DhiyaneshGeek do you think that changes things? Want @fatguru to redo their changes against the current merged CVE-2025-55182.yaml ? Note I also see another issue about this template, #14255 (it's tagged as "false-positive" but I think that's an error, the report is about a false-negative). I suspect the /{{random-path}} change might improve that case too?

...Buuuut also, @fatguru could changing to /{{random-path}} also introduce a new problem? What is the likelihood that a deployment is frontended by a LB or WAF that knows "Only / and /_next/ and /foo/... are valid toplevel paths to forward to the real server"? In that case testing only for a random-path is likely to fail. (I don't know if that'd be 0% or 2% or 20% of Next.js servers out there.)

[fatguru]

Indeed, That's a valid concern regarding strict LBs/WAFs. To mitigate this, my proposed update implements a hybrid approach probing both paths (already implemented like this in my repo):

path:

• "{{BaseURL}}" # 1. Catches strict routing/allow-listed paths
• "{{BaseURL}}/{{rand_base(6)}}" # 2. Bypasses root redirects (forces 404 RSC handler)

This ensures coverage for strict environments while resolving the redirect-induced False Negatives (which is likely the root cause of #14255, as the 404 handler processes RSC without redirecting).

Cheers!