For agencies running 10–40 client Next.js apps
A new advisory flags every client. Which ones are actually affected?
Version scanners flag every app on an affected version. Pich reads the advisory with SERV Reasoning, then checks each client app for the advisory's exact conditions and shows you the lines of code behind every verdict.
How Pich works
From advisory to evidence in four steps
- 1
Advisory
Pick a supported Next.js advisory or paste the text of a new one.
- 2
SERV-compiled checklist
SERV Reasoning reads the advisory and lists the exact versions and conditions that make an app affected, each with a word-for-word quote.
- 3
Deterministic checks
Pich throws out any condition whose quote is not in the advisory, then checks each client app's files. No AI decides the verdict.
- 4
Evidence-backed verdict
Each app gets one of three verdicts with file-and-line evidence, the unknowns, and a plain-English note for the client.
Product
Try Pich
Pick an advisory, then check it against 8 demo client apps or against your own public GitHub repository.
1Pick an advisory
Read the advisory text SERV will receive
GHSA-f82v-jwr5-mffw / CVE-2025-29927 Authorization Bypass in Next.js Middleware Affected versions: - next >= 13.0.0, < 13.5.9 (patched in 13.5.9) - next >= 14.0.0, < 14.2.25 (patched in 14.2.25) - next >= 15.0.0, < 15.2.3 (patched in 15.2.3) - next >= 12.0.0, < 12.3.5 (patched in 12.3.5) # Impact It is possible to bypass authorization checks within a Next.js application, if the authorization check occurs in middleware. # Patches * For Next.js 15.x, this issue is fixed in `15.2.3` * For Next.js 14.x, this issue is fixed in `14.2.25` * For Next.js 13.x, this issue is fixed in 13.5.9 * For Next.js 12.x, this issue is fixed in 12.3.5 * For Next.js 11.x, consult the below workaround. _Note: Next.js deployments hosted on Vercel are automatically protected against this vulnerability._ # Workaround If patching to a safe version is infeasible, we recommend that you prevent external user requests which contain the `x-middleware-subrequest` header from reaching your Next.js application. ## Credits - Allam Rachid (zhero;) - Allam Yasser (inzo_) Source: https://github.com/advisories/GHSA-f82v-jwr5-mffw (GitHub Advisory Database, CC-BY-4.0)
2Choose which apps to check
Three verdicts
Every app gets exactly one, with evidence
- Confirmed
The advisory's conditions were found in this app's code and config. This is not proof an attack happened.
- Absent within inspected scope
At least one required condition was not found in the files Pich inspected. This is not a safety guarantee.
- Needs manual review
Pich could not decide from the files alone. A person needs to check the listed unknowns.
Pich never calls an app “safe”. Its verdicts only describe the files it inspected.
Product proof
The conditions matter: a controlled before/after run
Static checks say where an advisory's conditions exist. To show those conditions are real, we built and ran two of the bundled apps locally with the real Next.js releases, then sent the CVE-2025-29927 bypass header to their protected /admin page.
| Demo client app | next version | Normal request | With bypass header |
|---|---|---|---|
| Acme Dental (affected) | 14.2.24 | 307 redirect to login | 200 admin page served |
| Brightline Legal (fixed) | 14.2.25 | 307 redirect to login | 307 redirect to login |
Header sent: x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware. Run on 2026-09-27 with proof/run-proof.mjs. This runtime proof exists only for CVE-2025-29927; the second advisory is checked statically.
FAQ