For those of you that don’t use NextJS, these middleware are usually used for checking the presence of auth tokens to determine if a redirect is necessary. They don’t usually gate access to data,...
For those of you that don’t use NextJS, these middleware are usually used for checking the presence of auth tokens to determine if a redirect is necessary. They don’t usually gate access to data, just access to the page structure. So for most apps this won’t be a critical issue.
See, this is why I don't understand the severity rating of CVEs. This one is rated "Critical 9.1/10", but it "only" grants access to the page structure, which is... relatively tame for something...
See, this is why I don't understand the severity rating of CVEs. This one is rated "Critical 9.1/10", but it "only" grants access to the page structure, which is... relatively tame for something rated "9"?
As far as I understand it really depends how someone used middleware in their code. It's usually probably not going to be as bad, but in some cases it might (for example, I once came across a site...
As far as I understand it really depends how someone used middleware in their code. It's usually probably not going to be as bad, but in some cases it might (for example, I once came across a site that returned all API auth data in a json stored in a <script> tag in page's body; that said I don't know if it used nextjs). It's probably hard to determine a rating because of that, so they went for the higher one to make it harder to miss for someone who might be affected more badly.
You could also fetch protected data in a middleware. But I've seen people on HN talk about how 10s of thousands of sites are vulnerable right now. I wanted to clarify most of them are vulnerable...
You could also fetch protected data in a middleware. But I've seen people on HN talk about how 10s of thousands of sites are vulnerable right now. I wanted to clarify most of them are vulnerable to a relatively inconsequential exploit.
The two ways I see this being bad are if:
You have one auth middleware which gets skipped and then a data fetching middleware which doesn't check auth itself.
You have a skipped auth middleware and then the page itself fetches data without checking auth.
I wouldn't be surprised to learn there are a ton of vulnerable pages just because they don't strictly need auth for the page to function and so have no auth-related code in the page at all....
I wouldn't be surprised to learn there are a ton of vulnerable pages just because they don't strictly need auth for the page to function and so have no auth-related code in the page at all. Basically the case where they're just depending on the middleware as the only guard against access.
Is it a good pattern? Not at all. Even for read only stuff like dashboards it's a good idea to at least be able to keep an access log. Is it happening a lot anyway just because it's easy? Based on the quality of code I've seen in the wild, probably more than we'd hope.
Relevant bits for anyone who uses next.js, it has been patched:
Relevant bits for anyone who uses next.js, it has been patched:
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 versions 11.1.4 thru 13.5.6 we recommend consulting the below workaround.
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.
That's quite an impressive response time all things considered.
The vulnerability took a few days to be addressed by the Vercel team, but it should be noted that once they became aware of it, a fix was committed, merged, and implemented in a new release within a few hours (including backports).
That's quite an impressive response time all things considered.
For those of you that don’t use NextJS, these middleware are usually used for checking the presence of auth tokens to determine if a redirect is necessary. They don’t usually gate access to data, just access to the page structure. So for most apps this won’t be a critical issue.
See, this is why I don't understand the severity rating of CVEs. This one is rated "Critical 9.1/10", but it "only" grants access to the page structure, which is... relatively tame for something rated "9"?
As far as I understand it really depends how someone used middleware in their code. It's usually probably not going to be as bad, but in some cases it might (for example, I once came across a site that returned all API auth data in a json stored in a
<script>tag in page's body; that said I don't know if it used nextjs). It's probably hard to determine a rating because of that, so they went for the higher one to make it harder to miss for someone who might be affected more badly.I guess. If the middleware works as intended, you can theoretically use it to protect sensitive values inside your frontend app, but... ugh.
You could also fetch protected data in a middleware. But I've seen people on HN talk about how 10s of thousands of sites are vulnerable right now. I wanted to clarify most of them are vulnerable to a relatively inconsequential exploit.
The two ways I see this being bad are if:
I wouldn't be surprised to learn there are a ton of vulnerable pages just because they don't strictly need auth for the page to function and so have no auth-related code in the page at all. Basically the case where they're just depending on the middleware as the only guard against access.
Is it a good pattern? Not at all. Even for read only stuff like dashboards it's a good idea to at least be able to keep an access log. Is it happening a lot anyway just because it's easy? Based on the quality of code I've seen in the wild, probably more than we'd hope.
Yeah the kind of thing where someone thinks because the endpoint isn’t publicly listed it doesn’t need auth.
Relevant bits for anyone who uses next.js, it has been patched:
Next.js 13.5.9 and 12.3.5 also contain a patch according to the Next.js blog post.
That's quite an impressive response time all things considered.