Next.js app serving an unknown _next/static/chunks/*.js file that does not exist on disk
Unanswered
Asiatic Lion posted this in #help-forum
Asiatic LionOP
Next.js app serving an unknown _next/static/chunks/*.js file that does not exist on disk, where can this be injected from?
My server was recently compromised (because of react2shell) (contained within Docker, non‑critical learning project). I’m trying to understand how this mechanism works.
I’m not a Next.js developer, I only handled deployment, and I haven’t been able to locate the source of this behavior.
I’m debugging a production Next.js app (NODE_ENV=production, Dockerized) where an extra JavaScript chunk is being served to clients.
(The actual filename is censored.)
What makes this strange
The file does NOT exist anywhere on disk
2. Not in .next/static/chunks
3. Not in .next/server
4. Not in node_modules
5. find / -name xxxxxxxxxxx.js → nothing
It does not appear in:
1. Webpack manifests
webpack_require & webpackChunk_N_E
2. grep -R across the entire project and .next finds no references
Yet
1. It is requested by the browser
2. It appears in the raw HTML, injected just before </body>
3. It is successfully served with HTTP 200
4. The response is ~9 KB and executes normally
5. It appears in the browser DevTools Sources tab
I can’t share the contents of the injected JavaScript yet, as I’m unsure whether this is the right place to discuss potentially malicious code.
Question
Where in the Next.js / Node.js / Webpack pipeline could a script like this be injected and served when it does not exist on disk or in build artifacts?
I’m particularly interested in:
1. Next.js internals (HTML rendering / streaming / runtime injection)
2. Webpack runtime behavior
3. Supply‑chain attack vectors
4. Runtime or memory‑only module injection
5. Anything that could explain a file being served but not present
Any insight from people familiar with Next.js internals, Webpack runtime, or JavaScript supply‑chain attacks would be greatly appreciated.
My server was recently compromised (because of react2shell) (contained within Docker, non‑critical learning project). I’m trying to understand how this mechanism works.
I’m not a Next.js developer, I only handled deployment, and I haven’t been able to locate the source of this behavior.
I’m debugging a production Next.js app (NODE_ENV=production, Dockerized) where an extra JavaScript chunk is being served to clients.
(The actual filename is censored.)
/_next/static/chunks/xxxxxxxxxxxxx.jsWhat makes this strange
The file does NOT exist anywhere on disk
2. Not in .next/static/chunks
3. Not in .next/server
4. Not in node_modules
5. find / -name xxxxxxxxxxx.js → nothing
It does not appear in:
1. Webpack manifests
webpack_require & webpackChunk_N_E
2. grep -R across the entire project and .next finds no references
Yet
1. It is requested by the browser
2. It appears in the raw HTML, injected just before </body>
3. It is successfully served with HTTP 200
4. The response is ~9 KB and executes normally
5. It appears in the browser DevTools Sources tab
I can’t share the contents of the injected JavaScript yet, as I’m unsure whether this is the right place to discuss potentially malicious code.
Question
Where in the Next.js / Node.js / Webpack pipeline could a script like this be injected and served when it does not exist on disk or in build artifacts?
I’m particularly interested in:
1. Next.js internals (HTML rendering / streaming / runtime injection)
2. Webpack runtime behavior
3. Supply‑chain attack vectors
4. Runtime or memory‑only module injection
5. Anything that could explain a file being served but not present
Any insight from people familiar with Next.js internals, Webpack runtime, or JavaScript supply‑chain attacks would be greatly appreciated.