If your app runs Next.js, you should upgrade it this week, whether or not you find the vulnerable code. On October 22, 2026, GitHub published advisory GHSA-673q-mjm6-r5xr, rated 9.5 out of 10, describing a flaw that can let someone with no login run their own code on your server. The advisory's own words are "upgrade immediately even if your application does not have similar functions." That's the answer. The rest of this post is how to tell where you stand and what to do about it.
What happened
The advisory is titled "Unauthenticated Remote Code Execution in use cache functions returning typed arrays." Plain words. Unauthenticated means no password needed. Remote code execution means a stranger gets to run their program on the machine that runs your app. That's about as bad as a web flaw gets, which is why the 9.5 number.
The specific trigger is narrow. It affects apps using the App Router together with the Cache Components feature, where a function marked with use cache returns more than one typed array. A typed array is a special kind of data list, the sort a developer reaches for when handling binary data like file contents or images. Most small-business apps won't have exactly that shape of code. The advisory still tells everyone to upgrade.
Who should care
Anyone whose website or app was built with Next.js. That includes apps made with v0, which builds on Next.js, and many apps a developer or a coding agent like Cursor set up. Lovable builds on a different framework (Vite and React), so a Lovable app is usually not on Next.js unless someone moved it. Owners often don't know what framework their app runs on. You didn't pick it. The tool did.
So the first thing to settle is whether this post applies to you at all. If your developer or your AI tool says "yes, Next.js," keep reading. If the answer is a different framework, you can stop here, though the general habit of asking "what runs my app, and is it current" is one worth keeping.
Check one: which version of Next.js you're running
Every Next.js project has a file called package.json at the top of the code. Inside it there's a line that starts with "next": followed by a version number. That's the number you need.
Who to ask. Your developer, if you have one. If you built the app yourself in an AI tool, open the chat and ask it to show you the next entry in package.json. It'll read the file and answer. If you have the code in GitHub, you can open package.json in the browser and scroll to it yourself.
A safe answer is a version at or above the patched version listed on the advisory page. An unsafe answer is anything below it. If the number has a ^ or ~ in front of it, that's a range, and the real installed version lives in a lock file (package-lock.json, pnpm-lock.yaml, or yarn.lock). Ask for the version from the lock file too. The range in package.json can say one thing while the lock file pins something older.
Check two: does your code use use cache
Search the whole codebase for the exact phrase use cache, quotes and all. In GitHub, the search box at the top of the repo does this. In VS Code or Cursor it's a project-wide find. An AI tool will do it if you ask "search every file for the string use cache and list the matches."
Zero matches is the safe answer. It means your app doesn't use the caching feature the advisory names, so the specific attack path doesn't exist in your code today. You still upgrade. The advisory is explicit about that, and I'd add a practical reason. The next feature you or your AI tool adds might introduce it, and you won't remember to check.
One or more matches means you need a developer to look at each one. The question for them is narrow. Does that cached function return more than one typed array? If yes, you have the exact shape the advisory describes and the upgrade moves from "this week" to "today." If the function returns ordinary data like a list of products or a user profile, you're outside the described trigger. Upgrade anyway.
Check three: upgrade Next.js
Go to GHSA-673q-mjm6-r5xr and read the patched versions it lists. Move your app to one of those. For a developer this is a one-line dependency bump and a reinstall. For an AI tool, the prompt is roughly "upgrade the next package to the patched version named in GitHub advisory GHSA-673q-mjm6-r5xr and update the lock file."
Expect the possibility of breakage. Framework upgrades sometimes change behavior, and an app written by an AI tool months ago may lean on something that moved. Run the app locally after the bump. Click through the pages you care about. If something breaks, that's a normal upgrade problem to fix, and it's a far better problem than the one the advisory describes.
Check four: redeploy and confirm the live site changed
Upgrading the code on your laptop or in a repo changes nothing for your users. The live site runs whatever was last deployed. So after the version bump, deploy again, then confirm the deployed site is actually running the new version.
How to confirm depends on your host. On Vercel, the deployment detail page shows the build log, and the installed next version appears in it. On other hosts, ask your developer to check the running build's dependency list. The failure mode I see most is a deploy that was started, failed quietly on a build error, and left the old version live while everyone assumed it was fixed. Check the timestamp of the live deployment against the time you merged the upgrade. If the live deployment predates the fix, the fix isn't live.
Check five: don't wait for a workaround
The advisory says, in its own words, "There is no known workaround for affected applications." That means there's no setting to flip, no firewall rule, no quick config change that closes this. The upgrade is the fix. If someone tells you they've found a clever way around it without upgrading, the people who wrote the framework disagree.
What this kind of flaw means for a small business
Remote code execution on your server is different from most app security problems. An exposed anon key or an API key shipped in the frontend gives an attacker access to one service. Code execution gives them the machine. From there they can read every environment variable your app loads, including database passwords, payment secrets, and email credentials. They can read whatever files the server can read. They can make requests to your other services as if they were your app.
That's why the severity number is where it is, and why "my app is small, nobody would bother" is the wrong frame. Attackers don't pick targets by hand for flaws like this. They scan for the fingerprint of a vulnerable framework and try the exploit everywhere it matches.
How to tell whether anything already happened
Here's what's not known yet, stated plainly. The advisory doesn't say whether this flaw was exploited before it was published, and I haven't seen a public account of a specific victim. Absence of a report isn't proof of absence.
What you can do today. Look at your hosting logs for the days since October 22 and ask whether traffic patterns look normal. Check whether any environment variables or secrets have been used from places you don't recognize. Your database provider, payment provider, and email provider each have activity logs. If anything looks off, rotate the secrets your app loads at startup. Rotating secrets is cheap. Living with a stolen database password isn't.
If your app has no logging and no way to answer "was anyone in here," write that down as its own finding. It's the gap that turns a patched flaw into an unanswerable question.
Where to go from here
The upgrade is the fix, and the five checks above are things you or your developer can finish in an afternoon. If you want a second set of eyes on the whole app rather than this one advisory, a Ship Check is a pre-launch security review where I go through exactly these kinds of questions, from framework versions to what your build exposes. It's one option. The free option is to run the checks yourself and, if you want tooling to help, I compared the security scanners that work on AI-built code earlier this year.
Either way, the one thing that can't wait is check three. Read the advisory, bump the version, redeploy, and confirm the live site changed.