One line in a request could make a vulnerable application believe that its security check had already happened. It had not.
That is what made CVE-2025-29927 dangerous. A specially prepared request could cause certain Next.js applications to skip middleware used for access control. If that middleware was the only check protecting a page or API, an attacker could get past it.
We saw repeated attempts against internet-facing applications protected by SiteWALL. Every malicious request observed in this campaign was blocked before reaching the applications.
Customer names, attack volumes and sensitive details remain private. The pattern matters more than the numbers.
Attackers moved quickly. SiteWALL stopped the malicious requests while application teams reviewed and fixed the underlying software.
That is the value of protection at the edge. It acts immediately, even when the permanent software fix takes time.
What is CVE-2025-29927?
CVE-2025-29927 is a critical weakness in certain versions of Next.js, a widely used framework for building web applications and APIs.
Next.js applications can use middleware to inspect a request before it reaches a page or API. Teams often use it to check login status, user roles and access to administrative pages or API routes.
The vulnerable versions trusted an internal signal used by Next.js itself. An attacker could include that signal in an external request and make the application behave as if the middleware had already run.
The application could then skip the middleware. If that middleware was the only access check, a protected page or API could be reached without the expected permission.
The official Next.js advisory rated the vulnerability Critical, with a CVSS score of 9.1 out of 10. It could be attempted remotely, without a valid account and without any action from the victim.
Self-hosted applications using affected versions faced the primary risk. Applications hosted on Vercel, Netlify and Cloudflare Workers were not affected.
Why should a business leader care?
This is not only a developer or IT problem. It is a business problem.
Web applications and APIs now handle customer information, payments, partner access, internal processes and administrative functions. When a check protecting one of these is bypassed, a technical weakness can quickly become a business incident.
Depending on the application, an attacker could potentially view protected information, reach an administrative page, use an API without permission, change business records or cross from one customer account to another.
We should also be accurate about the risk. This vulnerability did not automatically give an attacker control of the server. The impact depended on what the skipped middleware protected and whether the application checked the user’s permission again at the final page or API.
The greatest risk existed where middleware alone controlled access. If that middleware was bypassed, the protected page or API could be exposed.
What did SiteWALL observe?
The traffic did not behave like normal visitors. It behaved like automation.
What SiteWALL observed and blocked, including sensitive routes, cloud-hosted sources, changing crawler identities and automated repetition.
The requests went directly to login pages, administrative panels, dashboards, consoles and account routes. They repeated in a mechanical pattern, like a script working through a list.
The busiest source Ips sat in Google Cloud address ranges rather than ordinary residential networks. The leading source countries also matched major cloud-hosting locations.
Geography reflected where the traffic was hosted or routed, not necessarily where the attacker was located.
The requests used different user-agent identities, including browsers, search engines and AI crawlers. Several claimed crawler identities appeared at unusually similar volumes. This suggested automated user-agent rotation or crawler impersonation rather than normal independent crawler activity.
These signals were useful, but none was proof on its own. Anyone can change a user-agent string, and an IP address identifies infrastructure rather than the person operating it.
SiteWALL evaluated the complete request behaviour. This included the targeted route, supplied headers, repetition rate, source reputation and whether the request matched a known attack pattern.
The malicious requests were blocked at the edge before they reached the protected applications.
For our customers, the objective is clear. Stop the attack before it can exploit the vulnerability and compromise the application.
Patching is essential, but it is not always immediate
The permanent fix for CVE-2025-29927 is to upgrade Next.js to a safe, supported version. Every affected organisation should do this as soon as possible. But patching a production application takes time.
Teams must identify affected applications, test the update, check dependencies and schedule deployment. Older applications may belong to another team, an external partner or be missing from the current asset inventory. Attackers do not wait for this process to finish.
This creates a gap between disclosure and the permanent fix. SiteWALL can close that gap by blocking the known attack pattern while teams update the application.
This is virtual patching. It does not replace the software update.
The two actions have different purposes.
- The software update removes the weakness.
- SiteWALL blocks known exploit attempts while application teams complete the update.
The bigger lesson is to stop attacks before they reach the application
The most important lesson is not about one framework or one header. It is about preventing a known attack from reaching vulnerable software.
SiteWALL examines incoming requests at the edge and blocks known malicious behaviour before it reaches the application. Monitoring gives security teams clear visibility into what was attempted and stopped.
Access checks inside the application have a different responsibility. They confirm who the user is, what the user is allowed to do and whether the requested information belongs to that user.
SiteWALL stops the attack at the edge. The application controls access to sensitive information and actions.
SiteWALL blocks the malicious request at the edge while application access controls protect sensitive data and actions.
SiteWALL blocks known malicious behaviour at the edge, before it reaches the application. Strong access checks within the application safeguard every sensitive action.
The result is protection at the edge and control at the point of action.
What should application owners do now?
1. Find every internet-facing Next.js application
Include websites, APIs, customer and partner portals, older applications and third-party systems.
2. Check the Next.js version
Identify affected versions and upgrade to the appropriate fix or a currently supported release.
3. Review what the middleware protects
Find pages and APIs that rely on middleware. Make sure each resource independently confirms permission before performing a sensitive action.
4. Block the attack at the edge
Block untrusted internet requests that carry the internal signal abused by this vulnerability. Record and alert on every attempt.
5. Review the logs
Review administrative, login, dashboard, console and API requests. Investigate any request that succeeded where it should have been denied.
6. Test without the middleware
Do not test only whether middleware blocks a malicious request. Test whether the application remains secure when the middleware does not run.
These steps address both sides of the risk. SiteWALL stops known attacks before they reach the application, while the application controls access to sensitive actions and information.
Security must move at the speed of the attack
CVE-2025-29927 shows how quickly a weakness in a trusted framework can turn into an internet-wide search for vulnerable applications.
Patching matters. Secure coding matters. Neither removes the need for protection in front of the application.
SiteWALL blocked every malicious attempt observed in this campaign, giving application teams time and visibility to fix the underlying software.
That is the role of SiteWALL. It provides immediate protection at the edge while application teams complete the permanent software fix.
The aim is simple. Stop known attacks before they reach vulnerable software and give application teams the time and visibility to remove the weakness.
Is your application protected beyond the framework?
If you operate internet-facing web applications or APIs, SiteWALL can identify the routes an attacker would probe first, apply virtual protection at the edge and keep that protection in place while your team deploys the permanent fix.
A SiteWALL Security Review for web applications and APIs shows where attackers are likely to probe, whether edge protection is ready to stop known attack patterns and where application access controls need attention.
Stop attacks at the edge. Keep sensitive actions under application control.
Review your applications and APIs before an attacker finds the gaps.
Request a SiteWALL Security Review
See how SiteWALL protects web applications and APIs
References
Next.js Security Advisory: Authorization Bypass in Next.js Middleware
